Kapernikov enables Umicore to increase plant capacity
Kapernikov helped Umicore to make its precious metal recycling processes more efficient. This enable ...
At Kapernikov, we build robust, scalable and cost-efficient cloud-native data platforms and applications. When we start discussing architecture, vendor lock-in is a topic that keeps popping up. This article describes our vision on cloud vendor lock-in.
The big cloud vendors now offer a huge number of building blocks for building your data platform (both Amazon AWS and Azure cloud claims to offer over 200 products/services, with google cloud listing over 100 products on their summary page). Some of them are basic infrastructure (a virtual machine or data storage), and some of them are value-added services that offer a lot of functionality (an IoT gateway).
In addition to this, independent software vendors also have their offering on the public cloud: you can provision software from Confluent, Databricks, Ververica on all major cloud providers.
For a lot of these value added services (but not all), a self-managed (sometimes open source) alternative exists, that offers functionality comparable to the SaaS versions. However, this shifts the burden of maintenance, monitoring and upgrades on your team.
This makes for a huge solution space: for every component of the software architecture you are designing, multiple options are available on all public clouds. The optimal choice depends on a lot of factors. Avoiding cloud vendor lock-in is one of them.
In order to answer the question “what about cloud vendor lock in”, we need to:
Let’s dive in.
Vendor lock-in, as defined on Wikipedia, makes a customer dependent on a vendor for products, unable to use another vendor without substantial switching costs. With cloud vendor lock-in we mean the inability to switch to another cloud or technology vendor.
There are several reasons why vendor lock-in can be problematic:
Apart from these reasons, cost savings (due to pricing differences) are often cited as a reason to avoid cloud vendor lock-in. In our experience, costs savings alone has rarely been the motivation to switch from one cloud vendor to another one.
Note that cloud vendor lock-in isn’t all that new: vendor lock-in exists for much longer than cloud vendor lock in. Cloud vendor lock-in isn’t worse than “traditional” vendor lock-in, but with the advent of the cloud, we have much more tools at our disposition to fight lock in than we had before.
The question of avoiding cloud vendor lock-in is hence a question of limiting the cost of switching to a different cloud or technology vendor.
In order to understand what is the risk of a vendor lock-in, we must first ask ourselves how desirable the ability to switch (for the whole cloud vendor or for a specific component) might become in the future. This can be hard to predict, but here are some questions that can help you:
Answering these questions might help to judge the importance of avoiding vendor-lock in. The decisions are mostly made case by case. For instance, suppose that you are developing what will become the core innovative product of your company. In that case, avoiding lock-in can be very important (for reasons listed above), but maybe there is one cloud SaaS service from one of the vendors that is unmatched in relevant functionality, and not using that service would hamper the product or be a huge cost to put in place yourself.
Dealing with cloud vendor lock-in or independence is not something you do or don’t, but it is a trade-off you make, balancing the risk of being unable to switch with the extra costs a cloud-vendor-independent solution might impose. Doing so needs a good understanding of what risks and what costs we are exactly balancing, as well as a clear view on the positioning of the software you are trying to build.
Cloud technology selection can make the difference between a failure and a successful platform. However, it is difficult, because you need to take into account the risks and costs and also the team skill-set, the need of the organization to standardize on a portfolio rather than a single product, and the existing relations with software vendors and integrators.
Kapernikov has helped various small and big organisations navigating this trade-off. Are you also building a cloud platform, and do you need help ?