Evolution of cloud provider-agnostic solutions

An engineer or manager who can apply themselves to a range of technologies or conceptual frameworks can be useful in multiple domains and can possibly command higher salaries. A polyglot software engineer, for example, is said to be proficient in several programming languages. In computing, the term agnostic is used to indicate compatibility across many types of technologies. For example, a codebase can be implemented to be database-agnostic.

With this in mind, I suspect there will be value in building systems that are cloud provider-agnostic. As such, cloud providers will need to respond to this demand and will evolve as indicated on the map.

Agnostic Landscape in 20201696×1220 223 KB

Do you agree? If not, please update the map in the OnlineWardleyMaps editor to reflect the current state and what you anticipate happening:

https://onlinewardleymaps.com/#clone:Kh9fQ8rwyFk3R3ME2Z

I partially agree.
Yes, Kubernetes is already evolving as the cloud-agnostic runtime on which applications can be run.
No, because refraining from using cloud provider-specific technologies leads to a least common denominator result that will hurt your performance compared to others who fully embrace everything a particular cloud provider has to offer.

Thank you for your thoughts @rsinnema1. I’m interested in exploring your last point.

The benefits of cloud-agnostic solutions extend to exit strategies. Say, you are looking to acquire a business and there are two identical candidates. The only difference is one is cloud-agnostic and the other is locked into one particular cloud provider. Which business would you acquire?

My belief is that that will never happen. The fact that one business is cloud-agnostic will affect it in ways that the other won’t be and vice versa.

Many people have written on the pitfalls of cloud-agnostic solutions. See e.g. https://www.thoughtworks.com/radar/techniques/generic-cloud-usage or https://www.itproportal.com/features/why-enterprises-shouldnt-worry-about-public-cloud-vendor-lock-in/.

If you don’t believe it is likely, that would suggest the map above is invalid?

Another way of looking at vendor lock-in is in the form of technical debt. All cloud services will have a life cycle and an adoption curve. Cloud services are of course managed. If you are locked in to one particular cloud provider service then there are two levels of debt. One level has to be serviced by the cloud provider in the form of legacy service support and maintenance. The other level of debt has to be serviced by the users of the legacy service. These users will also have an additional problem, diminishing capabilities and difficulties recruiting engineers with the right skills to maintain a solution built on the legacy cloud service.

It seems inevitable that cloud providers will need to offer better support for cloud-agnostic solutions moving forward.

I’ve been thinking about cloud provider-agnostic tools a lot lately as well and I like the map a lot. These are just some unorganized thoughts:

1. Why are provider agnostic solutions good? Because it reduces exposure to extreme events. Eg. merchants who only have sales channels through Amazon are in quite a pickle now, because Amazon experienced a squeeze on its shipping infrastructure due to the COVID-19 crisis and restricted the shipping of some items. There is no guarantee that AWS will not experience a similar squeeze on its data centers at some point, so having provider-agnostic tools can reduce outages from weeks to hours or days in the face of such an event.
2. The trend towards managed cloud services makes building cloud agnostic stacks harder. A LAMP stack app only needs a VM from the cloud provider, while a serverless app will consume dozens of cloud services.
3. A counter to this trend is IaC: If all dependencies are in code, it’s possible to build constructs on top of those dependencies that abstract away the cloud provider.
4. There are some emerging standards between the serverless offerings of cloud providers:
   • HTTP APIs for SQL databases
   • JWT based access to APIs
   • what else?

Thank you for sharing your observations and thoughts @agostbiro

I agree, practical needs will drive the shift from emerging to accepted. Cloud provider-agnostic solutions will be more resilient and offer options for reducing technical debt.

A promising example of cloud providers cooperating on standards is ONNX.

Thanks, ONNX is a great example!

One more though re evolutionary drive:

In Wardley maps, we usually understand evolution as a commodification process with a first mover advantage for moving a component from product to commodity. AWS has been a master of this, but of course their solutions come with lock-in. However, the evolution of cloud provider-agnostic products is actually a commoditization process through which the differences between cloud providers are diluted. So I expect this play from either a new entrant or from a cloud provider in a losing position, but definitely not from AWS.

An analogy is relational algebra and SQL. A database (cloud service) can be SQL compliant (agnostic) but can also include vendor extensions. The risk (or technical debt) is how much of those extensions should you consume to gain a competitive advantage.

Being cloud agnostic has costs as well as benefits. I don’t dispute the benefits, but I think you leave out the costs. If I can’t use BigTable on GCP because AWS doesn’t also offer it, then I have to introduce an abstraction layer. It is very expensive to build and maintain such a layer. Also, this layer can only use those features of BigTable that AWS offerings also have. So now I"m missing out on the cool stuff and I have to maintain a heap of software myself. The economics simply don’t work out.

The only time I see this working is when the abstraction layer is defined by an independent 3rd party, like with Kubernetes. This will only be commercially viable in rare cases, IMHO.

@rsinnema1 thank you for your comments about costs.

Google Bigtable is nearly 16 years old. My first question would be, why don’t other cloud providers offer a compatible solution?

Cloud providers generally offer commodity compute and services. Depending on the context, your example, Bigtable, may actually belong in the product (+rental) space of a Wardley map. As there is only a single provider it would not make any sense to add an abstraction layer here.

As a practitioner, I would still argue that not striving to be cloud agnostic will have longer term costs in terms of career progression.

Likewise, multicloud deployments are likely to be more resilient and more capable of adapting to changing user needs and responding to competitors. I would not like to predict the costs of ignoring these factors.