[moltar]

Just a counterpoint. But my experience has been the opposite.

Taking a legacy application that runs on a single server and is struggling to scale with spaghetti of config files all over the box and security issues that have gone unpatched because no one wants to touch the box as it’s too dangerous to change anything, as everything is intertwined. No backups or unverified backups. No redundancy. No reproducible environments so things work on local but not on remote. Takes devs days to pin the issues.

Then break it down and replace with individual fully managed AWS services that can scale independently and I don’t need to worry about upgrades.

Yeah, the total bill for services is usually higher. But that’s because now there’s actually someone (AWS) maintaining each service, rather than completely neglecting it.

They key to all this is to use IaC such as AWS CDK to have code be the single source of truth. No ClickOps!

[scrose]

I mostly understand what you’re saying and I hope I didn’t come across as saying serverless is *never* a good idea. In my experience it’s just very often not the best choice. I will always keep an open mind about solutions, but serverless often comes with many shortcomings that teams don’t notice until it’s too late. I’ve seen it happen enough times that I feel I must keep a healthy dose of skepticism when anyone proposes changing a small part of stack for serverless options.

I’ve been working with AWS for about 8 years now and have worked on supporting dozens of projects across 5 different orgs ranging from small 5-person shops to 1000+ people. I have only seen a handful of cases where serverless makes sense.

> Taking a legacy application that runs on a single server and is struggling to scale with spaghetti of config files all over the box and security issues that have gone unpatched because no one wants to touch the box as it’s too dangerous to change anything, as everything is intertwined. No backups or unverified backups. No redundancy. No reproducible environments so things work on local but not on remote. Takes devs days to pin the issues.

All of these issues are easily possible with many serverless options. What it really sounds like is your org went from a legacy architecture that built up a ton of tech debt over the course of years and had no one owning the basics (ie backups) to a new one with less tech debt since it was built specifically around current issues you were facing. In 3-5 years I wouldn’t be surprised to hear the pendulum swinging back in the other direction as staffing and resources change hands and new requirements emerge.

[moltar]

Hey thank you for the thoughtful response.

I didn’t mean to say that serverless is the way. I was just talking about AWS in general.

Although serverless is a broad category that includes Aurora Serverless, which does has trade offs but it’s a good choice in some cases.

I also like Step Functions a lot.

EventBridge for an event bus.

I’d even put ECS into sort of serverless category. I don’t manage the underlying servers and only care about the abstraction at the container level.