Multicloud architectures make sense in many situations. However, there are also hidden costs and problems. […]
Cloud computing is like a digital cornucopia of possibilities. And if the options of one cloud provider look good, why not use those of two, three or a variety of providers?
There are many good reasons for multicloud architectures: more cloud instances also means more APIs, more locations for data centers, and an even longer list of available AI algorithms (which may work). As soon as new improvements are incorporated, a team of specialists is ready, who are certainly agile enough to squeeze the optimum performance out of every little bit. In addition, multicloud architectures are often about preventing vendor lock-in. Because when the end of the contract approaches, prices often rise-unless you toying with an offer from the competition. In such cases, a multicloud strategy greatly facilitates the rapid change of provider.
However, the mentioned benefits are not in vain. Agility and flexibility also have a dark side, which sometimes only shows up after weeks, months or even years. We’ve rounded up some of these dark multicloud secrets for you.
Many components of modern Cloud offerings are pure Commodity. Each one sells instances with variable RAM sizes and your favorite Linux distribution. Between the everyday options, however, there are often really useful, mostly proprietary tools – for example Oracle’s database, Google’s Firebase or Microsoft’s .NET stack, to name a few .
A multicloud approach can make it difficult to get the most out of all the tools available because it’s usually hard to duplicate some of them in other clouds. Then you may have the option to quickly switch from one provider to another – but you may miss out on some really useful features or tools that would be able to move your business forward.
Making decisions takes time. An excess of choice ensures that spreadsheets and checklists are prepared, which in turn must be evaluated by decision-making committees in elongated meetings. And in the end, all the effort leads to the fact that your company saves costs in the cent range. If anything.
Many Cloud components are relatively interchangeable. Nevertheless, there are always small differences that your cloud team should always keep in mind. Perhaps one cloud instance has already been switched to PHP8, another has not. Or another instance is switched to a different pricing model because the outbound traffic was too high. More providers and partners always mean more coordination effort, which the entire team has to bear. So if you want to enjoy the Multicloud benefits, you must also be able to keep track of the associated product announcements, changes, press releases and emails.
In theory, the Internet is held together by elaborate standards that ensure that everything is interoperable. This statement is true in principle, but not one hundred percent. There are always tiny differences in your Ubuntu or Python version and your program code will “swallow” at them when they become apparent. Spreading your code across multiple cloud instances increases the chance of these small differences coming to light-preferably on the weekend or during your vacation.
Sending data packets back and forth between machines in the same rack is usually faster than sending the same packets to another data center at the other end of the world. So if you want to benefit from the particularly low storage prices in Antarctica, you may also have to expect longer delays.
Latency is not always important – some data does not have to be sent very quickly. Also background calculations do not necessarily need a lot of speed. But it makes perfect sense to run your core microservices in your local area.
Investing in a cloud means getting to know its details and interfaces. Investing in many clouds means playing the same game multiple times. So your team has to build up expertise not just once, but many times. While there are some options to simplify this process – the Storage API of Backblaze, for example, which mimics Amazon S3 buckets. However, such tools are the exception rather than the rule. Multicloud also means multiple trainings.
Choosing the cheapest price per hour is obvious when choosing the cloud instance. As a rule, however, other costs arise, which can be lapping up in individual cases. For example, some cloud offerings charge for data leaving. Others offer particularly favorable conditions for a long-term bond. All cloud pricing models are very diverse-to find the cheapest offer right away, one look is not enough, unless you are lucky.
Commodity options lead to a Commodity product. Maybe your team is on Zack and adds more code layers that realize great, new features. But this is tedious if you only start with the absolute minimum when it comes to the cloud. There are various cases where it works well to rely on the simplest solution. If you want to get started with the cloud and achieve long-term success, you should refrain from this approach. Otherwise, your multicloud architecture is nothing more than the lowest common denominator.
As a rule, cloud providers offer more or less fat discounts for companies that act as bulk buyers and want to bind themselves for several years. They escape those companies that want to resist vendor lock-in with agility and prefer to spread their budget across many cloud instances.
With trust, it’s one thing: Of course, there’s nothing wrong with not wanting to put the fate of a company in the hands of a single cloud provider. On the other hand, the multicloud approach means that you put your trust in multiple providers-which potentiates the potential for disappointment.
Relying only on one cloud provider has the advantage that it becomes more difficult for them to take responsibility for any problems. Imagine that you take out fire insurance, and with another insurer – one against water damage. Then, if a fire causes water damage, you can bet that the insurers will see the bringing debt with each other.
Driving a multicloud strategy means more than digging through the standard clauses of multiple contracts: it promotes the emergence of legal gaps between these contracts. You should make every effort to close them as much as possible. (fm)
This post is based on an article from our US sister publication CIO.com.
* Peter Wayner writes for our US sister publication InfoWorld.com and is the author of several books – among others on the topics of open source software, autonomous driving and digital transactions.