11 Dark Secrets Of Multicloud

Cloud computing is a digital cornucopia of choices to dazzle the eyes of everyone from the spreadsheet-addled CIO to the container-slinging intern. Those servers with 24GB of RAM look nice and so does that new AI image classification system. Oh, what’s that over there? Long-term object storage? Give me a couple zillion bytes of that too.

If the options from one cloud provider are nice, why not two? Or three? Or N? Everyone knows that homework expands to fill the desk and every recipe grows in complexity to take over every bit of counter space. It’s only natural for the modern architect to entertain the idea of sprawling over the entire internet to take advantage of all that’s available.

There are good practical reasons why multicloud architectures make sense. More clouds mean more options for APIs, more locations for data centers, and an even longer list of clever AI algorithms that just might work. When new improvements come along, a team of architects that’s open to multiple clouds will be agile enough to take full advantage of them.

And there’s also the desire to fight vendor lock-in. When the contract comes up for renewal, the prices go up until you find some competition. Adding multicloud agility into the architecture from the beginning makes it easier to switch when the vendor sales team wants to squeeze you. There’s just something so irresistible about the dream of being able to move your business to another provider in a weekend.

But all these advantages come with a price. Remaining agile enough to enjoy the competition has a dark side that may only become obvious after several weeks, months, or even years. Here are some of the hidden dangers of multicloud that might arise to undercut your experience.

Missing out on proprietary excellence

Many parts of the modern cloud are pure commodities. Everyone is selling instances with variable amounts of RAM and a choice of your favorite flavor of Linux. Everyone is storing your bits in buckets. But in between all of these run-of-the-mill options are some unique and powerful tools that are largely proprietary. Oracle’s main database, Google’s Firebase, and Microsoft’s .Net stack are just a few of them.

The multicloud imperative can make it difficult to take full advantage of all these tools offer because it’s hard to duplicate them in another cloud. If your goal is to make sure you have other options that can be swapped into production at a moment’s notice, you might not be able to enjoy the truly clever options that appear. You can still make exceptions for one part of your stack. But the biggest price of being able to play the field is never getting married to one outstanding tool.

The tyranny of choice

The critics of late market capitalism like to latch on to the extremes, like the fact that some malls have individual stores that do nothing but stock thousands of different kinds of socks. While these critics have probably never experienced the joys of late Soviet communism where there was only one choice on good days, they have a point. Making decisions takes time. The tyranny of choice forces us to make spreadsheets and checklists that are reviewed by committees sitting in meetings, all to shave a few fractions of a cent off of the hourly rates.

Juggling changes

Many parts of the cloud are automated commodities that are fairly interchangeable, but there are always small differences that your team has to keep track of. Perhaps one cloud has switched to PHP 8 before the other. Perhaps another is switching the pricing model to penalize outgoing bandwidth. More vendors and more partners mean more email announcements, videoconferences, and — maybe one day — more hype at annual in-person conferences at swish resorts. Aside from the extra fun at the parties, it’s all just more work for everyone on the team. The price of multicloud freedom means eternal vigilance over announcements, press releases, and emails from multiple vendors.

Standard, not standard

Teenagers like to plumb the depths of sincerity with phrases like “kidding/not kidding.” So do standard writers. In theory, the internet is knit together with elaborate and well-specified standards that ensure that everything will be interoperable. There’s often plenty of truth to this, but it’s never perfect. There will always be small difference between your version of Ubuntu or Python, or some other so-called standard, and your code will hiccup or even barf when it discovers it. Spreading your code around multiple clouds increases the chances of finding these tiny differences that somehow manage to appear late on Saturday night or during your vacation.

Latency

Sending packets between machines in the same rack is usually going to be faster than sending them to a different data center on the other side of the world. A multi-cloud strategy is probably going to require longer delays if you’re going to take advantage of those low prices on storage in Antarctica. This isn’t always important. Some packets don’t need to travel quickly. There are plenty of background computations that don’t need speed. But for the main routines that power the most interactive parts of any application, it will help to have the core microservices running in close proximity.

Training multiplies

Investing in one cloud means learning the details and idiosyncratic interfaces of one company’s vision. Investing in multiple clouds means doing this again and again. The team will need to build up expertise again and again. Yes, there are some good options that simplify this. Backblaze, for instance, has a storage API that imitates Amazon’s S3 buckets. But those clones are an exception. N choices means N times the training.

Pricing models muddy the waters

There are few things more like a commodity than a modern instance running a popular open source operating system. While choosing the lowest price per hour seems like an easy metric, there are often other costs that end up mattering. Some clouds, for instance, will charge for data leaving their centers. Others have better rewards for long-term commitments. The pricing models often have multiple axes and you’ll need pretty good estimates to begin to choose the one with the lowest price for you. The products may seem like commodities but the pricing models aren’t.

Lowest-common denominator mindset

Choosing commodity options makes it more likely that you’ll deliver a commodity product. Your team might be able to work magic and add wonderful features to your layers of code, but it’s just a bit harder to exceed when you’re starting with the bare minimum. Many jobs don’t require too much cleverness. Many tasks are better solved by the simplest solution. But for those moments when you’re reaching for the stars, there may only be one best choice. Multicloud architectures tend toward the lowest-common denominator of everything.

Missing out on bulk pricing

Cloud vendors offer big discounts to companies that buy in bulk, especially if they make long-term commitments for years in advance. Remaining agile and ready to jump to a new cloud means avoiding this kind of lock-in and the discounted prices that may come with it. Spreading out your spending over multiple clouds makes it harder to grab the big bulk discounts for the truly large commitments.

The tricky math of trust

It’s fair to be careful of trusting anyone in business. It’s smart to avoid putting all of your trust in one vendor. But playing the field means putting your trust in more entities and that has the perverse effect of multiplying the odds of disappointment or outright betrayal. You may not trust each of your multiple cloud vendors as much individually, but the total amount of trust required to keep things running seems to multiply.

Rising likelihood of legal cracks

One of the advantages of sticking with one provider is that it’s harder for the provider to blame someone else. Imagine that you buy fire insurance from one company and flood insurance from another. If a flood starts an electrical fire, you can bet that both will agree that it’s the other company’s job to pay the claim. Embracing multiple clouds means more than just wading through multiple default agreements and negotiating multiple contracts. It means that it’s easier for gaps to exist between them and it seems easier to fall into these cracks.