Vendor lock in. Scary words. You'll hear people hyperventilate about this on cloud in general and serverless in particular. So should you be concerned?
Hi, I’m Forrest Brazeal at Trek10, and this is ‘Think FaaS,’ where we learn about the world of serverless computing in less time than it takes to run a Lambda function. So put five minutes on the clock - it’s time to ‘Think FaaS.’
Today’s topic is ‘Talkin’ Lock-In’. That’s right - vendor lock in. Scary words. You’ll hear people hyperventilate about this a lot when it comes to the cloud in general and serverless in particular. So should you be concerned?
Now obviously, lock-in isn’t just a cloud thing. Any time you rely on somebody else’s service, they become a dependency for you. But serverless applications get people especially concerned because they are basically nothing but managed services, stitched together with code that runs on the cloud provider’s managed execution environment.
So when people talk about vendor lock-in for serverless, they’re usually worried about three things.
Number 1. Will the cloud provider still be around as long as I need them?
I think we can stop worrying about this. The major cloud vendors, especially AWS and Microsoft, aren’t going anywhere. They are fully committed to the cloud and honestly, they’re probably going to be around a lot longer than any particular version of your app. In other words, if you become so amazing and powerful that you outlast AWS, that’s a good problem to have.
Number 2. Will the cloud provider get rid of a service that I rely on?
This is a big worry for some people looking at serverless architectures. Take AWS for example. Any kind of serverless application on AWS is probably going to rely heavily on Amazon’s API Gateway service. What if AWS deprecates API Gateway in favor of Awesome Rest Portal 2.0? What if they break the APIs? How will your app survive?
Google is notorious for sunsetting user-facing services without a lot of warning. But I think AWS in particular has built a lot of trust with their users up until now by not doing this. As an example I would point to SimpleDB, which is an AWS service that has been deprecated for years and years now, but it’s still running. It still has docs, the APIs still work, so if you have some weird app in a dark corner of the internet that needs SimpleDB to survive, you’re okay. And again, the likelihood of your cloud apps outlasting AWS services is pretty small.
In fact, one of the primary reasons for choosing serverless is that you can rapidly iterate and refactor your application, using new or updated services as they become available.
Now, Number 3. This is the big one. What if I build a serverless application - and I use the cloud provider’s Function as a Service, and their managed NoSQL service, and their managed queues and event streams and all the other glue that’s so easy to use and integrate with - and then what if I want to leave?
Maybe the cloud provider raised their prices. Maybe I decide I like somebody else’s services better. Maybe I want to be a maverick and build my own datacenter. But I can’t move, because my application is so hopelessly tangled up in services that I don’t control. And not only that, but I’m relying on the cloud provider’s custom hardware, their networks, their massive scale - things I couldn’t build myself even if I wanted to. I am locked in.
I mean ‘history of humanity’ is a little dramatic, like I don’t think Genghis Khan was worried about migrating his single page apps, but you get the point. The cloud provider sucks you in with the promise of convenience and low cost, and then you’re sort of stuck in their Hotel California for the rest of time.
This is a legitimate concern. To an extent. Some people will tell you that a serverless architecture, because it tends to be made up of microservices, is actually easier to move around. Just pick up one piece of your application, move it to a different cloud, and call it from a REST endpoint. Look Mom - no lock-in! But that’s an oversimplification. A really well-architected serverless app is going to be deeply ingrained with a cloud provider’s services, and some of those services, like your data layer, aren’t so easy to move.
So ultimately, there’s some critical thinking required here. You have to weigh the pros and cons and decide what’s most important to you. Do you want to maintain maximum control over every aspect of your application, and spend your life reinventing wheels around every detail of tooling and infrastructure? Or do you want to build and innovate at cloud scale, focusing your limited resources on the code that actually creates business value for you?
Personally, I choose option 2 every time. Evaluate your options carefully, pick a cloud provider that you trust, and stand on their shoulders. I think that’s the way, not to be locked in, but to be locked and loaded for success.
That’s it from me! Hope you’ll join me next time for another episode of ‘Think FaaS.’
