Who Has Switched to Serverless?

We've been using a serverless stack on AWS for a while (API Gateway, Lambda, S3, SQS, RDS) and it's been a good experience overall.

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.

We switched some of our stack from k8s and swarm to Fargate, and API Gateway (Lambda). I don't know whether I enjoyed the switching, I mean it's just learning a new stack and applying it; but I do currently enjoy not having to manage anything myself and I like that there's no internal abstractions that are leaking out to the devs as they do their work.

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?

I've been deploying to the serverless stack on Azure (Functions, Service Bus), and have been mostly happy.

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/

I built my entire SaaS on serverless, initial writeup here: https://onlineornot.com/building-saas-in-one-week-how-built-...

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...

I always thought of serverless as yet another fad to come and go. In my career it seems like these things come in waves.

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...

We have been burned very badly by vendor lock-in in the past so we now have policies against renting other companies computers.

My team switched with AWS lambda and it was convenient. I definitely recommend using a framework like the Serverless framework. One benefit of the framework is that it supports multiple vendors so you don’t have to port cloudformation templates over, but it also supports a ton of plugins that make development easy. Our team had nearly zero scaling issues and our costs were lower than any other team in our org who were using ECS or EC2. An example of an issue was that a service I wrote was timing out for certain parameters and I had to increase the memory from the lowest memory setting so it could finish in time. But those kinds of things were rare. It was a Flask app and if needed we could have easily set up a docker container and thrown it in EC2 or ECS but we never needed to. Cold starts were annoying but mostly solved with provisioned concurrency which can be autoscaled. It was sometimes annoying to not be able to log into a production host and debug something but I guess it’s not good to do that anyway. Overall I’d recommend going serverless if you don’t know what your load is going to be or know it’s going to scale up slowly. If you know it’s worth the cost of ECS/EC2 from the start, it’s computationally intensive or requires a lot of RAM, then just go with ECS/EC2 (or EKS).

I’ve been running PHP for 20+ years.

It’s “serverless” without the cost and latency of Serverless.

I was using regular NodeJS server on EC2 or similar services from cloud providers and wanted learn Serverless because at the peak times I was struggling to manage servers for https://nureply.com.

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.

We have built a full digital bank on AWS serverless here. Lambda, S3, DDB, SNS, … no switch, we built it from scratch. The peace of mind is one of the biggest pros. So we can focus on more payment related problems. The ease to build an event driven system is also a plus.

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.

A lot of "serverless" is functions (i.e. backend or app server), but I would probably also say most apps would be fine on Hasura [0], a GraphQL-API-on-your-Postgres-as-a-service. I've built a couple apps this way and now I cringe at the prospect of building yet another CRUD backend.

Hasura + [some kind of FaaS] is great; definitely recommend considering this stack.

[0]: https://hasura.io

Wrote up some thoughts last month on serverless vs. containers here: https://www.withcoherence.com/post/containers-and-the-server...

My 2c is that for most people using containers on a "serverless" runtime like Cloud Run is the best of both worlds...

We went from EC2 Autoscaling Groups to ECS with tasks, where each task has a few containers responsible for particular functionality.

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.

Serverless seems to work well for basic web apps, anything more than that and things get complicated

our team has been using AWS Lambda for some event-driven data processing. it's good, would use it again.

AWS SAM makes dev, testing, and deployment experiences of lambda functions very good.

Have done serverless but not Serverless. The prior is beautiful yet can create a complicated testing picture.

I've used Azure Functions and Logic Apps. While they work, they get a 'meh' from me.

don’t switch, use both. raw ec2 has strengths and weaknesses. so does lambda. they are perfect complements.