Some time ago, the Register published an article titled “Lambda and serverless is one of the worst forms of proprietary lock-in we’ve ever seen in the history of humanity”. It received a lot of attention, and vendor lock-in has become a perennially popular question at conferences. But I’m here to tell you that you are probably thinking about vendor lock-in all wrong when it comes to serverless.
Hear me out.
It’s coupling, not lock-in
The biggest misconception about serverless vendor lock-in arguments is that technology choices are never lock-ins. Being “locked in” implies that there is no escape, but that’s not the case with technology choices. Not with serverless, not with databases, not with frameworks, not with programming languages.
Instead, technology choices create coupling. And no matter the choices you make, your solution will always be coupled to something. Moving away from those technologies requires time and effort, but there is always a way out. In the worst case, you have to rewrite some parts of your system. Sam Newman defines a microservice as a stand-alone service that can be rebuilt in no more than two weeks. That gives you a rough idea of the worst case cost.
To prevent any coupling to a particular cloud provider, you end up with the least common denominator across all providers. And that means using only VMs and no managed services. And it means missing out on most of the benefits your cloud provider can offer!
There are two sides to risks
Is being tightly coupled to a cloud provider a risk? Absolutely. But taking risks is not a bad thing on its own. We take risks all the time. Part of being an adult is about taking sensible risks that give you the maximum return.
Is taking a new job a risk? Yes. But the return is new learning opportunities and (hopefully) better financial compensation.
Is driving a risk? Yes. But the return is being able to move from point A to B more efficiently so we can spend our time on other more useful things.
The return for embracing serverless is enormous. You get scalability and resilience out of the box. Lambda auto-scales based on traffic demand and Lambda functions are deployed to three Availability Zones by default. Lambda also scales to zero when there is no traffic so you don’t pay for idle. It minimizes the amount of undifferentiated heavy lifting you have to do and lets you focus on the things that are important to your business. In return, you get better velocity and time-to-market. Lambda functions are also more secure because AWS takes care of the security of the OS and networking layers. Known vulnerabilities in the infrastructure layers (such as Meltdown and Spectre) were quickly patched without requiring your intervention. And Lambda is compliant with a wide range of industry standards including PCI DSS.
Focus, focus, focus
Matt Klein, the creator of Envoy and a software engineer at Lyft, said recently that “unless you’re an infrastructure company, infrastructure is basically overhead”. I couldn’t agree more. So, does it make sense to throw your most valuable and expensive resource at what is essentially overhead to your business?
How often does a startup fail because of lack of portability? And yet, the vendor lock-in arguments promote portability above all else! Why?
“Because AWS can raise the price of Lambda suddenly and then you are screwed!” Sounds scary, but where’s the evidence of that? AWS announced over 57 price cuts in the last five years and zero price hikes. Should we make decisions purely based on “the worst thing that could happen”? If so, all of us belong in jail cells because we could all commit heinous crimes, even if there is no evidence to suggest we would. Fortunately, that’s just not how our society operates. It’s not how we make day-to-day decisions. So why start now?
Instead, as Ben Kehoe wrote recently, serverless is about focus. Focus on what differentiates your business. Focus on customers’ needs and creating business values.
Lack of focus is a far bigger risk
Statistically, 70% of companies perish within the first 20 months. These companies fail for many reasons, for example:
- run out of funding
- unable to find market fit
- unable to compete in the market
Building a capable engineering team is costly and time-consuming. For most companies, staff salaries are their biggest cost. This makes engineers their most expensive resource, and their time should be valued as such. So it stands to reason that you should give your engineers leverage to do more with less and maximize their impact on your business.
Instead of worrying about being tightly coupled to one cloud provider, a competitor that can go to market earlier and iterate quicker is a far bigger risk. As discussed already, serverless lets you move faster by giving your engineers leverage to do more with less. It helps you retain focus on your business and your customers’ needs. A competitor that takes full advantage of these benefits would be in a position to lock you out of your market sector long before the risk of vendor lock-in comes to bear.
It’s a bad economic decision
Proponents of the serverless vendor lock-in argument never talk about the price you pay in return:
- A lot of upfront development work. Which translates to delayed product launches and lost market opportunities.
- A constant hit on productivity. Which translates to a slower time to market and putting your business at a competitive disadvantage.
- A risk that all your efforts would be in vain. If the need to migrate from your chosen cloud provider never materialized.
As an insurance policy to guard against being “locked-in”, the price is steep. The time and effort you spend up front often outweigh the potential saving of future work. As an economic decision, it just doesn’t make sense.
Given the high cost of prevention and the low probability of the risk coming to bear. You are much better off paying the cost of migration if and when it happens.
Data is the real lock-in risk
But all of these arguments are still ignoring the elephant in the room, that data is the real lock-in risk.
Business logic is always easy to move around. Moving from one compute platform to another would take work, but is rarely difficult. There are also many ways to ease these migration efforts. For instance, there are frameworks that let you move an existing Express.js application to run on Lambda. You can also use hexagonal architectures to make it easy to port your application to different runtime environments.
But as Nick Gottlieb elegantly puts it, “The true danger with lock-in, especially with serverless, is the potential for data lock-in. Data has gravity. It accumulates. Data is economically disincentivized to leave, by way of platform pricing. This is the single biggest threat to vendor choice.”
Unfortunately, this data lock-in risk applies to everyone. Regardless of whether your application runs on VMs, containers or as Lambda functions.
We’ve been here before…
Those of us who have been around for a while remember similar vendor lock-in debates before. There was a time when ORMs were all the rage because of the fear of being locked in to database vendors.
Many of us drank the kool-aid and adopted ORMs. Unfortunately, things didn’t work out as the proponents of vendor lock-in prophesized:
- The vast majority of us never needed to migrate databases in the end.
- The few that did, found out the hard way that ORMs didn’t make database migrations any easier. If anything, it’s just another thing that you have to deal with during migration.
- ORMs introduced their own complexities and caused much performance and debugging issues. They introduced upfront development work. And they slowed down ongoing feature development and are a constant cognitive tax on engineering teams.
Vested interests
Taking a more cynical look at the source of all this noise about vendor lock-in, I can’t help but notice some vested interests.
Take the Register article, for instance. It was based on a conversation with the CTO of CoreOS. Whose company just happens to “power the world’s container infrastructure”, in their own words.
What would happen if everyone stopped running their own container infrastructures? It’ll probably spell trouble for private cloud providers, whose survival depends on us running on “portable” infrastructure components. That gives them a vested interest in delaying the adoption of serverless technologies such as AWS Lambda.
Can we blame these companies? No. They’re looking out for their own survival as any one of us would. But we need to be vigilant and not let these vested interests lead us to bet against our best interests. The survival of our businesses depends on it!
Summary
In summary, vendor lock-in is a risk just like any other risk that we have to deal with. It’s not so much a “lock-in” risk as it’s a risk of a tight coupling that makes future migrations difficult and costly. But, like other risks, being tightly coupled to one cloud provider’s services has its rewards. We get scalability, resilience and security in return. We can launch our products to the market earlier and iterator on them faster. Because we can minimize the amount of undifferentiated heavy lifting we have to do, and can better focus on creating business value.
The cloud has enabled a switch from capital expenditure (Capex) to operational expenditure (Opex). This has levelled the playing field and smaller companies regularly disrupt markets that have been dominated by large incumbents. The speed of innovation and disruption is gaining pace. Serverless technologies are taking things to a whole new level. Anyone can build scalable and resilient systems by standing on the shoulders of giants such as AWS, Google and Microsoft.
Would you keep your eye on the market, and focus on staying ahead of the competition? Or would you rather spend your days worrying about what might happen if you decide to change cloud providers one day?
Choose wisely.
The competition waits for no one.
