When should you consider a plan to avoid cloud vendor lock-in?
When is cloud vendor lock-in a non-issue?
When talking about using higher level services provided by cloud vendors, cloud-native mind-set engineers may encounter the questions / concerns from management or technical leads, like “Well, we should not use XX technology because that’s vendor specific”, especially in an organization evolving from the traditional computing environment.
To those questions and concerns, I would like to share my thoughts: the ‘if we choose that higher level service, we will have a cloud vendor lock-in problem’ concern and its variants are non-issues for 90% of the cases. And the chances are: your organization’s situation most likely falls into that 90% cases — especially if your product is a service (e.g., an SaaS, or a consumer service) rather than a software stack (e.g., ElasticSearch needs to make sure their stack does not have vendor lock-in problem).
First of all, let’s talk about vendor lock-in from your customers’ perspective
As we mentioned above, there could be two types of service companies
consumer apps, such as Grubhub / Snapchat / Substack — they directly service consumers1
Software-as-a-service, such as Slack / Jira / Datadog — they service enterprise / teams
In neither case, the customers really care about whether your services run on AWS, Azure or GCP. They care about whether their message can be sent smoothly (in the case of Slack); they care about whether their posts and community are well organized (in the case of Substack). In short, as a service provider, being locked into a single cloud vendor has nothing to do with your customer satisfaction or dissatisfaction. In short, it is a non-issue to your customers.
Secondly, let’s estimate and project the cost of “avoiding vendor lock-in”
“Well, we should not use XX technology because that is vendor specific” — I have seen / heard cases varying from building application level authentication stack (e.g., to avoid using AWS Cognito / Auth0 stack) to building / maintaining their own Cassandra cluster solution (e.g., to avoid using AWS DynamoDB). And the engineering resources sucked into those efforts could also vary from several engineers to a dedicated big team. For a company building green field new services, those talents could have been invested into building the core differentiating features — concerning about vendor lock-in prematurely results in a huge opportunity cost.
Moreover, in a lot of cases, the home-grown cloud vendor neutral solution won’t give the business enough mileage either.
Why? Let’s use home-grown identity management system as an example, this article asked a list of questions (i.e., hints) why you may want to ‘buy’ an identity management solution instead of building your own. But someone may ask: why can’t our home-grown solution give us enough mileage at the first place? The answer is: because those are “undifferentiated heavy lifting” (— by Jeff Bezos) — there is no enough incentive for the executives to invest enough resource to make the supporting building blocks really solid.
Therefore the cycle of this route typically ends up with
a small engineering team to do this “undifferentiated heavy lifting”, showing its initial success;
the home-grown service can’t keep pace to the business requirements (e.g., see the identity management use cases example);
the team asks for more resource to keep up with the business requirements;
no (enough) resource approved and engineers owning those service feel pains / pressures;
totally rewrite the service because it starts impacting the business (or switch to higher level service provided by cloud vendors)
I had a chat with an engineering leader who runs a team of several hundred people and they are switching from an self-hosted open source NoSQL DB cluster to DynamoDB
In short, the level of investment most likely can’t and won’t justify the vendor neutral “benefit”, for 90% of the cases.
Note: Here I mentioned AWS technologies as example since I and a circle of friends who I often talk to are exposed to AWS stack; but I by no means advocate AWS as a vendor, instead, I am pretty sure the same conversation is bound to occur in other cloud vendor context, such as Azure and GCP.
Lastly, can we really get out of vendor lock-in?
Let’s say a company building an SaaS product and uses Stripe as their payment system, is it locked in to Stripe? And do we want to build our own payment gateway system avoid this “lock-in”? For this specific situation, the answer to most of us (if not 100%) is obvious and the decision is a no-brainer for two reasons:
we know we can’t possibly build such system without significant engineering investment;
we really don’t care being “locked-in” by Stripe because payment is not our core business — we just need a tool to collect the check for our service;
So in modern service building process, we are vendor locked-in one way or the other anyway. If this is the reality, then why worry about the hypothetical problems and pay a huge opportunity cost, instead, focusing on our core differentiating intellectual properties?
Is the above thought process related to your situation?
Are you or your management concerned about the being “vendor locked-in” problem? If this article touches upon some of your internal discussion topic, please feel free to share it with people who may feel strongly about it to start a healthy discussion?
Substack is the service we are using as this niche-community idea sharing endeavor