Some good points to discuss here.
Firstly the git history managed via a controller / helm chart. That’s sufficiently complex. The mindset of k8s/cloudnative doesn’t translate easily from the pet vps control server which comes with its own disk and persistence. So conceptually a management layer like cooling is objectively easier.
But that’s a nit really.
I think the idea of management being time consuming is more interesting. It’s true. And I think it’s true no matter what you do.
Time consuming management applies to any sufficiently complex infrastructure or team. No matter what you have these questions to answer.
How is access ma aged?
How does debugging a broken build work?
How does secret and config management work?
How does disaster recovery work?
If you are storing config as code, how are you managing deployment of that?
If you use k8s, how do you manage feature deprecation across versions? Even a managed version won’t help you resolve having to move from some kind of resource/v1beta to resource/v1.
I don’t say this as a slam dunk against anything. I think there are different levels of comfort with certain paradigms depending on what you’ve been exposed to over your lifetime. And the solution that feels most convenient to you is what you’ll want to work with. And for each type of preference we are going to see different solutions. All of which will be time consuming to manage in their own ways at a sufficient level of complexity or scale. Basically I prefer talking in these terms because it shifts the conversation away from broad comparisons to something more tangible which is “where does the time complexity lie for this particular approach”. Teams can put that down on paper and decide which one is more palatable and then go with that.