Hidden Benefits of Running in the Cloud
It’s time again to have the “cloud exit” debate where some company or system migrates off the public cloud and over to some flavor of on-premise, saves bazillion dollars, and attracts a lot of social media interest in the process. A couple of years ago, it was Dropbox. This week it’s Basecamp. In retrospect, it shouldn’t be a huge surprise: Everybody has their own tolerance for paying platform vendors, and for some people that’s notoriously low.
That’s great for them, and I don’t question their decision. But I think before other organizations rush to draw too many lessons from their experience, it would be good to do a quick check to make sure all aspects have been considered.
You get a lot more from the cloud than what you directly see on your bill.
Expecially in terms of non-functional requirements like performance and availability.
If you start with the question, “Where can I most cheaply run my MERN (or similar) stack application?”, you might conclude, “On a Linux machine sitting under my desk”.
Of course nobody in their right mind would ever do that, at least these days (right?!?). So now we’re into negotiating and making engineering tradeoffs.
Say you get a rack in a local data center and stick some bought or rented hardware on it, use some best DevOps practices, and install your three-tier application on it. You’ll probably make it at least minimally resilient, with redundant load-balanced servers. Perhaps you even use two geographically dispersed data centers. You probably want an ELK stack to do a little logging and monitoring. Monitoring seems to be a cash cow for public cloud providers, so you’ll most likely save a lot of bucks there (although ELK isn’t necessarily the easiest thing to try to operate yourself at scale).
Overall, it’s still cheap, maybe not as cheap as under your desk, and it works. But are you “done”? And do you have all the qualities you want from an application that’s going to make you billions? Maybe there are some things we haven’t fully thought through?
Networking?
Let’s talk networking. Your local datacenter certainly has a fsat link to whomever your local telco / fiber provider is, but you’re pretty much at their mercy after that.
Public cloud providers have world-class backbones that your locals can’t hope to match. When you’re running on the public cloud, your applications tacitly take advantage of that as you use the cloud provider’s services. And that includes the frequent improvements and upgrades.
Geography?
Your on-premise datacenter is located, well, where your on-premise datacenter is located in terms of geography. Maybe that’s where all your users are. It’s probably not. If you are running your own servers, the incremental cost of adding a new geography is…high.
A public cloud provider has points of presence all over the globe, connected by that fast backbone we mentioned above. And this isn’t just for the content delivery network (so crucial for serving low-latency responses to your users), but also services and databases if you provide an API or SaaS.
Upgrades?
If you run your own servers, not only will you be last in line for capacity procurement the next time there is a 2020-style hardware supply chain crunch, but your hardware is literally a depreciating asset. You’ll eventually need to decide when to pay for an upgrade and plan for a capital outlay to make that happen. And that’s assuming your hand doesn’t get forced by rapid growth.
Contrast with cloud hardware, where you get almost continuous improvements in price-performance. When AWS introduced Graviton instances, it immediately saved customers money and sped up workloads to the extent that it broke some poorly-designed SaaS providers’ billing models. And that upgrade was in many cases as easy as flipping a switch.
Others?
There’s all the standard arguments about cloud improving your velocity and agility by giving you one-click access to all kinds of different infrastructure. I’ll skip those since those have been discussed in great detail elsewhere.
Cloud Exit?
Cloud exit isn’t for everybody. Before you go there, make sure to keep in mind all the benefits you get from running in the public cloud, not just the ones with specific dollar signs attached.
Postscript
There are other squishier angles to pulling off a successful cloud exit that I intentionally didn’t address. One of those is personnel. I won’t go into details, but the general argument goes something like:
Early-career engineers aren’t being trained to run on-premise infrastructure.
Most people aren’t very interested in taking that up.
Those that are, are mostly very (very!) gainfully employed at the handful of largest tech companies and aren’t likely to leave.
Let me know if you’re interested, and I can go into this further in an upcoming post!
