Ask HN: Who Has Switched to Serverless?
Curious to hear stories from folks who switched some or all of their stack to serverless and has enjoyed the experience.
I can't recommend Serverless Framework. The abstractions are leaky and it's quite opinionated about architecture. We regularly need to step away from Serverless Framework to use various features offered by AWS. Meanwhile, it's led us to build an infrastructure that reflects our org chart in some really unpleasant ways. I wish we'd used AWS CDK from the start.
Lambda currently makes sense for us cost-wise, but we are approaching an inflection point where that will no longer be true (something like Fargate will probably be cheaper). Problem is, the cost of migrating from Lambda to Fargate will be non-trivial for us. I wish we'd used containers on Lambda from the start.
We struggle regularly with global state in the Lambda runtime. Some devs avoid it assiduously, which can result in costly inefficiencies which have bitten us badly a few times (think hitting API limits due to calls happening on each Lambda invocation rather than only when needed). Other devs make use of global state for efficiency benefits, which then bites us by causing difficult-to-reproduce bugs. I don't think there's a great solution to this in the Lambda runtime.
Overall I think the benefits of security, process isolation, scaling, cost, etc. have all made it worth it, but there are things I would do differently if I was setting up a project from scratch.
Does this actually solve a problem? You still need to implement the lambda interface. so as someone who hasn’t used them, containers just seem to replace the zip file format with no actual portability benefit
Speculative, but had we used containers from the start we would likely have built "fatter" Lambdas running full web servers with an extant web framework (someone else in this thread mentioned Flask - we don't use anything like that, we have one Lambda per... function, and our functions just consume the raw Lambda event).
There's a thin layer of lock-in which I'm aware of, but not afraid of. In exchange I get a lot of peace of mind, cost savings, and importantly, a lot of things are someone else's problem.
As with any tech the important thing is not adopting something because it's popular, but only adopting it if it helps you. That requires you to spend a little time learning about it first.
How about yourself, are you mulling a switch or in the process?
Azure gets a lot of hate around here and it's hard to disagree with some of the lived experiences.
That said, mine have been mostly positive overall. Yeah, the support isn't exactly stellar, yeah, the deployments are not 100% reliable (but close), but which stack has zero issues?
For me, the benefits vastly outweigh the issues.
For Functions, Service Bus, App Insights, I don't really care about the infra I once set it up. Everything is automated, from deployments to scaling when traffic hits. The team I contract for has 0 dedicated (Dev)Ops. Compared to another project where we used k8s, that's a big win - there, we had 3-4 dedicated k8s experts on staff to keep the lights on.
Some services that we use on Azure are not really serverless, like the managed Postgres. That's sub-optimal as the database can very quickly become the bottleneck and can't keep up with the autoscaled function instances. I hope that what Neon[1] is trying to do - truly serverless Postgres - takes off and I wish Azure had that.
The tooling and integrations that Azure has is also a big win in my book. For instance, migrating a static website to Azure Static Web Apps (omg why didn't they just call it "Pages"?) is super easy. You get automatic deploys from main/master and automatic preview environments for pull requests. All it takes is a simple Github workflow. I don't think I would want to manage my own infra for that.
The downside of the serverless model is that once you hit a bug or a limitation of the platform, all you can do is open a ticket and hope for the best. Whereas if you own the server, well, you can dig in, obviously.
For me, once I understand the trade-offs and serverless comes out ahead, I go all in. YMMV.
[1] - https://neon.tech/
It was great early on, as I had no idea if people would actually use another uptime monitoring service. Eventually, the costs were significantly more than permanently running VMs, so I moved most of my workload off AWS lambda, which I wrote about here: https://onlineornot.com/on-moving-million-uptime-checks-onto...
1. The single page application wave came and we rewrote our Rails 3 app to Angular.
2. Serverless came along and we were building things with Firebase and other services we didn't control.
3. Chat bots came along and suddenly we had automatic pop ups on our site offering help and sales.
4. Microservices came along so we broke Rails into a bunch of services and languages and frameworks.
5. React came along and we replaced Angular.
None of these things ever last. I focus on the fundamentals and keep my core competency strong. Learn old/boring/proven technology. If it has been around for 15 years it will probably be around in 15 years...
#tinfoil
It’s “serverless” without the cost and latency of Serverless.
It turned out great and I am almost paying nothing. It is a bit slow if there are no active users but at the peak times there is no cold starts and comparable to regular Ubuntu server.
Vendor lock in is true but I can copy paste a lot of code to make it a regular server again.
Also there are limitations for long running tasks but for these kind of tasks I can create a thin server.
So far it is doing well and enjoying not doing any devops so far.
The only thing I regret is DDB. While the technology is great NoSQL was a poor choice for us. But at the time it was hard to attach anything else to a lambda without a heavy performance drop.
Hasura + [some kind of FaaS] is great; definitely recommend considering this stack.
[0]: https://hasura.io
My 2c is that for most people using containers on a "serverless" runtime like Cloud Run is the best of both worlds...
Dev is a lot easier. Every functionality is represented by a container, which makes it super easy to version, test, plug in to other stacks, e.t.c.
Deployment/debugging is harder.
With things like Cloud Run and long running functions it seems most of the initial drawbacks have been solved.
Money seems to be the main constraint these days from my research.
AWS SAM makes dev, testing, and deployment experiences of lambda functions very good.