Why vendor lock-in with serverless isn’t what you think it is

ServerlessConf Austin just happened. It was brilliant and a lot of fantastic talks and discussion around a number of topics.

My big take away from the conference was the leaps that Microsoft’s Azure Functions and Logic Apps have taken in the last year. These solutions are becoming a very solid solution and if coming from a Microsoft background, then these are a real option for utilising Serverless concepts going forwards.

Back to the conference, and the title of this post.

There were a lot of conversations around vendor lock-in. This was unsurprising given that there were major cloud vendors (AWS, Microsoft, Google, Apache OpenWhisk) both giving talks and having stands at the conference.

Vendor lock-in is often a big problem because of concerns around a vendor ceasing a service or simply turning off an account. My experience is mostly that vendors don’t do this without at least a period of time to resolve or move, so it’s frankly not a problem most of the time.

However, up until serverless ideas came about, cloud providers have been fighting to host more and more of your “servers” (whether physical, virtual, instances, containers etc). These are pretty simple to transfer between clouds, and so having cross-cloud solutions at the instance level isn’t massively complicated to consider and achieve.

We’ve also had cross-browser solutions for years as well. Mainly these are javascript libraries that provide a great way of standardising a solution for web browsers. Simple isn’t it?

Which means that we must be able to do serverless and avoid vendor lock-in right?

Well, there’s a problem. While Function as a Service is the core to most serverless options, and moving functions is similar to moving containers between providers, there is a problem.

The majority of serverless solutions rely on the rest of a vendor’s cloud services: events, data storage and many other things (as well as other third party solutions). Which means that the code is very often cloud specific.

Which means that to build a cross-cloud solution, you would need to build abstractions above the cloud to essentially standardise the event creation and ingestion as well as the services that you need.

Unfortunately, building abstractions can be hugely time consuming and counter productive. When you’re talking about functions, one of the keys is limiting the addition of libraries. Adding abstraction libraries means the function isn’t as small as it could be and could easily remove some of the value of functions.

Those abstractions also will often provide either inefficient code, or bring in technical debt with code that other people create. This technical debt means that we won’t have learned the lessons we’ve previously added in with frameworks becoming stale and bloated over time.

It’s not just the infrastructure, but the code as well.

Which makes a cross-browser non-vendor-specific serverless solution a little bit of a pipe-dream at present. It’s not that you can’t do some simple solutions, but at present, there is not a good way of doing this for a production environment, without having to pick a vendor.

Picking a vendor should be a positive outcome from a process of identification.

Trying to build something serverless and cross cloud is an attempt to avoid the correct process.

It will come in the future, but at present, we don’t have the patterns in the serverless world to really know what the abstractions should be.

So…

Pick a vendor.

For good reasons.

You won’t always get it right, but make the best decision you can.

Most of these vendors can cope with what you throw at them so just go for it and stop trying to keep your options open. That way lies madness and mediocrity for your solution (at present).