> You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.

You can consider it so theoretically, but for many teams, especially small teams, OS-level systems admin is a different skillset and non-trivial burden that they are glad to pay a premium for, which is why offerings like heroku are successful.

It may work that way for you, but it definitely does not for many many teams.

"You already have to walk to the store, so hiking the appalachian trail is just another part of your walking strategy" -- this is an exageration, the difference between walking to the store and hiking the trail is probably larger than adding OS-level maintenance, but it shows "you already have to do X so doing anything else that I can also call 'X' should be trivial" is a flawed form of analysis, it tells us nothing that you can call all of it "walking" or all of it "patching strategy".

>If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.

This is "you'll always have to do X, so might as well do 10x" argument...

Who would argue that? Why would you ever want to do 10 times something just because you do it once?

Well, the "You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy." is close to making that argument.

Just because I have to manage patches for 'my app and it's libraries' doesn't mean also handling the OS and everything else that would already be covered by the serverless service is no biggie...

Literally the only other thing to maintain with a Fargate service is what container you run your tasks with. If you have a Nodejs app, use the public Nodejs container. If the container version ends up with a vulnerability, bump the version in the task definition, and do a rolling restart. This isn't some onerous, complex task that only the most cunning sysadmin can fathom. If that alone is what causes somebody to run Serverless I don't think they understand all the other complications that come with it.

>Literally the only other thing to maintain with a Fargate service is what container you run your tasks with. If you have a Nodejs app, use the public Nodejs container. If the container version ends up with a vulnerability, bump the version in the task definition, and do a rolling restart. This isn't some onerous, complex task that only the most cunning sysadmin can fathom

If you're doing a toy demo app, or a website for your local flower shop, yes...

Any non trivial company's systems are not just some random container with a "Nodejs app" inside. They need to keep state, handle caching, redundancy, global CDNs, and lots of other layers.

You either build all those and full ops on top of containers (or whatever), or you get them off the selves and ready to play with a serveless service and their state solution, plug-and-play ready-to-use caching layer, and so on...

Maybe I'm not patching correctly, but I never found keeping an LTS OS up to date to add a significant amount of work over keeping frameworks up to date, let alone 10x.