I recently helped a client to transition the hosting of their homepage to a cloud hosting provider. My client had received the sales pitch, were convinced by fortune 500 reference clients and assurances of a 99.99% uptime SLO. My client had already spent all the money to build their next homepage inside the cloud provider’s ecosystem. All that was left for me was to deploy it.
Of course, we first ran a test with a non-public domain to make sure the cloud provider’s hosting setup was working as intended. The cloud hoster passed the test (including some AB benchmarks) with flying colors. After redirecting our actual customer-facing domain to the cloud provider, everything was working great!
It was a successful launch …
… or so we thought. Roughly 12 hours after they took over hosting our homepage, we suddenly started seeing HTTP error 429. We reached out to support and they gave us bullshit tasks to do. They asked for access to our root domain DNS zone. They told us to remove our domain in their GUI, wait for 12 hours (where we’d be offline), and then re-add the domain. And oddly enough, after they replied, the problems got a lot worse.
By now, it was broken for most of our staff, including me. Looking at the HTTP request inspector, it was immediately obvious that DNS was working just fine because I could see my browser connect to the correct IPs. And the error 429 reply also included headers specific to our cloud hosting provider, thereby proving that my request had, indeed, reached their server.
When asked about the 99.99% uptime SLO, support told me that their SLO for regular customers was just a non-binding self-set objective. If we actually wanted 99.99% uptime, we would need to upgrade to an Enterprise plan and buy the Enterprise SLA.
That’s when we figured out that we’re the suckers in a mafia-style protection racket:
Either we pay up, or we lose our homepage.
Luckily, we had kept the old servers running. And I had deliberately set a very short TTL on the DNS changes. This allowed us to quickly switch back to our old self-hosted homepage.
Sadly, this is not the first time I’ve seen one of my consulting clients getting very heavy-handedly forced into upgrading by a cloud vendor, which is why I’m writing this blog post to warn others. And here’s a bit of argumentative help:
When comparing Cloud with On-Prem, always include the Enterprise SLA and Enterprise Support costs
When you do your own hosting, you’ll usually pay more in salary costs. But you have the huge advantage that if stuff goes wrong, you can call these people, and they will pick up the phone. If you treat your employees well, they might even cancel their vacation to help you through a technical emergency. Sooner or later, you’ll need that kind of help. Also, when you own the server, nobody is going to kick you out against your will. But with a cloud service, they might be willing to throw you under the bus if it helps them please larger and more profitable clients. Or, as in this case, extract more money from you.
That means if you move from on-prem to the cloud, you are not “saving” the salary of your ops person. You are merely shifting it from salary costs to service costs in your P&L.
If you are a small business, in many cases you’ll find that the Enterprise SLA and Enterprise Support Contract together are so extortionately expensive that you’re better off financially with on-prem hosting.
“The Cloud” is just someone else’s computer.
And most cloud providers have no loyalty. You’ll likely never even meet them in person. The only thing you know for sure is that “The Cloud” generates a lot of profits. And you sincerely hope it won’t be you holding the bag. That’s right, for a small company, the public cloud is as reliable as a prayer.
If it’s you vs. “giant billion-$$$ cloud corp”, you have 0 leverage. You won’t even get a phone number to call. As a small company, you should work with local trustworthy service providers, where you know the staff. Stay away from impersonal unicorns.
I’ll leave you with a slighly modified quote by one of the sages on reddit:
The worst part about the cloud is that when something breaks, there’s very little I can do to fix it.
The best part about the cloud is that when something breaks, there’s very little I can do to fix it.