Serverless Vendor Lock-In

When people start talking about serverless lock-in, they are concerned about the portability of functions (FaaS). But that is a completely inadequate assessment of the problem. Functions are the core of serverless architecture and are the glue connecting the services of your cloud provider together combining a serverless solution. You should assess portability as a whole and then correctly evaluate the real need for it.

You Lock On API Not Functions

Functions can be migrated quite easily to any platform you like. Easily comparing to dependency to other services (API) you use, which are cloud specific.

When you chose your cloud provider, you should do it carefully. You provider should be:

• Wildly used and reliable.
• Constantly lowering their prices.
• Long history of managing legacy services.

Such a provider is definitely AWS. If you chose your provider carefully, are you planning to leave it?

Lock-in is mostly in services you use. Not so much on functions. You can move functions to containers or EC2. You do not have to change a lot of code. But you will still use the same services of your cloud provider.

There are tendencies to build a uniform and open source solution for serverless like OpenWhisk, originated by IBM and joined by Red Hat, Adobe, and others. It allows enterprises to spin up their own functions service. There is a project, CloudEvents, a specification for describing event data in a common way independent of the cloud provider. And there are Fission and Knative, open source solutions for serverless based on Kubernetes. But as I said before, the major problem is not of compatibility of functions.

Are You Currently Lock-In Free?

Isn't locking to your current infrastructure, your platform choices (Oracle?), and operational team a bigger lock-in?

But what is locked-in anyway. Are we ever free? Are we free when we build everything from scratch with a "free" open source solution? Are we free then? Or are we just more locked-in to our own solution that we hardly manage and depending on a few people that can leave our organization at any time?

Do Not Build a Service Agnostic Solution

One approach for mitigating the danger of a lock-in would be abstracting your architecture so that it can be adapted to different cloud providers. And you can only use features that are the smallest common denominator of cloud providers you want to support. Do not do that! This will over-bloat and complicate your solution. There is a good chance that you will not need that (YAGNI). You will overengineer your service, make it complicated, and chunky. So, you will lose the key benefit of serverless, which should be composed from slim and simple microservices.

The Need to Rewrite Software

You fear that you will have to rewrite your software because of a vendor lock-in to your cloud provider? There is more chance that you will have to rewrite your software because the language, the libraries, the tools, and the framework you freely chose, became obsolete. But not just that. Your business requirements may change. Well not "might." We are living in a world of constant changes and we have to adapt. And your solution must adapt to these changing business requirements. If you are still not writing code in "evergreen" Cobol, you probably rewrite your software every 10 years. It is more likely you will have to rewrite software because of that, and not because AWS will become too expensive. And with serverless, you become more agile and you easily adapt to business changes.

You Pay for What You Use

Serverless provides payment only for what you use. No long-term contract (like Oracle), no obligations, and no upfront payment. You do not know how your business will go, so why pay upfront or commit to solutions you do not know will fit your future. Isn't this the ultimate solution for your business risk assessment and ultimately lock-free?

Microservices Are the Answer

Serverless solutions should be built as microservices — small and autonomous. That means you can change, optimize, scale, move, or transform each microservice autonomously. So, if your serverless solution in one part became too expensive or unfit to serverless architecture, just transform it. You can also move it to other cloud providers if you wanted to. Same goes if you want to move a serverless system to traditional. It is much easier to migrate than vice versa. So serverless is always the safest bet.

Final Point

I know this blog is written one-sided and that there are legitimate concerns about vendor lock-in, but they are greatly overblown. It is mostly just a fear of not controlling everything, especially parts that are new to you, that you did not get enough opportunity to get comfortable with. So be openminded and view the problem for its greatest perspective. There are valid reasons not to build a serverless solution, but they are mostly technical.

With serverless, you are lowering operations and are able to concentrate on things that bring you money and joy. Your company becomes more agile and can easer adapt to changes. Isn't that the synonym of freedom?