Cloud Lock-In and Change Agility
TL;DR Don’t Focus on Lock-In Insulation — Focus on Change Agility
We are entering into a future of lock-in. Public clouds are no longer someone else’s computers or hosted services. These are fast becoming proprietary platforms with a bit of open source sprinkled in here and there. Almost everything you need to run an enterprise is now available as a pay-as-you-go platform on AWS, and Azure and GCP are not staying put.
As difficult as it may be to swallow and accept this trend, it is important recognize that, anything that needs to be procured or downloaded, built, run, operated and maintained is up for lock-in. In this future, all the infrastructure primitives, software lifecycle automation services (including containers and cluster managers), what was once known as middleware, data processing platforms, the mechanics used for security and operations, as well as the all the enterprise data will be locked into to a few public clouds.
I don’t expect any enterprise to successfully operate on, or migrate to a public cloud and yet remain insulated from the cloud provider’s platform lock-in. Sure, there are several open-source and closed solutions (for instance, those in the container, cluster management and PaaS area, big data processing engines etc, various relational and non-relational databases etc.) that aim to help you stay agnostic. But such platforms insulate you at-best from just the mature aspects of these cloud platforms, such as, say the IaaS layer. But none of these help you participate in the massive platform shift happening in public clouds. When you consider this shift, lock-in insulation is like having the cake and eating it too. You can’t take advantage of all the new capabilities to innovate for your business while staying agnostic to the platform.
In this lock-in future, techniques of the past decade and half, such as open source and abstraction layers, won’t insulate us from lock-in. This does not mean that open source, open interfaces and open protocols don’t matter. They do, and will continue to matter to drive a culture of open coding, sharing, learning, collaboration, and interoperability. But not necessarily for lock-in insulation.
So, what’s the answer then?
The answer, in my view, is practicing change agility. Change agility is an organization’s culture of continually practicing significant changes.
During the last fifteen years, most enterprises reacted to lock-in concerns by over-investing in abstractions, whether it be programing frameworks, parsers, databases, communication protocols, application servers, cloud providers, you name it. At the end of it all, what’s left was was past regrets and large difficult to change monoliths. Those abstractions, in effect, did nothing other than contributing to a culture of change resistance.
A culture of change agility on the other-hand deals with changes as a matter of course and not as impediments. It embraces techniques like service orientation, asynchronous and decoupled communication patterns, micro-architectures, experimentation, failing fast, tolerance for mistakes, constant feedback and continuous learning.
An organization adept at change agility does not see lock-in as an obstacle. It sees it as an opportunity to learn, experiment, and partake in creating its own future. Not just once, but continually.
