I’m worried that many engineering teams are being led down to the river of lower productivity by the Pied Piper of multi-cloud agnostic frameworks. And if you’re also worried about the effect this has on our ability to innovate, read on.
Today, more than 70% of companies have a multi-cloud presence. And many are still running workloads on-premises as well. In response to this increasingly complex environment, companies often try to abstract their enterprise architecture, using a single set of high-level tools and interfaces that (theoretically) make all their applications and operations “cloud agnostic.”
Before I explain why this is a mistake, we need to first understand why companies are moving to multi-cloud in the first place. The days of only three hyperscalers are over. Providers like Tencent, Alibaba, and OVH are all challenging the Big 3 in both features and geographic footprint. In addition, countries are passing data sovereignty laws that require certain data to remain within their physical borders. Simultaneously, computing capabilities continue to migrate to the edge, with the adoption of high-speed, ultra-low latency 5G mobile networks. And finally, to complicate matters more, many companies are adopting a hybrid cloud approach, keeping some parts of their infrastructure on premises, and moving others to the cloud. So, if you want to be at the leading edge of where the world is going, it’s not enough to just be multi-cloud, you have to be cloud agile.
But what’s an engineer to do with this multi-cloud mayhem? Well, you could go all-in on one cloud. But this is a very risky business decision. It limits your access to innovation, makes it difficult to comply with ever-changing data sovereignty laws, and locks you into one vendor for all your computing needs. (Remember, that single cloud provider can see your ingress and egress logs, knows you’re all in, and can price your services accordingly.)
Also tempting is designing a layer of abstraction that strips all clouds down to their most basic offerings: compute, storage, networking. But using the same containers and other multi-cloud frameworks can limit innovation and stifle great engineering, because you lose access to the amazing managed services offered by various cloud providers -- things like specific storage features, instance features, or even whole services, like AI/ML, which just can’t be abstracted. And in the end, you pay premium prices for only the most basic commodity features. It’s like asking your team to win Le Mans, but only allowing them to build a car with only a gas pedal, four wheels, and a windshield.
The CEO of one large investment bank told us, “Multi-cloud is an opportunity for us to unlock the full value of each location, not water things down with abstractions and accept the lowest common denominator.” If you agree with this line of thinking, your cloud strategy should follow these rules:
- First, let the workload dictate which cloud (or clouds) it lives on. There are literally dozens of considerations for choosing where your computing takes place. Geography. Reliability. Compliance. Performance. Let the strategic intent of each workload define the requirements of your cloud computing needs.
- Second, take advantage of the best services possible wherever you can. Yes, there is a cognitive load to using different services on different clouds. If you can use the same service on all clouds (and it’s the best service available to you on all of them), that’s even better.
- Third, focus your teams on great engineering within every environment. And be skeptical whenever you hear the words “agnostic”, “framework” or “generic.” Obviously, good architecture and tools are essential, but don’t let them become the focus of your teams, or you will lose competitive advantage.
Don’t get me wrong. You can abstract away some things. If you have a stateless web app that fits nicely in a container, go for it, and scale the daylights out of it. But that’s a very small part of an enterprise architecture. Provisioning, cost control, security, databases, monitoring, and event management are all crucial, and all different on different clouds. DevOps, networking, and security are the areas where you just can’t have a “one-size fits all” model. And monitoring and incident management require deep environment-specific expertise, or you’re pretty much guaranteed to be operationally mediocre.
As I’ve said before, in the digital economy, our businesses are defined by the applications we offer to our customers, our business partners, and our employees. And the success of our businesses is defined by the quality of those applications, the speed you deliver them, and the quality with which you operate and support them. My advice is to approach your cloud strategy with your eyes wide open, don’t let yourself be swayed by a fad, and do whatever it takes to enable great engineering that delivers value to your customers.
I’d love to hear what you think about my characterization of the cloud landscape, and my recommended approach to cloud strategy. Reach out and let me know what you think, either on LinkedIn or at @MarkLovesTech.