Multicloud's moment: Everybody's doing it, but are you doing it right? Here's eight dos and don'ts
Richard Seroter
Director of Outbound Strategy and Engagement
You've probably embraced multicloud by now. But have you embraced the right services and practices to make the most of each platform and product?
Oftentimes, “multi” is a good thing. Multiple pilots on the airplane? Check. Multiple high-quality candidates for an open role let you pick the best one. That scene in The Wizard of Oz, when they go from black-and-white to multicolor.
But “multi” isn’t always good. Those twenty-page diner menus? Too much choice can cause indecision and delay. Multiple contractors in your house simultaneously doing home improvement can create a lot of complexity and coordination for you to manage.
The same dynamics exist for multicloud.
It can be a good strategy, but may also introduce complexity. And the industry is full of noise about multicloud that can make it hard to know how to proceed. Google Cloud has been at the forefront of this conversation, and with that accrued experience, here’s our view of what works, and what doesn’t.
Why would anyone choose multicloud?
If you are completely happy with your current cloud setup, stick with it. Adding more clouds will always cause more complexity. That said, there’s a reason why 89% of companies have chosen to be multicloud, according to at least one estimate, and they rely on more than one hyperscale cloud.
First off, all clouds aren’t the same. Each cloud provider offers something they’re particularly good at.
This means that some companies choose to be multicloud because they’ve adopt a best-of-breed approach, selecting certain providers for the tasks at which their technology excels.
Sometimes people find themselves in a multicloud situation because of mergers and acquisitions that bring other clouds into their portfolio. There are cases where it’s cheaper or less complicated to keep the acquired business on their existing cloud rather than switch them to another.
We also see companies become multicloud for regional or compliance needs. Whether it’s related to concentration risk, data sovereignty, or latency, some businesses add clouds to satisfy business demands.
Recently we have seens an increasing number of people that are embracing multicloud tools as a way to switch their primary cloud provider. The initial cloud that they chose five to ten years ago was the right choice at the time. But as their needs changed, and more suitable options became available, they wanted to revisit prior decisions. By becoming multicloud, companies make that transition less jarring and give themselves time to adjust their tools, skills, and workloads to the new primary cloud.
Here, multicloud is the journey, not the destination. It’s something we talked about recently at Google Cloud’s Next ‘22 conference, which you can watch here, or jump ahead to the dos and don’ts, which can help you on the multicloud journey, wherever your organization might be.
The do’s and don’ts of a successful multicloud strategy
Whatever your reason, it’s clear that multicloud is part of the IT landscape for the foreseeable future. How can you not just survive, but thrive? For many years, we’ve been building services and helping customers navigate the multicloud journey, and we think we’ve developed a pretty good sense of what good looks like.
Don’t choose multicloud to “prevent lock-in”
There are very good reasons to pursue a multicloud strategy, as outlined above. A not-so-good reason? Preventing lock-in. You can’t do it. Everything is lock-in. Your programming language, CRM system, open source database, proprietary hypervisor, and public cloud are all going to lock you in in some way. You can’t just switch any of them overnight, as you’ve built up processes, skills, and integrations for each. That’s OK. What most folks are trying to avoid is being cemented to undifferentiated or slow-to-change components of their architecture.
Avoid treating the public cloud like a generic pool of infrastructure. You won’t get the expected efficiency, cost-savings, or velocity. Use common components where it makes sense, and differentiated ones where it improves your business outcomes.
Do build an open source foundation
Open source software makes multicloud a more reasonable proposition. Whether popular open source projects like Terraform, Spring Boot, and Apache Kafka, or Google-created technologies such as Kubernetes and Tensorflow, the ability to run powerful software anywhere, independent of the infrastructure, gives you strategic flexibility. As you craft your multicloud strategy, establish bias towards open APIs.
At the same time, think twice before running that open source software yourself. Rather, lean into built-in or partner-operated managed services. Why? You want the interoperability of the open APIs that provide flexibility, security and control, while the expertise of others to run it. For example, you could use open database interfaces, but delivered through Google Cloud's managed services. Or run workloads in a portable way atop expertly managed Google infrastructure.
There are very good reasons to pursue a multicloud strategy. A not-so-good reason? Preventing lock-in. You can’t do it. Everything is lock-in.
Don’t expect to buy complete “multicloud solutions”
I have some bad news: Multicloud is more about the architecture of your IT than any specific products. Nobody sells a turnkey multicloud experience that somehow addresses all the considerations of a modern system. Everyone sells pieces of the stack, and it’s up to you to assemble them in the way that makes the most sense for your organization. Here’s some areas to consider:
Production: How are you securely building, packaging, and distributing your software?
Runtime: What is the host, or hosts, for your commercial and custom-built application?
Operations: What tools are operators using to patch, troubleshoot, and manage infrastructure? Where are you storing logs and metrics?
Data management: How are you storing, securing, and accessing data? Is data replicated between environments, and if so, how?
Identity: What is the source of identity and role-based access controls?
Security: How are you monitoring threats? Storing secrets? Encrypting at rest and in transit?
You want to carefully consider your architecture and which layers you’re building versus buying.
Do pick strategic anchors for stability and consistency
You need to make some foundational bets that span environments. There will be technology that you “lock into” in order to make multicloud more maintainable and valuable. As you do so, it’s critically important to be future-focused. These bets have long-term implications. For instance, are you marching towards the cloud and shrinking your data center footprint? Then your bets should be anchored in cloud-managed services.
Don’t build a Frankenapp out of a hodgepodge of services
The predominant way that companies use multiple clouds is to use each cloud for particular teams or workloads. Your anchor technologies may span clouds (see above), but it’s neither common nor recommended to build systems out of components from different clouds. However, SaaS providers and companies that need highly resistant systems do rightfully put copies of the same system on each cloud.
For cost, security, and performance reasons, aim to keep the majority of your software system in a single environment.
Do choose one of the five common adoption journeys
There’s no one way to become multicloud. We’ve observed five types of journeys, and some companies are doing a portion of each! Some of these are better than others.
Cap and grow. Freeze your initial cloud in place, and invest primarily in the next cloud. This is happening more often than before.
Extend the foundation. Treat the current cloud as the anchor, and “stretch” it to your secondary clouds. It’s a reasonable strategy that helps you keep existing skills in place.
Parallel paths. Intentionally (or unintentionally) grow each cloud independently. This is what often happens in organizations with very independent departments. Long-term, this isn’t the smartest strategy as you’ll end up with significant duplication and complexity.
Selective services. Choose a small number of best-of-breed services from a secondary cloud, but keep growing your footprint in your primary cloud. This is often how people begin their multicloud journey.
Isolation for regional/compliance needs. Add and grow your secondary cloud in specific locations to satisfy the needs of that region.
Each of these paths has benefits and risks. And your choice has a carry-on effect on your staffing, technology choices, and overall architecture.
Don’t lose sight of the developer and admin experience
Your multicloud adventures could accidentally turn into an exercise of architectural purity. While you may design a magnificent platform that somehow runs across clouds and improves your security posture, will anyone use it? Do developers have an easy on-ramp and does it offer a better experience than the alternatives?
The best multicloud efforts keep the developer experience in mind. They look to make these environments useful — not just tolerable. And the same goes for administrators. This new multicloud setup should avoid becoming a management nightmare that can’t be patched or debugged going forward. Simplicity is key! Your developers and admins are your most important constituencies, and we recommend setting up a long-lived platform engineering team that treats your platform like a product.
Do invest in portable skills and practices to “future proof” yourself
In truth, there’s no such thing as future-proofing. No one knows what the future holds. The best you can do is increase your agility so that you can adapt faster than your competitors can.
There are, however, some skills you can develop to gain more flexibility with a single cloud or multiple clouds. Invest in timeless disciplines like architecture (e.g. data, application, and security) and product management. Double-down on infrastructure automation, continuous delivery, and containerization. These will all help you gain maximum flexibility in your cloud journey — which is really what we mean by “future proofing” anyway.
The cloud has largely evolved to avoid the traps of past generations of technology. That doesn’t mean that cloud in general, and multicloud in particular, can’t have traps of its own if not thoughtfully implemented.
