You do you: How to succeed in a distributed, multi-cloud world
Richard Seroter
Director of Outbound Strategy and Engagement
Why do we use more than one thing to solve a particular need? Sometimes we don’t have a choice. All my financial assets aren’t in one place because my employer-provided retirement account is at a different financial institution than my personal account. Other times, we purposely diversify. I could buy all my clothes at one retailer, but whether it’s a question of personal taste, convenience, or just circumstance, I buy shoes at one store (and often different stores for different types of shoes), shirts at another store and outerwear somewhere else.
Is it the same situation within your IT department? Based on organizational dynamics, past bets on technology, and current customer demands, I’d bet that you have a few solutions to any given problem. And it’s happening again with public clouds, as the statistics show that most of you are using more than one provider.
But all public clouds aren’t the same. To be sure, there’s commonality amongst them: every public cloud provider offers virtual compute, storage, and networking along with middleware services like messaging. But each cloud offers novel services that you won’t find elsewhere. And each operates within different geographic regions. Some clouds offer different security, data sovereignty, and hybrid capabilities than others. And the user experience—developer tools, web portals, automation capabilities—isn’t uniform and may appeal to different teams within your company.
Using multiple clouds may be becoming commonplace, but it’s not simple to do. There are different tools, skills, and paradigms to absorb. But don’t freak out. Don’t send your developers off to learn every nuance of every cloud, or take your attention away from delivering customer value. You do, however, need to prepare your technical teams, so that they’re prepared to make the most of multi-cloud. So what should you do, as a leader of technical teams? Here is some high-level advice to consider as you think about how to approach multi-cloud. And remember, there’s no universal right solution—only the right solution for your organization, right now.
Keep your primary focus on portable skills
Your software isn't defined by your choice of cloud. That's probably blasphemous to say, coming from someone working for a public cloud provider, but it's the truth. Most of what it takes to build great software transcends any given deployment target.
What software development skills truly matter?
Go deep on one or more programming languages. Really understand how to write efficient, changeable, and testable code.
Optimize your dev environment, including your IDE, experimental sandboxes, and source control flow.
Learn a frontend framework like Angular or Flutter.
Grok the use cases for a relational database versus a schema-less database.
Figure out the right ways to package up applications, including how to use containers.
Invest in modern architectural knowledge around microservices, micro frontends, event stream processing, JAMstack, APIs, and service mesh.
Know how to build a complete continuous integration pipeline that gives your team fast feedback.
This is valuable, portable knowledge that has little to do with which cloud you eventually use.
Don't get me wrong, you'll want to develop skills around novel cloud services. All clouds aren't the same, and there are legitimate differences in how you authenticate, provision, and consume those powerful services. An app designed to run great on one cloud won't easily run on another. Just don't forget that it's all about your software and your customers. The public clouds are here to serve you, not the other way around!
Use the "thinnest viable platform" across environments
Too often, organizations put heavyweight, opaque platforms in place, and hope developers will come and use them. That's an anti-pattern and companies are noticing a better way.
The authors of the book Team Topologies promote the idea of Thinnest Viable Platform (TVP) to accelerate development. In many organizations, Kubernetes is the start of their TVP. It offers a rich, consistent API for containerized workloads. It could make sense to layer Knative on top of that TVP to give developers an app-centric interface that hides the underlying complexity of Kubernetes. Then, you might introduce an embedded service mesh to the cluster so that developers don’t have to write infrastructure-centric code—client-side load balancing, service discovery, retries, circuit breaking and the like. (Note, if you combine those things, and mix in a few others, you get Anthos. Just sayin’).
But what’s really powerful here is having a base platform made up of industry-standard open source. Not just open source, but standard open source. You know, the projects that a massive ecosystem supports and integrates with—think Kubernetes, Istio, Envoy, Tekton, and Cloud Native Buildpacks. This allows you to run an identical platform across your deployment targets and integrate with best-of-breed infrastructure and services. Your developers are free to take the foundational plumbing for granted, and steer their attention to all the value-adding capabilities available in each environment.
Pick the right cloud (and services) based on your app's needs
Let's recap. You're focused on portable skills, and have a foundational platform that makes it easier to run software consistently on every environment. Now, you need to choose where the software actually runs.
Your developers may write software that's completely cloud-agnostic and can run anywhere. That's hard to do, but assuming you've done it, then your developers don't need to make any tough choices up front. When might you need upfront knowledge of the target environment? A few examples:
Your app depends on unique capabilities for AI, data processing, IoT, or vertical-specific APIs—think media or healthcare.
You need to host your application in a specific geography, and thus choose a specific cloud, datacenter, or partner facility.
Your app must sit next to a specific data source—think SaaS systems, partner data centers, mobile users—and use whatever host is closest.
Have a well-tested decision tree in place to help your teams decide when to use novel versus commodity services, and how to select the cloud that makes the most sense for the workload. Choosing the cloud and services to use may require expert help. Reach out to Google's own experts for help, or work with our vast network of talented partners who offer proven guidance on your journey. The choice is yours.
