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.

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

1 Like

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.

1 Like

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.

2 Likes

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.

1 Like