Cloud Vendor Lock In Conundrum
The whole world and its infrastructure are moving into Cloud at a rapid pace in the last decade. The speed and frenzy of this transformation have caught everyone by surprise. From small start-ups to large companies/governments, there is significant migration to the cloud from existing on-prem infrastructure.
Building Innovations on the open standards
The same is the case with the backend. Java is nowadays less preferred due to Oracle’s trying to milk more money. People are gravitating towards more open source stuff with Python, Node, Go and other programming languages. Even from the database perspective, Postgresql is emerging as the de facto standard along with MySql. In the relational world, MongoDB / Cassandra etc. as well in the No-SQL world. All this resulted in championing the idea of open source and driving innovations on top of them. One significant outlier in this trend is the mobile app ecosystem where Apple and Google dictate the way around how apps have to be built. Some of them are necessary to ensure privacy, security, but at other times, it is to have control over the ecosystem.
Skirmishes between Public Cloud Providers and Open Source
Then the cloud happened. Whatever open-source innovations that we build need infrastructure and hosting. This resulted in public cloud providers rolling out new and interesting products. These help fuel interesting awesome ideas. The pace of innovation by the big public cloud vendors to incrementally roll out new products and updates. This makes it difficult to pause, reflect and think of open standards, vendor lock-in and portability.
Added to this, cloud providers take many open source innovation and add their infrastructure and sell it as managed services. Generally, the open-source community thrive by offering the product free but make money with consultancy. But the cloud providers are taking up this pie. This has resulted in open source companies changing their models. Companies like MongoDB, Redis and few others have rolled out newer features only on their managed services. This is to prevent cloud vendors from taking advantage of their hard work.
What Vendor Lock-in means in the context of cloud?
So what does vendor lock-in mean in the context of the cloud? Choosing a public cloud provider’s services that are not based on standards. They are also not portable to other cloud providers. Infrastructure As A Service ( IAAS) is the foundational layer that exists in all cloud providers. IAAS offer bare-metal servers. Building solutions with these servers is the safest and easiest way to avoid vendor lock-in. But this also means we would not be able to leverage all the innovations rolled out up by cloud providers. Hence a more nuanced way of approaching the vendor lock-in situation.
As we stand in 2020, here are the major pros and cons that are there with Cloud Vendor Lock-in. This is not different from the previous decades of choosing an IBM or Oracle or Microsoft stack of products. Like the famous saying, no one gets fire for choosing IBM, it is now, no one gets fired for going with AWS.
Advantages of going with a single vendor approach for Cloud
- Easier management of products, services, support and effective governance. This is a major advantage.
- Better integration between the vendor products could result in fewer complexities and overheads.
- Cloud Products may not build with open standards in mind. But building solutions on top of new products offered by cloud services would result in bringing products to the market faster. This can lead to cost savings with reduced maintenance, monitoring and support.
Issues associated with Vendor Lock-in
- Companies tie-up with the vendor and are at the mercy of the vendor for pricing. One change in the pricing by a few dollars could result in a huge cloud bill. This can make or break companies, especially in the start-up world.
- When a particular cloud vendor is being evaluated, there might not have been a significant cost difference. But over time as the other vendor reduces the price, the option of taking advantage of cost reduction by moving to other vendors may not be possible. Due to tight integration between products, negotiation for better deals/discounts may not be possible. Some companies that use core products offer mild threats to cloud vendors about porting out to other companies. This helps them to negotiate better deals and that is no not possible.
- There is no easier way to migrate unless there was a conscious smart decision taken during the initial architecture and design phase. This can help to reduce the impact of the lock-in. Migrate to a new cloud in worst cases could very well be a re-write.
What does it mean to avoid vendor lock-in? Multi-cloud.
Building solutions that can be run on multiple cloud providers. For large companies at the scale of Google, Microsoft, Uber, Netflix etc., the multi-cloud makes absolute business sense. It looks like a no-brainer that multi-cloud must be the default mindset. But the challenge of building solutions already in the cloud is pretty complex. The multi-cloud approach would take up significant time and resources to manage such a complex setup.
Even though Cloud has been there for a decade now, companies are only now adopting at a large scale. Resiliency, Availability and Recovery designed at a region level amongst multiple availability zones and cross-region availability. Management of resources is already proving to be a challenge with cost and associated overheads. With so many complexities even in a single cloud setup, the multi-cloud approach should be carefully considered. Unless otherwise there is a strong business case to move multi-cloud, this is not recommended for all.
So how to think about Vendor Lock-In and ways to reduce it
1. Design applications with a hexagonal architecture
Hexagonal architecture has a layered approach. The business logic and entities are core to the system. Adapters and Controllers are a way to interact with these objects. The technology and vendor components at the peripheral layer and can be replaced easily.
For example, if we are to use Amazon DynamoDB, do not introduce DynamoDB and its interaction in every layer. Any and every part of the application needs to connect to a data layer to get data in a standard way. This data layer will be the only layer that talks to DynamoDB. To replace DynamoDB, the data layer contract would not change. Application components would continue to talk to the data layer in the same way. But the implementation at the data layer may change to talk to MongoDB instead of DynamoDB. So a conscious approach of clever design and architecture could help us deal with this problem better.
2. Choose services from other cloud vendors when they deem fit
Depending on the use-case, if there are few services from other good cloud vendors, choose them. For example, Google Cloud may offer better services like Machine Learning / AI etc. Even though an organization may be currently all in AWS, it would make sense to choose Google Cloud for the use-case and make the best use of it. Even though the resulting overhead and complexities may be extra, it would still make absolute business sense.
3. Think of workflow portability
Instead of designing for workload portability, workflow portability can help. For example, the choice of Infrastructure As Code ( IAC ) for AWS could very well be Terraform instead of AWS’s own Cloud Formation. With Terraform, there may be more work required to write scripts for another vendor stack. But there is a way to manage and re-use the workflow within Terraform for multi-cloud scenarios.
Standards and Interoperability in Cloud World may take a long time
Standards and Interoperability may not be the focus for market-leading cloud vendors like AWS or Microsoft. They would want customers to be in their offerings. There is no incentive for these companies to think of standards. It is with vendors like Oracle, IBM Open Shift pushing the multi-cloud and standard offerings. It is their only way to stay relevant in the market. Google Cloud and others champion Kubernetes and containers and often claim how it helps to avoid vendor lock-in. But then running Kubernetes is going to take significant resources.
Implementation of Resources Identity, Access and Security Policies are different with every vendor. Cloud Security is a big focus area for all companies. Dealing with security in a multi-cloud setup would make things even complex. If AWS comes up with Lambda, Google comes up with Cloud Run which based on open standards of Docker though some aspects of it may not be open at all. Google Cloud tries to champion the K-Native movement as well. But no one else seems to be marching behind this idea. So there is no point in choosing services that have open standards and are portable at this point. Cloud adoption is still maturing and it may take a while to get there.
So what should we do in 2020? Go All-in with a single cloud provider
Every tech company would want to retain or lure the pie from others to increase their revenue. And the approach of each vendor is mostly self-serving. It becomes necessary to consider all these points and build architecture in a way that it is easier to port the applications. There is no point in not building services that are cloud-native leveraging all good innovations in the cloud just to avoid vendor lock-in. Every extra line of code written or the extra server that we manage will always incur a cost, be it resources, maintenance and management.
The yearly IT spend of organizations is currently around 1.8 trillion dollars. Cloud vendors have a together annualised run rate of 80 billion dollars. There is enough pie for all cloud providers to grow and hence would not be particularly looking to increase the cost. For the next 5-10 years, Vendor lock-in would not matter as the cloud adoption is still evolving and everyone is figuring out this beast. So unless otherwise there is a clear business case, I would not urge anyone to think of multi-cloud or vendor lock-in. The focus must be building applications to wow customers and end-users. This includes smart architecture and design choices that can help in porting out to another vendor if the situation demands.