Vendor Lock-In and Serverless doesn’t really exist

… for most people.

One of the biggest problems that often comes up when people talk about looking into Serverless solutions is vendor lock-in.

Vendor lock-in is the idea that the you are essentially building a solution on top of the services provided by a cloud vendor, and that it’s hard to lift and shift to another cloud provider in future (for whatever reason).

The thing is that there’s a fundamental problem here.

It’s just not a thing that really happens (in most cases)

The only time it really matters (in my experience) is if the company itself has a business requirement to have multi-cloud vendors as part of the mix.

It’s never a technical requirement to have multi-cloud.

It may be a technical requirement to have your solution across multiple data centres.

So when you’re talking about multi-cloud the first question I’m going to throw back is “What is the business requirement?”

And to be clear, the big cloud vendors aren’t going anywhere, so you are unlikely to be either thrown off (they want your money) unless you egregiously break their terms and conditions (which is possible, but pretty hard to do without being intentional).

What does it mean to be Serverless and Multi-Cloud?

Most of the time, what people mean is that they want to abstract their “solution” so that it’s completely able to be run on more than 1 cloud provider’s systems.

Which is fine.

But then if you’re running two data sources, how are you ensuring consistency?

Do you have two data sources?

Nightmare scenario. Why would you do that?

So let’s assume you have one data source as your source of truth (which is a pretty good idea imho).

Then actually, when you look at Serverless and multi-cloud, what people actually mean is FaaS and multi-cloud.

In other words, I want my functions, sitting on two different clouds.

Because your functions are your logic.

But the problem is that you still have all the other services around FaaS solutions, that make FaaS a little easier.

Things like S3 triggers in Lambda, or Event Grid in Azure.

So, then you’d have to abstract away from there to ensure that your functions can do the same things on different platforms.

And if your data sits outside the cloud you’re on, you’ve got a problem with latency.

Should you go multi-cloud with Serverless?

Basically if you go multi-cloud with Serverless, you’re trying to solve a problem that you may well not have had, by:

increasing complexity (more functions/systems)

increasing maintenance (more functions/resources)

increasing infrastructure (more functions/resources)


Simply, if you’ve not got the resources, it’s a relatively strange decision to make.

And I’ve never found a company that absolutely has to do this.

Because I think it’s unnecessary to even consider it now.

So just don’t do it.

Using multi-cloud services

One thing to say is that there is nothing wrong with developing a solution that has a database in one cloud (because it’s great) and using the storage in another cloud (because it’s great) and using a third solution somewhere else to orchestrate it.

That’s fine! If this comes from a business requirement

e.g. I need a great graph database, so use a managed graph database service

This is totally acceptable and actually it’s what most people do without realising it (analytics services anyone?)

So there’s nothing wrong with multi-cloud.

What’s wrong is trying to make your entire solution multi-cloud

Because you almost certainly don’t need to.

Oh and if you do ever need to, the likelihood is you’ll have enough money to do it.

Written by

ServerlessDays CoFounder (Jeff), ex AWS Serverless Snr DA, experienced CTO/Interim, Startups, Entrepreneur, Techie, Geek and Christian

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store