Should you be worried about serverless lock-in?

Serverless architecture is the inevitable future for most organisations, as major players in the technology sector are moving towards cloud platforms. This is due to cloud vendors’ abilities to provision and manage major computer resources, and drastically reduce the time-to-market. With the growing interest in serverless architecture, the market is expected to reach $7.7 billion by 2021.

Sound too good to be true? Well, sort of. Most serverless architectures come with a risk called ‘vendor lock-in’. Vendor lock-in is where customers are dependent (i.e. locked-in) on a single cloud provider’s technology implementation, and cannot easily move to a different vendor in future without substantial costs, legal constraints or technical incompatibilities.

However, the real concern is how much you should allow these considerations to influence decisions about whether or not to commit to a particular serverless platform vendor. The reality is that there is always a degree of lock-in with any technology choice, and serverless is no different. Vendor lock-in is a reality, whether you are choosing a database, a programming language, or an operating system, and serverless is no different.

Vendor lock-in is just another risk that comes with technology choices. But, like other risks, being tightly coupled to one cloud provider’s services has its rewards. You get scalability, resilience and security in return, and can launch products to market earlier and iterate on them quicker. Because going serverless minimises the amount of undifferentiated heavy lifting that has to be done, you can better focus on creating business value.

As with any technology move, however, it's a good idea to assess the potential risk and impact when choosing a vendor.

The first step is to check which programming languages and software development kits (SDKs) are supported by the vendors you’re considering. This will save you from incurring massive costs if and when you do decide to migrate to a different platform that shares the same language. If you realise during a migration that your new vendor does not support your chosen language, it will open a whole new set of problems to address before the migration can begin.

The next big challenge after committing to the chosen language is to consider transferrable solution architectures. A good architectural pattern will make any future migrations of serverless functions much easier. If the base code remains the same during migration, the costs come down automatically.

When choosing a cloud provider, the question isn’t necessarily whether you should be worried about being locked in, but rather what considerations need to be in place before committing to a single vendor. Migrating from one vendor to another is not impossible, but costly and risky when done impulsively.

Serverless platforms and services should be exploited for the right use cases. It can be cost-effective for burst and batch type workload scenarios, proof of concepts and low consistent-load systems. But for more traditional websites with predictable loads, there are more economical solutions to utilise. Being “cloud-ready” is the right proactive move, but be sure that going serverless is the best solution for your organisation when considering costs, integrations and scalability.