Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Lambda is not useful. It solves a few problems but creates even more new problems.

Some problems include:

- It makes managing multiple environments (e.g. development, staging, production) almost impossible.

- It makes debugging difficult because you can't run the code on your own machine and step through the code. Most projects cannot be tested end-to-end due to environment incompatibilities between different services and front-ends running locally... It's a fact that multiple developers can't share a single development environment because each developer needs to work with their own test data but Lambda doesn't allow this.

- Lambda adds all sorts of unexpected limits on your code; e.g. cold starts, maximum function execution duration and others.

- The lock-in factor is significant; once you're hooked into Lambda and all the surrounding services that it encourages, you cannot leave and you have no bargaining power in terms of hosting costs and your future is entirely dependent on Amazon.

- Other AWS services that you can integrate with Lambda also exacerbate problems related to handling multiple environments and debugging. Services like Elastic Transcoder and S3 are blackboxes and are very hard to debug. If something goes wrong, sometimes the only way to resolve the problem is to contact Amazon support and spend weeks sending messages back and forth to figure out the issue.

- You're contributing to centralization of wealth and power instead of helping small companies and small open source projects. You're helping to turn Amazon into yet another too big to fail company with infinite leverage on the rest of the economy.

- It takes the fun out of coding. As a developer, you no longer feel any ownership or responsibility over the code that you produce, you're just handing over all that code to Amazon. In fact, it might as well belong to Amazon because that's the only company that is able to execute that code. It doesn't help with employee turnover.

The main reasons why Lambda is popular are because Amazon spent a fortune on marketing it and there are a lot of vested interests in the industry who want it to succeed (to drive up Amazon share price).



Many of the problems you notice are correct, but...

> It makes managing multiple environments (e.g. development, staging, production) almost impossible.

I don't know why you say this? In my experience, this was one of the most amazing parts: my CI/CD setup simply deployed a new Lambda function for every branch in my repo, which was equivalent to the production one in terms of environment.

> It makes debugging difficult because you can't run the code on your own machine and step through the code.

It took some work to initially setup, but I did manage to do this pretty well. Perhaps related to the next point:

> The lock-in factor is significant; once you're hooked into Lambda and all the surrounding services that it encourages, you cannot leave and you have no bargaining power in terms of hosting costs and your future is entirely dependent on Amazon.

This is true, but can be mitigated. I restricted the lock-in to the entrypoint, and managed to transfer my functions elsewhere later with relatively little effort. In this case, the Lambda functions were behind an API Gateway proxy, and I converted them to the same interface used by Express.js before passing them to my business logic. That allowed me both to execute the business logic locally, and to migrate it where it is running now, on a standard Express.js server.

> It takes the fun out of coding.

Well, I can just say that it was still fun for me - most of the fun usually is in the business logic, although the experience of simply experimenting in a different branch and having a complete production-like environment pulled up for that still amazes me.


You make some reasonable points, but many of them don't reflect my experience with Lambdas.

> It makes managing multiple environments (e.g. development, staging, production) almost impossible.

It certainly doesn't. You just have to use an infrastructure-as-code tool such as Terraform or Serverless. AWS's own method of dealing with environments is best ignored.

> Lambda adds all sorts of unexpected limits on your code; e.g. cold starts, maximum function execution duration and others.

Like any other platform, Lambdas have certain perforamance limitations you need to be aware of. They're not a fit for every problem but the future is going to be increasingly serverless. These limitations are likely going to be much less of a problem as the technology matures.

> The lock-in factor is significant; once you're hooked into Lambda and all the surrounding services that it encourages, you cannot leave and you have no bargaining power in terms of hosting costs and your future is entirely dependent on Amazon.

Again, use of a platform-agnostic setup like Terraform helps mitigate against this. In theory it ought to be relatively simple to change FaaS providers (I haven't actually tried this).

> You're contributing to centralization of wealth and power instead of helping small companies and small open source projects. You're helping to turn Amazon into yet another too big to fail company with infinite leverage on the rest of the economy.

The centralisation of power and wealth is true to an extent but there are two sides to this. It's also empowering for small organisations. It allows small companies to very quickly ramp up availablity and have extremely solid reliability without a specialised infrastructure team. You can also start up something very quickly and cheaply given AWS's free usage tier.


Have you heard of the Serverless Framework? It solves some of those problems, including handling dev/staging/production environments.

I do think you raise some great points however.


Doesn't that mostly apply to all serverless platforms? Serverless is cheap and allows cloud providers to use excess capacity to allow small pieces of software to run, scaling almost infinitely[0]. But it is always vendor lock-in, whether you choose Azure or Amazon. It is a propietary platform but that applies for most of the cloud if you use services that don't exist elsewhere (Azure blobs, Azure Cosmos DB, etc)

[0]: https://www.troyhunt.com/serverless-to-the-max-doing-big-thi...


I think I would take the parent comment to apply to any hosted Functions as a Service platform.


The only thing I can agree with is the centralization of wealth argument. The rest is simply not true I'm afraid.


Some of the problems are easily solvable. I use up[https://github.com/apex/up] which is an open-source serverless framework to solve them.

a. it is possible to have multiple environments[https://up.docs.apex.sh/#configuration.stages]

b. you can run code on your machine[https://up.docs.apex.sh/#commands.start]

c. regarding vendo lockin; alternative serveless providers(apart from aws) are planned [https://github.com/apex/up/issues/4]

d. You're contributing to centralization of wealth and power instead of helping small companies and small open source projects. up is open-source but also has a paid plan[https://up.docs.apex.sh/#guides.subscribing_to_up_pro]

e. It takes the fun out of coding. I'm not sure about that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: