Image Credit: Jumpstory

Cloud exit or cloud right sizing?

David Heinemeier Hansson (DHH) made headlines last year when he announced that his company, 37Signals, was withdrawing from the cloud. While some interpreted this as a sign of the cloud’s decline, a closer look reveals the opposite. The lesson learned is not to abandon the cloud altogether, but rather to adapt it to meet your specific needs through cloud right sizing.

The cloud company’s cloud exit 

37Signals is a successful Software as a Service company (that is, a cloud company), whose two most popular products are the email platform hey.com and the CRM system basecamp. There are also some additional smaller services that do not have a significant impact. Basecamp is already run on-premise today. In addition, they use S3 for all their solutions.

DHH writes in December 2023:

“Not only did we complete our cloud exit quickly, but customers scarcely noticed anything, and soon, the savings started to mount. Already in September, we’d secured a million dollars in savings on the cloud bill.”

However, their cloud exit is not to their own data center but to a partner, Deft (Source: The Big Cloud Exit FAQ (hey.com)), where they lease rack space at two locations in the US. Deft also handles all the practicalities of setting up purchased servers. Technically, this is still cloud according to the NIST definition of IaaS:

“The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications and possibly limited control of select networking components (e.g., host firewalls).”

They really just switched cloud providers!

He writes very bombastically, “The cloud exit is done,” but they still use the cloud as a CDN to ensure fast response times. Further, almost a third of their cloud bill for 2022 was for S3 used for file storage. Consequently, it is not a complete cloud exit but a hybrid cloud setup. 

Cloud exit at no cost?

They bought computers from Dell and had them installed in the Deft data center. DHH knows well that a server breaks down and expects a server to last five years on average. That seems like an extended amortization period, but I’m no infrastructure expert. However, five years from now, the servers will not be as impressive in terms of performance as they are today. The amortization of comparable compute price following Moore’s law has not been included in this amortization schedule. It may still be sufficient for their needs, though.

Apparently, they were able to buy new computers and install them in their Deft data center without any extra electricity bill. I wonder if that is replicable: buy $700.000 worth of computers and connect them without any additional power cost. He also admits that their setup can’t handle spikes of 5-10x and that server provisioning is much slower, so it’s not all rosy clouds. On the other hand, these are also functions that few organizations need.

The operations costs were kept stable. No additional people or other service costs were incurred after expanding the data center significantly. I wonder if that calculation will be generalizable, too. While I am unsure that similar migrations may be able to be done without additional costs for electricity or operations, it is clear that it is significantly lower altogether. DHH mentions one million in savings on a 2.3 million budget. That is around 40 percent. We should also notice that it is different from what they get. An AWS server with the same specs as today would not cost the same as today in five years, and they give up on elasticity. The trick is that they figured out what they need and could provide that cheaper. 

Not quite an exit, after all

This is not a cloud exit but a cloud migration of a substantial but limited workload in a hybrid cloud setup. The cloud is not only the hyperscalers AWS, Azure, and GCP. Multiple other suppliers offer specific elements or more attractive cost structures. If you can move all your processing to a different provider without any additional cost, that is a good deal. 

The exercise is about right-sizing the cloud. Given the steady flow of an email service like hey.com with few peaks, having a much less elastic setup at a cheaper price point makes sense. They still use Content Delivery Networks and file storage in the cloud because they are optimized for specific workloads.

The lesson from 37Signals’ impressive cost savings is not to leave the cloud but to carefully architect it to the organization’s needs. If you have a very standardized infrastructure built entirely of open-source components like virtual machines, containers, and relational databases, there are many alternatives to lifting and shifting it to another provider. If your workload is steady, this provider does not need to provide high elasticity for sudden bursts. 

What is needed is for companies and leaders to follow in the footsteps of DHH and carefully examine their workloads and possibilities for adapting them to a more cost-optimal structure. This requires architectural skills and a knowledge of alternative vendors in this space. This also applies when moving workloads from on-premise data centers to the cloud. A full-on lift and shift of everything to AWS might not make you happy (or at least not your CFO). For each workload, it is necessary to evaluate the optimal architecture and deployment. If you only need the basic IaaS features, companies like Digital Ocean, Rackspace, Hetzner, or FUGA Cloud. Suppose you need lightning-fast response times: Cloudflare, Akamai, or KeyCDN. 

It is difficult to generalize and conclude that we are in the middle of a significant cloud exodus. In fact, I believe that the opposite is the case because the vast majority of companies in the world still have a lot to gain by migrating to the cloud. They just need to align the architecture around the optimal cloud services. 


Posted

in

by

en_GBEnglish