Old school architectures making a return, part 3: escaping the Hyperscalers
Nobody ever got fired for buying AWS. But maybe they should be?
For the last 15 years, the default move for startups and enterprises alike has been to move their compute needs to the three big Hyperscalers (AWS, Google Cloud, Azure). In particular, AWS has benefitted, being the first modern cloud provider.
This has been further solidified by skills for the three specific clouds being in-demand: a combination of Resumé Driven Development, and certifications have reinforced the loop of moving to the Hyperscalers.
However, lately this default is coming under attack: Amazon Web Services margins, as of April 2024, were 37.6%, quite rich for a supposed commodity business. GCP and Azure margins aren’t far behind. People have started questioning the default, Basecamp have loudly moved from the cloud back to on-premises due to costs.
And even by what can be observed externally, it seems the Hyperscalers are milking their customers. As an example, in a recent price comparison, 50TB of data costs:
$56 on Hetzner
$4250 on Google Cloud
$4350 on Azure
$4500 on AWS
There are two observations I can make from this:
The Hyperscalers price bandwidth almost 80x higher than some of their smaller competitors.
Secondly, the Hyperscalers usurious egress pricing is curiously closely clustered together to make me think…
But surely there are benefits to the Hyperscalers?
Yes, the Hyperscalers have certain benefits (note: i distinguish between the cloud and hyperscalers, they are not the same).
Not least:
Close to limitless elastic scaling.
Global reach - the ability to put compute close to users almost anywhere on the planet. This significantly reduces latency in many cases.
Global resilience - the ability to create systems where losing an entire datacenter is only a blip.
A plethora of managed services that reduce the need for dedicated DevOps/systems administrator headcount.
There are surely more benefits that slip my mind at this point, but nonetheless, for organizations that need one or more of the above, Hyperscalers are close to the only game in town.
Do you need it, though?
However, ask yourself, apart from the cool-points you score from saying your system is globally resilient and distributed, can scale infinitely, etc, do you really need those things?
Is your load-profile mostly stable, or perhaps not stable, but predictable, to the point where growth and even best/worst-case scenarios of load are easily achieved with.. Some servers?
Maybe, it’s a case of YAGNI (“You Aren’t Gonna Need It”)? Maybe one of the smaller, budget cloud providers will serve you just as well, for a fraction of the price?
Or if you are a bigger company, perhaps on-premise/dedicated hardware in someone’s datacenter(s) will do the job?
For the third time: consider your defaults!
For the third time in this series of posts, I’m going to make the point I have been making throughout:
Stop defaulting your choices. Start considering the trade-offs of different choices. Pick the best one.
I’m not quite advocating a return to on-premise (though it might be appropriate for some), just consider whether the benefits of the Hyperscalers really apply to your use of compute, and whether they warrant the steep premium paid.
By simply asking the questions and considering the answers, it’s possible you may cut your operational costs down to a fraction. If you compound the choice of not always building microservices, and not always defaulting to the big, expensive cloud providers, the savings could be immense. Simpler architecture leads to less compute being used, and less DevOps work needed. Less compute, from less expensive providers, will improve the bottom-line even further.
As we close the books on the excesses of the ZIRP (“Zero Interest Rate Policy”)-era, it’s worth reflecting on the excesses our industry got caught up in. Expensive default choices are definitely some of them.