Before delving into what I mean by Platforms as pets and Cloud as cattle, let’s look at the journey of Cloud over the past decade.
It’s been more than a decade since the major Cloud providers launched their services. AWS in 2006, Google Cloud Platform in 2008 and Microsoft Azure in 2010.
The advent of the Cloud allowed our economies to thrive. Infrastructure costs went down and productivity went up. Services became more reliable. The Cloud democratised the ability to launch new products and services without upfront capital.
When the major Cloud providers started offering their services, customers who opted for a Cloud-native / Cloud-first approach built their entire infrastructure on the Cloud provider of choice and many still do.
While building entire platforms on the Cloud allowed service providers to maximise their profit and improve their customers experience, they also led to vendor lock-in.
The problem with vendor lock-in
The highly specialised plethora of services available on the major Cloud provider platforms meant that if one, say, was using S3 or Lambda or Kinesis for their products and services, they could only operate on AWS. Similar situations could be found with all the major Cloud providers and the specialised services they offer.
You might ask: OK, so what’s the problem? My business can run smoothly on a single Cloud provider and I can rely on High Availability/High Reliability, right? Well, not quite.
The problem is the same encountered with coupling in software development. Use runtime dependencies instead of offering and consuming APIs and you’re headed towards dangerous waters due to the rigidity of the architecture.
What happens if you experience a fallout with your Cloud provider of choice? If one or more of the services you’re using disappears? What happens if they become too costly or if other Cloud providers offer a better version of that service? If the strategy has been one of “all-in”?
Platforms to the rescue
From managed databases to storage to Serverless architectures, to messaging and queues, notification services etc., we’re witnessing a convergence of Cloud services in the capability they offer. As an example, today one can deploy Kubernetes containers on AWS EKS, GCP GKE and Azure AKS and the same is true for many other services.
From the point of view of the developers, they need a capability, not a particular service branding. For example, if one wants to deploy an API on a gateway where a serverless function provides the fulfilment logic using Node.js, what difference does it make whether is AWS or GCP or Azure which offers such capability?
From the point of view of the developer, what matters is that they get access to the capability they need in a consistent way. Imagine developers who could get access to such capabilities in a Cloud agnostic way. They could access, say, Container / Storage / Managed Databases / Serverless / Gateways capabilities without knowing or caring which underlying Cloud service they’re using under the hood. Platforms offer such advantages.
Platforms have several advantages
With the exception of niche services that Cloud providers offer, or where a particular Cloud offering towers over similar services that other competitors offer, Platforms have several advantages over Cloud Native services:
- They offer a consistent user experience.
- They can operate in pretty much every market across the world, regardless of data restriction policies
- For the regulated Financial Industry, they provide exit strategies, without causing business interruptions in disaster recovery scenarios
- They allow for a quicker time to market. If developers need to learn a single platform vs various Cloud-specific services, they will become more efficient. Not only in the delivery of such products, but also in their maintenance
- They allow to choose best-in-class services from different Cloud providers
Cloud services today are becoming so reliable that they effectively be considered as elastic infrastructure. My view, therefore, is that we should treat Platforms as Pets and Clouds as cattle.
How to go about building Platforms?
One of the greatest outcomes that CTOs can deliver as part of their functions is to lead the delivery of a Platform that offers developers the required capabilities in a Cloud agnostic way. One of the toughest questions to answer is: who should provide such Platform? Should businesses build or should they buy?
I think the answer lies somewhere in between. There are vendors that provide platforms that offer a specific set of capabilities, e.g. API management, AI, Data Management, etc. Platforms offering high-quality Cloud agnostic capabilities are preferable to building the same capabilities internally. However, experience suggests that to be good, a platform must specialise in one thing and do it well.
If developers require heterogeneous capabilities, businesses can build a Platform-of-Platforms, a wrapper that stitches together each of the underlying Platform capabilities in a Cloud-agnostic way and offer it as “The Platform”. I think this space will become more relevant as time progresses and Cloud services continue to improve to a point that there won’t be much differentiation anymore.
From a commercial, regulatory, architectural and engineering perspective this makes sense. Everybody wins.
I hope you enjoyed this article and I’d be interested in hearing your views.