Choosing On-Prem vs. Public Cloud

There was an article recently on Linked In by David Heinemeier Hansson about his company’s decision to leave the public cloud and save $7 million over the next five years. The article engendered a great deal of discussion about the pros and cons of his approach, and many questions about how they planned to do it and how he calculated the savings. The article that announced the decision and got the most publicity had a link to its precursor article that set the stage for the decision. I am not sure how many read that article too, but after reading them both, I had some comments to make.?

Too often we see engineers and designers choose a technology, widget, design or paradigm because it is the latest buzz in the industry. This even has a name: ‘Shiny Object Syndrome’. Weighed down by too many expectations of them, overworked engineers are always dreaming of a solution that makes their lives easier. However, as we all know, and Gartner has institutionalized, most of these expectations are based on hype, and once the layers have been peeled back and the new technology put to use, they tend to be more like onions: they only bring tears to our eyes.?

Business needs have to drive the technological design approach in every case. What is the likely usage of the application over time? Can we predict the growth pattern and seasonality with any level of certainty? David has laid out the business expectations for his set of applications and even admitted that when an application was unexpectedly successful, being able to add capacity very quickly was essential. But when the resources needed can be modeled and satisfied in a planned manner, owning is better than renting.

In fact, my analysis of the cloud costs being incurred, and the resources being used for several applications shows that architects are still thinking in the old ways and provisioning for the peak, rather than the minimal configuration that will work and scaling out and in as the load grows or recedes. In addition, the years of planned overcapacity in datacenters and colos have made engineers lazy about constraining resources being used. A colleague has even explained how most applications use 25-50 times the storage they need due to uncontrolled data replication and poor design.?

All of this leads to several calls to action. First, engineers need to be aware of the resource costs their design decisions are leading to, based on expected load over time. Architects need to use these load projections to choose the services and resources they need and consider the risks and costs of being under-provisioned and even the cost and effort moving from one choice to another.? They need to choose the services that are ubiquitous rather than available from a single vendor, so that migration between vendors and internal datacenter/colo is easy. Finally, they need to choose an internal developer platform that abstracts away the infrastructure and its operations away from the developers who can just focus on building the best apps that can run anywhere the business needs dictate.?

A final comment. Many of the posts in Linked In as well as on Twitter where the conversation overflowed were unduly polemical. I would hope that as engineers and technologists we are guided by data and reasoning when making our choices. In many real-world cases, we don't always have all the information or predictability we would like, but we balance the risks and move forward. If we find later that we were wrong, we just execute Plan B.?

About Tailwinds

At Tailwinds we are helping teams design, build, deploy and operate cloud-native applications securely with lower cost and faster time to market using our Internal Developer Platform (IDP) product - MajorDomo.??