The Big Cloud Exit Myth

I have finally gotten around to writing professionally, but not for work. I’m writing this on Christmas day while I’m supposed to be cramming for my AWS Solutions Architect Professional exam to re-certify tomorrow. I have been following “The Big Cloud Exit” since last year when David Heinemeier Hansson published the article.

The title of my article is “The Big Cloud Exit Myth” to parallel his vision for his company, which he decided to make public and use to “influence” people and organizations about why they should exit the cloud. I hate articles titled “9 ways to use …” and “5 ideas to make …”. These articles are overblown, inconsequential, or downright misleading.

So, I have decided to make my first post a commentary on “The Big Cloud Exit” while explaining why the public cloud is essential to organizations if appropriately used. As a senior solutions architect, I have seen many proper and improper public cloud uses over the last six years. I find the entire premise and process David has used to be disingenuous, using the veil of “transparency.” How could it be disingenuous but also transparent? He has given broad strokes of the process with a sprinkling of details.

Details matter.

So, to start, let’s look at 37signals. The website has a very interesting minimalist design. David and 37signals have some admirable parts of the 37-part “mission statement.” I would start with points 10 and 20: The Fortune 5,000,000 and Small Tech.

Companies are not obsessed with battling for huge Fortune 500 companies. People are. Companies are a construct of people, and company leaders heavily influence companies’ attitudes. Sales organizations in large companies target greenfield, mid-market, and enterprise customers. The evolution of a company is a natural process that can be restricted only by its leadership. David has decided that 37signals targets the Fortune 5,000,000, and that’s perfectly okay. Inversely, it is okay that other companies target the Fortune 500, along with plenty of other companies. The small tech point is heavily influenced by the previous one.

In the context of his other writings, small tech makes more sense in conjunction with point four, the profit motive. The idea that big tech tramples, muscles, and homogenizes is somewhat ludicrous. It is valid broadly, but big tech looks to deliver technology solutions to companies across the spectrums of size and industry.

The goal of public cloud providers is to make technology more accessible to companies that would not have access to it otherwise. On its face, this statement seems a little naive, but stay with me. Disregard all of the marketing, sales speak, and buzzwords, public cloud providers have enabled access to technologies for companies without the skill sets to manage or implement said technology. Lack of skill sets is the first part of why the public cloud is essential to individuals, organizations, and companies.

I have just recently set up an Opensearch domain. I needed it for a specific purpose. AWS Opensearch Service accelerated my end goal. I could have figured out how to deploy and configure it manually, but why would I need to do that? Several of the mission statement’s points convey that our time is valuable.

David points out that the public cloud is only valuable for two reasons: 1) low traffic and complexity and 2) highly irregular load patterns. I’m afraid I have to disagree with this being the only value the public cloud brings. I have been staunchly against migrations to the public cloud for the sake of migrations. Sales executives love them because of the shekels they add to their bank accounts. Moving virtual machines from one place to another can have value for organizations, but there are other values that the public cloud brings.

Data science, machine learning, and other fringe technologies have been brought to the forefront by public cloud providers and a few other hyperscale companies. If an individual, organization, or company wanted to create their platform with these technologies, the costs would go through the roof, and I have seen this happen. Quick experimentation and the fast-fail methodology add value to organizations that need to accelerate the trajectory of their products and services.

I’ll be very blunt in this following statement. 37signals wrongly chose how they used the cloud and saw an exit as the only option. It is essential that the public cloud be used in appropriate ways. David conveniently omitted the tech stack used by 37signals and its products, but some of it can be inferred from his writings. The public cloud is more than renting computers, as he has suggested, but David, in the 37signals’s mission statement, shows a bias against big tech and the public cloud. My question is, why did it ever make sense to use public cloud?

I want to address his point of “don’t be fooled by serverless.” Serverless is a buzzword, and I asked those to be disregarded. Serverless functions and managed services are two completely different things. Managed services have an underlying construct of public cloud providers handling the automation and orchestration of many tasks that David takes for granted at the least and doesn’t understand at the most. Someone or something has to do these tasks. The public cloud has enabled automation and orchestration for the masses that any organization would fail to accomplish on-premises. I was a cloud management specialist at VMware specializing in automation, and I have been in IT for 15 years. Automation in data centers is complicated and very limited. Many on-premises products are not easily API-enabled. The public cloud providers have invested billions of dollars in making automation and orchestration at hyperscale successful. There are many points of public cloud pricing that I disagree with (i.e., data transfer), but looking at value over cost is the most critical aspect.

Amazon Prime published a blog about reducing costs and reverting from a distributed service mesh to a monolithic architecture. Many people took this as a sign that “serverless is bad,” while the reality is significantly different. This blog should have conveyed that serverless systems are used appropriately, not because of buzzword hype. Some nameless executives, product managers, or architects saw the serverless buzzword in their marketing material and hundreds of industry analysts’ reports. Then, they decided the team should implement serverless where it didn’t need to be. This is my opinion and may not reflect what actually occurred.

The premise of this post comes down to my final point. Use the public cloud where it makes sense. Do what makes sense for your organization, customers, products, and services. Many mechanics, engineers, artists, and others have said, “Use the right tool for the right job.”