They’ve dominated the world of infrastructure for the past decade, raking in astronomical profits in the process. But there are rumblings in the industry - which 37signals’ David Heinemeier Hansson stoked up in his refreshingly honest blog post and guest podcast about leaving the cloud - that the undisputed reign of the cloud hyperscalers is about to be seriously challenged.
Finally.
I don’t say that because I work for a company that provides alternative hosting services. I say it because we are constantly being approached by companies that have got themselves locked into the hyperscale cloud providers’ platforms and want to get out. Who cannot or do not want to pay huge amounts of money for services that they don’t use, and support that is never there.
According to a new Wanclouds study, 81% of IT leaders say their executives and boards of directors have told them to either reduce hyperscale cloud costs or take on no additional cloud spending.
You could argue that number is indicative of the belt tightening that many businesses are now going through as a recession looms. But it’s also been some time coming. The shine had to come off the cloud hyperscalers at some point as businesses eventually clocked that the promise of scalability, efficiency and lower infrastructure costs isn’t exactly as it seems.
That’s not to say that the likes of Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure don’t play an important role in companies’ infrastructure. They absolutely do. For the Netflix and Amazon Prime’s of this world, that have very unpredictable scaling requirements, hyperscale cloud really is a good option to handle these peaks in traffic. But there are not many of those companies out there.
Before we get into the dos and don’ts, and finding a path out of hyperscale cloud, I think it’s important to first touch on the history of the cloud. Or, more accurately, my take on the history of the cloud.
Let’s start back in the 90s:
Introduction of WWW - The internet started to come into people’s homes with the invention of the World Wide Web. Companies had servers (mainly IBM mainframes) that usually lived in the basement, with desktop computers connected by LAN (local area network). It was impossible to access anything outside of the office.
Cloud was born - The internet then really started to take off and businesses set up websites, which needed hosting. Whether that was on their own servers, via a newborn web hosting company or on a third-party provider’s servers in their data centers. The latter two are what I would pinpoint as the first iteration of the cloud.
Because the cloud is - at its root - just using someone else’s computer. The complicated perception that we have of the cloud today is what the hyperscale cloud providers have created.
New services emerged - As the internet grew, people started to create new services - hosting multi-player gaming, creating eCommerce experiences, and streaming digital content. And these new services needed infrastructure to power them.
Enter co-location – Companies now had the opportunity to own their own servers but in someone else’s data centers.
Enter infrastructure-as-a-service - Hosting also entered the mix, building on the concept of cloud by providing businesses with access to someone else’s servers via the internet.
The dot-com bubble threatened to stem the technology tide, but the industry survived, and companies started to see the benefits of flexibility and scalability by hosting infrastructure in someone else’s data center. The move from CapEx to OpEx was particularly popular with start-ups that weren’t cash rich but with just a couple of hundred dollars a month could get their business online and start to disrupt traditional industries.
The problem with the hosting options at the time was that they were not flexible and scaling was slow, due to long term contracts and slow delivery times of additional infrastructure. Hosting was perhaps 10-15% better than owning and managing your own infrastructure.
It wasn’t enough and AWS knew it. As one of the biggest eCommerce companies in the world, it had spent a lot of time developing tools and server capabilities to enable it to scale up and down for massive peak events such as Black Friday and Christmas. So, why not monetize those tools and capabilities by selling them to other businesses? And do it in a way that was vastly different to current hosting services by billing by the hour (today, it even bills by the second) and spin up virtual machines in minutes.
No one else in the hosting market could even come close to these numbers. By the time other hosting companies had built their own clouds, AWS had gained a huge market share and built out a massive service offering. Businesses no longer had to think about compute or storage - it was now all sold as-a-service, available to purchase with a credit card.
Cloud is now synonymous with AWS, with GCP and Azure not far behind.
Why the history lesson? I think it’s important to know where the cloud came from in order to compare where it is today and why companies have got caught up in the hype. I was a customer of the big three hyperscale cloud providers at one time, so I understand the lure of the cloud and its promise.
I also know first-hand the complex monster that hyperscale cloud is today.
The more services that AWS has built over the years, the more complex it has become for the customer. I don’t know how, as a consumer, you are meant to know the best, most cost-effective way to buy its products and services. I don’t even think there is any one singular person at AWS who knows the most optimized way for customers to buy. The complexity has become so great that it even sells courses on how to manage the environment and companies are hiring people with AWS certifications to help them make the best buying decisions.
When I was a customer, I spent a good chunk of time learning how to understand the 1000-line Excel document that accompanied my monthly invoice and that was simply for compute. In the end, I, like many other companies, built an internal tool to translate the monthly bills into something legible.
And even if I wanted to speak to someone about it, the support that these companies provide is next to non-existent. Their standard support is break-fix only. I once waited a week after raising a ticket to be pointed to a knowledge base article. Better service is available but - you guessed it - it is an additional percentage on top of your bill every month.
While the purchase of hyperscale cloud may be simple, actually buying it in a way that works for your business isn’t. It’s very easy to end up spending far more than you should be.
So where are businesses getting it wrong?
As I touched on earlier, hyperscale infrastructure is a really good option for companies that have huge, unpredictable peaks and troughs.
Where many companies are going wrong is thinking they need this level of scalability. And here is perhaps my biggest message for any company reading this.
Incremental scaling and small peaks and troughs do not require hyperscale cloud.
Everyone has peaks and troughs in the daily curves of their usage. The cloud sells you on the ability to follow those curves up and down to ‘optimize your spend’. However, hyperscale cloud costs for compute can sometimes be 10x the cost of doing it in bare-metal, making the additional complexity of setting up and managing this auto-scaling null and void.
Part of the problem is that not many companies have a good grasp of what their scaling requirements actually are. It’s why we spend a lot of time with customers at the beginning trying to understand what they need.
Often cloud computing services will play a role in delivering infrastructure that suits those needs. But it is far more cost effective to put in place a baseline of bare-metal with cloud auto scaling. This allows scaling to take place but also means that if that new peak stays consistent, it can be backfilled by bare-metal, reducing reliance on the cloud and therefore reducing spend.
Of course, if you are a start-up, you won’t know what your scaling needs are, which is why many fall into the hyperscale cloud trap - by assuming huge success.
Many people reading this blog will likely be in the hyperscale cloud in some fashion. For some of you, that commitment to cloud computing services has been made at the request of investors.
There are two key reasons why investors are so keen on the cloud.
They are investing in a company because they believe it will be successful and are willing to part with cash for that belief. They will not want to hear, therefore, that the cloud might not be the best option if the company doesn’t succeed.
Developers are needed to replace the platform and software-as-a-service that the cloud hyperscalers provide and developers are expensive. The cloud gives start-ups a way to fast-track to launch with free credits and tiers.
This is a case, however, of ‘if it seems too good to be true, it probably is’. The hyperscale cloud providers are betting on perhaps one in ten start-ups being successful. By which point, they are locked into the platform and are too busy focused on developing a marketing team or expanding into a new geographical region that they don’t pay attention to their hyperscale cloud costs, which rapidly start to snowball.
Before they know it, they are in a huge amount of technical debt and in order to relocate from hyperscale cloud they will need to re-architect and build new systems.
Bearing in mind all of this and the issues companies are now starting to be vocal about in the public arena, I have some advice for companies who are either considering the cloud or looking to reduce their reliance on it.
Read the fine print - look at anything that is being offered for free with a very fine-toothed comb to really understand what you’re signing up for. Free now, doesn’t mean free forever. The cloud companies need to make money down the line to pay for these free credits.
Plan your escape - if you choose to take advantage of the free credits, make sure to put in place a strict deadline ahead of those credits running out to allocate a small amount of budget to start escaping any technical debt from platform/vendor lock-in.
Build architecture to be vendor-agnostic – I appreciate that is not always possible if under time pressure but know that at some point, you will pay the price in terms of cost or technical debt to get yourself out.
Be patient - if you’re already locked in, you have some work ahead of you. Be prepared that you can’t go from a highly locked in environment to one that saves you millions a year. It’s going to require investment in re-architecting key systems over time, not all at once.
The key thing is that people are now talking about how complex cloud has become and why it’s not sustainable. Where before it felt taboo to bash the cloud, the door to a more honest look at the reality of being a cloud hyperscale customer is slowly opening.
I’d love to hear your thoughts and experiences of hyperscale cloud and to know if anything I’ve said here resonates so, please get in touch if you’re interested in continuing the discussion.
With a decade in hosting and video game hosting, Isaac knows the big mistakes and how to help customers avoid them. Dog dad to Lilly, he owns all the tools and lives his best lawn life.
