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