So you want to change cloud providers

Online posts might make it sound worthwhile to chase credits, but look at all the factors before switching tracks to a new cloud.

I should know better than to look to the Hacker News crowd for wisdom. Recently someone on HN asked an interesting question: “Have you ever switched clouds?” Being HN, the responses weren’t nearly as interesting. In fact, relatively few people responded to the question at all, preferring instead to champion running their applications in private data centers. Others offered advice tuned to small shops not larger enterprises.

Yet despite the noise, there was a little signal in the thread. If you want to get the most of any particular cloud, you’re going to need to buy into its services, which, of course, complicates migration. Oh, and if you think you can build a better cloud than the hyperscalers, you might be missing the point.

[ Also on InfoWorld: Will Google Cloud ever win over enterprises? ]

Show me the credits

Once companies have elected to build on a particular cloud, what prompts them to move? Reading through the HN responses, “credits” are a prime motivator. It’s unclear how much such a honeypot appeals to larger enterprises, but for a certain demographic, migration can be motivated by “enough Google Cloud [or Azure or AWS] credits to make a switch worthwhile.” Unfortunately, this simplistic kind of cost/benefit analysis overlooks all the hidden costs of running in the cloud, as David Linthicum has detailed.

As GitLab apparently discovered, credits may encourage migration but they don’t necessarily pay for it. As described in the HN comment, “At GitLab, we went from AWS to Azure, then to Google Cloud.” Why move off AWS in the first place? Money was an issue, but not because AWS was inherently more expensive. Rather, it was a problem with the setup: “Like most companies, very little attention was paid to the costs, setup, etc. [when starting with AWS]. The result was that we were basically setting money on fire.” Along came an offer for free Azure credits that “would save us something like a year’s worth in bills (quite a bit of money at the time).”

Sounds great, right? “Moving over was rather painful and … we burned through the free credits very fast.” The company then decided to move to Google Cloud (for unexplained reasons), and found that migration was, again, a “challenging process.”

What did the commenter learn from the experience? “Looking back, if I were to start a company, I’d probably stick with something like Hetzner or another affordable bare metal provider. Cloud services are great if you use their services to the fullest extent possible, but I suspect for 90% of the cases, it just ends up being a huge cost factor without the benefits making it worth it.”

To me, this is the exact wrong lesson.

Still not understanding cloud

If you read through the entire thread, you’ll find a lot of self-confident assertions that do-it-yourself cloud (on Hetzner or other dedicated server hosters) is the way to go. (Here and here and here.) As they say, public cloud is “slower and more expensive than your own server by a huge margin.” Except that it isn’t. This idea that IT pros can easily “out-cloud the cloud” is wrong and beside the point.

Cloud has never really been about saving money. It’s about maximizing flexibility and productivity. As one HN commenter points out, “I work on a very small team. We have a few developers who double as ops. None of us are or want to be sysadmins. For our case, Amazon’s ECS [Elastic Container Service] is a massive time and money saver.” How? By removing sysadmin functions the team previously had to fill. “Yes, most of the problems we had before could have been solved by a competent sysadmin, but that’s precisely the point—hiring a good sysadmin is way more expensive for us than paying a bit extra to Amazon and just telling them ‘please run these containers with this config.’ ”

He’s doing cloud right.

Others suggest that by moving to serverless options, they further reduce the need for sysadmins. Yes, the more you dig into services that are unique to a particular cloud, the less easy it is to migrate, no matter how many credits a provider throws at you. But, arguably, the less desire you’d have to migrate if your developers are significantly more productive because they’re not reinventing infrastructure wheels all the time.

One company explicitly tried to avoid lock-in to any particular cloud. “We developed our product from the first commit to be deployed on 3 (!) clouds: AWS, Azure, IBM.” How so? By “sticking to the least common denominator which was FaaS/IaaS ([AWS] Lambda, [Amazon] S3, [Amazon] API [Gateway], Kubernetes).” Sounds simple, right? “It was certainly not easy. We also ignored tools that could’ve helped us greatly [if we’d stayed with] a single cloud in order to be multicloud.” Was it worth it? “Moving between clouds, given shared features, is possible, but is definitely not a couple clicks or couple of Jenkins jobs away. Moving between clouds is a full-time job. Finding how to do that little VM thing you did in AWS, now in Azure, will take time and learning. And moving between AWS IAM and Azure [Active Directory] permission? Time, time, and time.”

Multicloud isn’t easy to pull off, in other words, and neither is migration. Does that mean neither is ultimately worth it? Not necessarily. As Miles Ward, CTO of SADA (a key Google Cloud partner), describes it, there can be compelling reasons to jump to another cloud. “For so many, it’s just ease of use and efficiency to get things done; for others, it’s attention and partnership; for a third cohort, it’s absurd cost advantages; and a fourth, it’s performance and reliability.” As such, when “customers see gaps in one or many of those four areas … they move.”

Ward is probably right: There can be compelling reasons to migrate. Just be sure to do a full analysis of the total cost of ownership of the move, which needs to go well beyond “cloud X is offering me $50,000 in credits.” In addition, before you decide to roll your own cloud, it’s worth factoring in the costs associated with managing all your own infrastructure.