“Lambda and serverless is one of the worst forms of proprietary lock-in” (2017)

The big difference with something like PL/SQL is that it’s a proprietary language, whereas lambda and the other faas options are based on open languages. Makes portability somewhat easier to achieve.

This.

Funny thing is, the fact alone that you create a provider-agnostic system can give you enough performance or cost penalties that you want to change providers in the first place.

You can't use provider specific optimizations, so the provider seems bad and you don't wanna use it.

It’s not just portability that’s an issue with lambda. It’s also churn.

Running on Lambda, one day you’ll get an email saying that we’re deprecating node version x.x so be sure to upgrade your app by June 27th when we pull the plug. Now you have to pull the team back together and make a bunch of changes to an old, working, app just to meet some 3rd party’s arbitrary timeframe.

If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days.

That’s the issue I find myself up against more often when relying on Other People’s Infrastructure.

Good points, but it remains to be seen whether the portability of large serverless apps is sufficient to prevent the providers from squeezing their customers once they are deeply established.

The fact that there’s three major cloud providers (who will at the very least compete on customer acquisition) is a point in favor of this, but it’s definitely an experiment. In my mind, this is as much about negotiating power as it is about technical tradeoffs.

There are also a terrible cost of running just on one database, the dependency on just one provider.

In business you should never depend on just one provider. This provider could be the best in the world, now, because it has amazing management. But people die, or are hit by a bus, or get crazy after a divorce or just retire and they get replaced by the antitheses.

In my personal experience, real portability has great benefits on their own. Design is easier to understand and you constantly find bugs thanks to running your software in different architectures, compilers and so on.

At the end of the day, it is the quality of your team. If your team is bad, your software will be bad and vice versa.

The unifying lesson I've been appreciating after reaching my 30s is that in order to make good decisions, an individual needs to have a very clear understanding of how something works. If you know how something works, then you can foresee problems. You can explain the correct use cases for a particular tool. You know the downsides just as well as the upsides for a particular choice.

In software development, a lot of the new stuff that is supposed to solve our problems just shifts those problems somewhere else -- at best. At worst, it hides the problems or amplifies them. This isn't unique to software development, but it seems to be particularly pervasive because so much is invisible at the onset of use.

Best advice, be very suspicious when someone can't explain what the bad parts are.

You could always deploy your own FAAS cluster. https://www.openfaas.com/ https://openwhisk.apache.org/ and others.

You're only thinking about the _input_. Technically, yes, I can host an express app on lambda just like I could by other means, but the problem is that it can't really _do_ anything. Unless you're performing a larger job or something you probably need to read/write data from somewhere and connecting to a normal database is too slow for most use-cases.

Connecting to AWS managed services (s3, kinesis, dynamodb, sns) don't have this overhead so you can actually perform some task that involves reading/writing data.

Lambda is basically just glue code to connect AWS services together. It's not a general purpose platform. Think "IFTTT for AWS"

aws lambda is probably has the least vendor lock in than any of their offerings.

> And despite the dreams of techies more than likely after awhile, you aren’t going to change your underlying infrastructure.

Yeah, nowadays it's done by dissolving the company or being bought out, then shut down.

Still, it's the same thing. Use of inadequate infrastructure being, let's say, terminated.

I think it probably isn't purely the use of lambda/serverless but the creep of other things that make it more difficult to leave. Stuff like cognito or SNS or other services. Once you start using AWS, each individual choice in isolation looks cheaper and easier to just use something AWS provides. Once you start utilizing 7+ different AWS services it becomes very expensive to transition to another platform.

Also, this conversation is very different if you are an early stage company racing to market as opposed to an established organization where P&L often takes precedence over R&D.

> And despite the dreams of techies more than likely after awhile, you aren’t going to change your underlying infrastructure.

sorry -

isn't the _entire context_ of this article (and your response, experience, etc) 'implications of changing an underlying infrastructure' ?

yes, this isn't something one does on a whim, but it does happen, as your own post suggests.

Does this assumption hold for large, production-ready, applications?

And while we spend all of our energy and money doing that, we aren’t actually creating the product that is suppose to be bringing us revenue....

I have mixed feelings about this and I don't have enough experience to label on method better than the other.

Lambdas basically require zero maintenance. SQS requires zero maintenance. EC2 load balancer is zero maintenance. And the setup is trivial too and there's no migration time down the line.If you start off with native cloud for everything you can keep your maintenance and setup costs down drastically.

However, a lot can be done with the old school unsexy tech.

So I'm mixed.

In my case switching to an AWS API Gateway + Lambda stack means I have zero-downtime, canary deployments that take less than 5 minutes to deploy from version control. Api Gateway is configured using the same swagger doc that autogenerates my request/response models (go-swagger) and (almost) completely removes routing, request logging, throttling and authentication concerns from the request handlers. Combined with a staticly hosted front-end and SNS/SQS+lambda pub-sub for out-of-process workers I never have to worry about auto-scaling, load-balancing or cache-invalidation and we only pay for what we use. It may not suit every use case, but in our case, we have bursty, relatively low-volume traffic and the hosting bill for our public-facing site/service that comprises most of the main business revenue is the same as a rounding error on our BI service bill.

I'm generally a proponent of DIY, this doesn't make sense. When an org needs to scale, it makes sense to cultivate skill in the underlying infrastructure. On day 1, serverless makes a lot of sense because it encourages development patterns that eventually will scale nicely.

Serverless is also easier to develop for.

With Google Firebase Functions I was able to start writing REST APIs in minutes.

Compare that to setting up a VM somewhere, getting a domain name + certs + express setup + deployment scripts, and then handling login credentials for all of the above.

I had never done any of that (eventually I grew until I had to), so serverless let me get up and running really quickly.

Now I prefer my own express instance, since deployment is much faster and debugging is much easier. But even for the debugging scenario, expecting everyone who wants to Just Write Code to get the horrid mess of JS stuff up and running in order to debug, ugh.

(If it wasn't for HTTPS, Firebase's function emulator would be fine for debugging, as it is, a few nice solutions exist anyway.)

But, to be clear, on day 1 the option for me to write a JS rest endpoint was:

1. Follow a 5-10 minute tutorials on setting up Firebase Functions.

OR

1. Pick a VM host (Digital Ocean rocks) and setup an account

2. Learn how to provision a VM

3. Get a domain

4. Get domain over to my host

5. SSH into machine as root, setup non-root accounts with needed permissions

6. Setup certbot

7. Learn how to setup an Express server

8. Setup an nginx reverse proxy to get HTTPS working on my Express server

9. Write deployment scripts (ok SCP) to copy my working code over to my machine

10. Setup PM2 to watch for script changes

11. Start writing code!

(12. Keep track, in a secure fashion, of all the credentials I just created for the above steps!)

I am experienced in a lot of things, and thankfully I had some experience messing around with VMs and setting up my own servers before, but despite what everyone on HN may think, not every dev in the world also wants to run a bunch of VMs and manage their setup/configuration just to write a few REST endpoints!

So yeah, instead I can type 'firebase deploy' in a folder that has some JS functions exported in an index.js file and a minute later out pops some HTTPS URLs.

> In most cases, very few companies have products that need to scale to extreme load day 1 or even year 1.

That wouldn't be a great reason to choose serverless indeed. However, that doesn't mean serverless isn't still the right choice.

We've tried both the traditional approach you describe and serverless, and from experience the latter is 10x less infrastructure code than the former (we compared both Terraform implementations).

If serverless fits your use case, saving time and effort is a very good reason to go for it IMHO.

Honestly, I've developed the last few projects in Serverless framework and deployed to AWS Lambda. My biggest project is a custom Python application monitoring solution that has 4 separate Lambda function/handlers, populates an RDS PostgresSQL database with monitoring data (runs in a VPC), then reads from that database using complex joins across multiple application metric tables to send time-series data to Cloudwatch metrics.

Then, I configured Cloudwatch alarms to have thresholds for certain metrics that send a web hook to PagerDuty.

The benefit is that my monitoring system never goes down, never needs to be patched manually (AWS even patches my Postgres database, and fails over to the warm standby during patching), and never needs any system administration.

Have you ever worked at a company where you had a serious outage that you didn't detect quickly enough because a monitoring system was down? Having a Serverless monitoring system means this has happened 0 times despite our app running in production for almost a year now.

I'd include the triggers as part of that analysis, like being able to invoke a function every time something is pushed to an S3 bucket for example. Just being able to run arbitrary functions without caring about the OS is the core product, but the true value is that you can tie that into innumerable other services that are so helpfully provided.

Basically, AWS has so much damn stuff under their belt now, and it all integrates so nicely, every time they add a new feature it lifts up all the other features as a matter of course.

Agreed.

Vendor lock-in is a thing, but Lambda are lower on the rungs than other things.

It's the hyper-specific things that imply heavier lock-in, especially those that bleed into other systems.

I tend to agree, although with most things I think it depends on how heavily invested you are. Migrating a handful of mission-critical Lambdas is no biggie, but if you've really bought the bait and implemented your entire web services architecture on AWS API Gateway and Lambda -- for some reason -- you've got a much tougher job untangling yourself. Perhaps it suffices to say it's worth keeping an eye on how much friction you're building for yourself as you go.

The problem with that is, there's only one thing, some product manager somewhere, that sits on a light switch of your company or project's success or failure. They could even unintentionally end you with a price change.

Most systems out there are not in cloud (and multi cloud is even more far fetched).

There is however a large number of painfully learned lessons of vendor locked in systems... no one got fired for buying IBM, right?

    Pick a vendor and go all in.

That sounds like the perspective of someone who's picked open source vendors most of the time, or has been spoiled by the ease of migrating Java, Node, or Go projects to other systems and architectures. Having worked at large enterprises and banks who went all in with, say, IBM, I have seen just how expensive true vendor lock-in can get.

Don't expect a vendor to always stay competitively priced, especially once they realize a) their old model is failing, and b) everybody on their old model is quite stuck.

This, and if you really really don't want vendor lock-in, instead of inventing your own infra APIs, find the API the cloud vendor you chose exposes, replicate it, make sure it works, and then still use the vendor with the comfort of knowing you can spin your own infra if the cloud provider no longer meets your needs.

Or you don't bother replicating the API, even if you don't want vendor lock-in, because you realize that if a cloud provider evaporates, there will be a lot of other people in the same boat as you and surely there will be open-source + off-the-shelf solutions that pop-up immediately.

I've been at places where they were so vendor locked to a technology that there was a penalty clause for leaving that was in the tens of millions. It obviously wasn't cloud but the point still stands. If you don't have options you pay what they tell you or go out of business.

There's a middle ground here. You can decide on a case by case basis how much lock-in you are willing to tolerate for a particular aspect of your system. You can also strategically design your system to minimize lock-in while still leveraging provider specific capabilities or "punting" on versatility when you want to.

In other words you can decide to not bother with worrying about lock-in when it costs too much.

This will make your code base easier to port to multi-cloud in the future if you should ever want to.

If a company is going from zero to something, then you are absolutely right. In that case, dealing with vendor lock in later means success!

If an established company is moving to the cloud, the equation is not as simple. The established company presumably has the money and time to make their vendor agnostic. Is the vendor lock in risk worthwhile to spend more now? How large is the risk? What are the benefits (using all of the AWS services is pretty nice)?

That's terrible best-practice advice.

My best-practice advice is to do the math. What is the margin on infrastructure vs. the acquisition and management costs of the engineers necessary to operate the infrastructure.

Serverless doesn't scale very well in the axis of cost. At some point that's going to become an issue. If one has gone "all-in" on vendor lock-in then that vendor is going to spend as much time as possible enjoying those margins while the attempts to re-tool to something else is underway.

Best practice, generally speaking is to engineer for extensibility at some point, fairly early on.

If your time horizon is short (months to a couple of years) going all-in with a vendor can work quite well. Over longer time horizons (several years or more), it's often not so great. Forgetting about the costs involved (i.e. they know they've got you) and the fact that if that one vendor ever becomes truly dominant that improvements will slow to a crawl (i.e. they know they've got everyone), there is a very real risk of whatever technologies you are depending on disappearing as their business needs will always outweigh yours. Feature velocity tends to evaporate in the face of a forced overhaul or even rewrite.

At first this seems reasonable from a 'technical debt' perspective. Building in vendor-agnosticism takes extra resources (true), that you could spend on getting features to market (true), you can always spend those extra resources later if you succeed and need them... sort of true, not really. Because the longer you go, the _more expensive_ it gets to switch, _and_ the more disruptive to your ongoing operations, eventually it's barely feasible.

Still, I don't know what the solution is. Increasingly it seems to me that building high-quality software is literally not feasible, we can't afford it, all we can afford is crap.

Agree that time to market shouldn't be impeded by any unnecessary engineering.

But pick a vendor and go all-in can work for netflix'y big companies or ones with static assets on cloud. All cloud providers have their own rough edges and if you get stuck in one you might be losing your business edge. Case in point - not going to name the provider since we are partners with them, we found a provision bug - custom windows image based vm took 15 minutes to get provisioned and also exporting custom image across regions has rigid size restrictions. The provider acknowledged the bugs but they are not going to address it in this quarter but if we are netflix big - may be they could have addressed it sooner.

We have automated the cluster deployment so we can get our clusters up and running in most major cloud providers. We are careful not to be tied to vendor lock-in as much as possible since business edge cannot be compromised based on this big cloud providers, who only heed to your cry only if you are big and they care none what so ever for your business impediment. When you are expecting cloud resources which aren't going to be static - you need flexibility so the above recommendation doesn't suit all.

It doesn't have to be that way, for a client I've recently set up a Gitlab Auto Devops on Google Kubernetes. Feature velocity wise it is nearly as painless as Heroku (which to me is the pinnacle of ease of deployment), but because every layer of the stack is open source we could switch providers at a flick of the wrist.

Of course, we won't switch providers, because they're offering great value right now.

I feel this vendor lock-in business is a phase that will pass. We were vendor locked when we paid for Unix or Windows servers, then we got Linux and BSD. Then we got vendor locked by platform providers like AWS and such, and now that grip is loosened by open source infrastructure stacks like Kubernetes.

I'll echo this sentiment, and while it may sound like a philosophical position it really is pragmatic experience: it is nearly impossible to realize a gain from proactively implementing a multi-vendor abstraction. I've found this to hold in databases, third party services like payments and email, and very much so in cloud services. I instead recommend using services and APIs as they were designed and as directly (i.e. with as little abstraction) as possible. Only when and if you decide to add or switch to another vendor would be the time to either add an abstraction layer or port your code. I've never seen a case where the cost to implement two direct integrations was significantly more than the the cost to implement an abstraction, and many cases where an abstraction was implemented but only one vendor was ever used.

I'll note that I have no objection to abstractions per se, especially in cases where a community solution exists, e.g. Python's sqlalchemy is good enough that I'd seldom recommend directly using a database driver, Node's nodemailer is in many cases easier to use than lower level clients, etc.

Is there a middleground?

Perhaps standardizing on something like Terraform allows you to reduce the risk of going all-in on one vendor.

Similarly with Kubernetes; if you go all in on k8S, do you care where it's hosted or can you maneuver quick enough to the best provider?

By lock-out do you mean the vendor shuts down, or you get banned, or something else?

> It’s never the end of the world with vendor lock-in.

I think that's a matter of scale. Using Oracle for your counter example isn't very persuasive, as that's a huge vendor, so there's a market to extract you. Not so for many other vendors.

> Most companies don’t survive

...and ensuring they can control their costs and pivot away from solutions that prove too complex is part of being able to survive.

I mean, I agree, vendor lock-in doesn't have to be the end, but it also makes sense to extricate yourself when you can. When I worked for Virginia state govt they made a deal with Northrup Grumman...one that the legislative audit group came by later and said it was such a terrible deal that we should drop it...except we couldn't afford the exit costs, so we had to stick with a deal that was bad in terms of both money and quality.

That's a position you don't want to be in, and that result "It's bad but we can't afford to get out of it" is what the fear of vendor lock in is all about.

There's a world of organizations between Netflix and Twitter scale and small startups with 2-3 person infrastructure teams in which Kubernetes makes good sense.

At some point, it becomes cost effective to have a two-pizza team of engineers dedicated to it. Once an org hits that level, then the scale that can be achieved with Kubernetes is pretty immense.

" don’t need Kubernetes nor serverless."

Actually 'serverless' is where small shops might want to start.

A single Lambda can encompass a whole variety of functions, and if you're using a datastore that scales as well, you don't need to worry about much. Once it's set up, it should be very easy to monitor and change.

I'd rather a simple Lambda than managing a couple of EC2's with failover scenarios and the front end networking pieces for that.

As someone who has negotiated with AWS at the $1m/month level this is completely false.

"If you cross a million a month, they'll no longer negotiate with you because they know you're so locked that you're not going anywhere"

If they think you are unable to move at all, that may be true. The tone changes once you realize that either you can move, or you can't, but there's a lot more business coming and they won't get it.

Cool. What part aren't you buying, the title of this post, or the actual five paragraphs in the article that actually give you the context of that title?

Or https://github.com/fnproject .

I think best practice is to think of serverless deployment as a technical operations technology, rather than as a methodology to eliminate the need for technical operations. Don't lose track of what you're effectively outsourcing to your serverless provider. Have a backup plan, just like in the old days you wanted a backup plan in case your datacenter provider had issues.

Like Oracle.

As far as I know, in the entire existence of AWS since the first services launched in 2006, they have never abandoned a service.

In my opinion, the real lock-in is not the stateless API, but the tie-ins with other AWS services that may end up being required to accomplish what you need.

Like, if you're trying to provide a calculator API, you can definitely run that in Lambda and then easily move it somewhere else when AWS does something to upset you. But, let's say you're trying to do something a little more complicated (a common example is validating and transforming profile pictures for some sort of app), you might end up using AWS Step Functions and SQS. Your code is still portable but it relies on a bunch of managed services.

They need a snappy new name for it, though. "Web hosting" or something.

There is a great list of self-hosted services, i think the author will be happy for merge requests with more services https://github.com/Kickball/awesome-selfhosted

Isn’t that what containers and Kubernetes are for?

This is called 'Flynn' and it just works.

Abstracts your database, load balancing and most functions that AWS provides. You can even add minio as an S3 compatible data storage.

AWS won't go out of business.

You'll start seeing slowly increasing rates... and as people leave, the rates will increase further. Eventually, you'll start seeing Snowball no longer supported for getting your data off S3.

This is why the serverless framework (trying to give the possibility to deploy to any cloud provider) is so important. Some repetitive simple tasks are extremely well suited for lambda/functions /whatever name and some tasks are suited for big machines with gazillion terraflops and terabytes of ram. The job of the engineer is to know what his software needs, and what the most optimal path for this is.

Business is ever changing. This is just another step

You can definitely build a fully functional web app using just serverless. For an example, take a look at https://acloud.guru . Where I work, we almost exclusively use serverless, and I have found it to be incredibly reliable, and way more hands-off than a docker deployment.

On Azure it's not a docker container, or any other kind of 'standard' container.

That said you can get a docker container with the Azure Function runtime, so you could in theory port your functions elsewhere, but I don't think you get the monitoring benefits that you'd have keeping it on Azure.

More like two

- deserialize event

- pass object to your business logic.

Added. Thanks!

Why do we park in a driveway and drive on a parkway? The key is to understand what people mean by the words they say. Yeah, there can be things that get under our skin, but at the end of the day, just roll with it. (I say this as much to remind myself as to you.) Looking for absolute consistency in language is a recipe for needless, self-inflicted frustration.

> Why is it called "serverless" when it is not, in fact, serverless?

It is serverless from the perspective of an IT department that, by adopting it, no longer has to manage servers as a distinct resource.

It's like a product sold as having “worry-free interoperation”. There's still worry in the interoperation, you are just paying someone else to do the worrying.

Likewise, a serverless product still has servers underneath, you are just paying someone else to abstract them so that they aren't a concern for you.

I felt the way you did, but I'm sorry to say that that fight has been lost. That one along with crypto.

Why is wireless networking called wireless when there are wires connecting the wireless router to the modem? Or the modem to the coax? Because it's wireless at the last hop and that is what is what is important to the user.