This kinda makes the mistake that nearly everyone makes with regard to containers: They view the container as a black box into which complexity disappears.
A container doesn't consume complexity and emit order. The complexity is still in there; you still have to build your containers in a way that is replicable, reliable, and automatable. I'm not necessarily saying configuration management is the only way to address that complexity, but it does have to be addressed in a container-based environment.
Now, I understand that in many cases some of the complexity is now being outsourced to others who maintain the containers (in the same way we've been outsourcing package management to operating system vendors for a couple decades), and so maybe some of the complexity has been pushed outside of your organization, but you have something being deployed that is internal to your org, so you have to deal with that complexity. Container management tools just don't do things at that level.
There's always a point where what you're doing is unique to your environment, and you have to be able to manage/reproduce/upgrade it somehow.
> Now, I understand that in many cases some of the complexity is now being outsourced to others who maintain the containers
We have a winner.
Containers in the end looks to management and developers as a means of outsourcing those pesky sysadmins that always get in the way of dreaming big.
Its not without reason why devops and containerization seems to go hand in hand, as both are pretty much about neutering or sidelining the sysadmin role.
The sysadmin role isn't being neutered or sidelined, it is being moved from something every company has to do to something that primarily will be performed by large providers at massive scale. System infrastructure and the management of it is becoming commoditized, and containers are one part of that story, just as the increasing level of abstraction of cloud platforms is another.
The more a complex system increases in complexity (parts) the more likely some part will fail and the less likely that failure will create a catastrophic failure. (Mark's Law)
Any sufficiently advanced technology is indistinguishable from magic. (Author C. Clark)
With the advent of AI we will soon reduce IT into magic.
I guess that's true if you're treating containers and the environment they run in as "another layer" of stuff that you use configuration management to deploy on top of your existing automation you maybe already had prior to adopting them. I do suppose that is probably true of many users still today. There is also the use case of updating your base image or AMI and then replacing slaves/followers/your servers that run the containers, more or less eliminating the need for a job that is constantly running, or running on a schedule to keep the host system up to date. It's true that in the case of container hosting systems, that is mostly being abstracted away from you, and this post was written with that mindset as we do just that. Good comment and point of view though, I think it's still something a lot of folks struggle to wrap their heads around!
A container doesn't consume complexity and emit order. The complexity is still in there; you still have to build your containers in a way that is replicable, reliable, and automatable. I'm not necessarily saying configuration management is the only way to address that complexity, but it does have to be addressed in a container-based environment.
Now, I understand that in many cases some of the complexity is now being outsourced to others who maintain the containers (in the same way we've been outsourcing package management to operating system vendors for a couple decades), and so maybe some of the complexity has been pushed outside of your organization, but you have something being deployed that is internal to your org, so you have to deal with that complexity. Container management tools just don't do things at that level.
There's always a point where what you're doing is unique to your environment, and you have to be able to manage/reproduce/upgrade it somehow.