How to succeed in a multi-cloud world

Why do we use more than one solution to solve a particular need? Based on organisational dynamics and current customer demands, you would have a few solutions to any given problem. Furthermore, it’s happening again with public clouds, as the statistics show that most of you are using more than one provider.

All public clouds aren’t the same. There’s a commonality amongst them: every public cloud provider offers virtual compute, storage and networking along with middleware services like messaging. However, 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. The user experience including 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. However, you don’t need to 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 a few high-level advice to consider as you think about how to approach multi-cloud. Remember that there’s no universal right solution, only the right solution for your organisation, right now. 

Keep your primary focus on portable skills

Your software isn’t defined by your choice of cloud. Most of what it takes to build great software transcends any given deployment target.

What software development skills that truly matter? 

• Go deep on one or more programming languages. Really understand how to write efficient, changeable and testable code. 
• Optimise 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. 

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, organisations 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 organisations, Kubernetes is the start of their TVP. It offers a rich, consistent API for containerised 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.

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. 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

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 upfront. When do 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.
• You need to host your application in a specific geography and thus choose a specific cloud, data centre or partner facility.
• Your app must sit next to a specific data source such as SaaS systems, partner data centres and 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.