> “We switched to the cloud” isn’t a decision made by development orgs in any non-software company. In most businesses, supportability by IT and boring bureaucratic processes are king.

This might have been true in your experience but it hasn’t been in mine (.com, .edu, .gov). There’s common term (shadow IT) for what inevitably happens: someone hires their own staff, gets their own servers, arranges their contractors to host it, architects their application requirements so it can’t be run by central IT, etc. The reason it happens is that the IT department is not listening to its users and thus giving them a strong incentive to find alternatives to accomplish their jobs — and they’ll almost always win unless the CIO is politically untouchable and has an iron hand on the budget.

This is especially true in these cases: using the cloud or containers is what senior management are hearing from all of their consultants, and likely many peers. If you’re trying to hold that back without a really good reason, it is unlikely to end well for you unless you’re related to the CEO, especially since it’s easy to find people with equivalent or greater experience who can point to good results from having adopted what are now relatively mature technologies with plenty of case studies.

> “Adopt whatever buzzword shit developers are into” is about the worst career advice you can actually give sysadmins that work in non-cutting edge companies.

If you think that’s true, I would suggest you reread my comment and ask whether that’s a fair reading of my suggestion about finding a way to balance concerns. There is a huge amount of space between “no” and “you can run whatever you want”.

I've also been doing that for about 25 years, with a similar list, and full automation since ~2001 or so. I haven't found that approach to scale very well because it requires a much higher level of sysadmin skill & application-level knowledge, maintaining a somewhat extensive list of backports or custom builds, and the ability to customize each application to work with a filesystem layout which avoids the conflicts which inevitably arise. Automation is important to making that work at all but it still means that any time things change hands there's a non-trivial amount of code to review before you are confident about making changes and it tends to require elevated privileges or greater levels of coordination between the developers and operators.

The reason why containers are popular is that you get a simple way to manage all of that and it's completely standard on every project. App A doesn't need to be modified to coexist with App B because they're running in an isolated environment, the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances, builds are much faster because of the layering model, you can deploy a single tested image with no chance of differences creeping into your automated deployments in testing & production, etc. All of that is something which you can achieve with other tools but there's a huge win to not having to reinvent each wheel when you encounter it and being able to reuse other people's work easily.

Note also that I said “containers” instead of Docker — some people might prefer, say, podman / buildah but the key concepts of having a clear support boundary with an isolated-by-default filesystem model are really more important than the implementation.

You know why docker is being used instead of this approach?

Because your automation is made by you, and for you, no one else can take it over if you leave. And even if they can take it over, they will have way higher salary - compared to the container based system.