What is the point of Puppet/Chef anymore? A dockerfile specifies everything you need. Do people really want to continue to script company specific infrastructure code? In the future, with a docker file, can't a container service just figure out the loadbalancers, networking, etc? Isn't this more secure? Will this end the devops madness?
The container orchestration craze (i.e. Kubernetes et al) is buoyed by irrational decision making. I.e. the number of legit use cases are much smaller than the number of implementations purely because it's cool or career building.
Meanwhile, in the cost-efficient world, running 5-10 mega-machines in rackspace and managing them with Ansible is still often the most rational option.
for some reason, hopping onto the hypetrain and shitting out a github repo over the weekend that does the minimally possible thing for a really new technology is about as much career building as having been the PM responsible for google maps.
"having a repo" is somewhat equal to claiming non-"provable" 5 years of experience.
Where is this container service? Maybe it's in the cloud, you're paying Amazon for it. That's a possibility, and there's nothing for you to do there, but maybe you're a F500 company (or Amazon) who runs everything in-house.
How do you provision the container cluster host? Maybe you PXE boot, but you still need a configuration to join the cluster.
Maybe you don't configure via confs, and instead try to auto-detect nodes via multicast. Sure, but now you're constrained to a single broadcast domain on your network. Can't make that too large or you'll have a very chatty network.
How do you provision the switches? They need configurations still.
You'll also want security enforced on the hosts, to ensure certain container ports aren't exposed to the world (oops MySQL is now public due to a debug container instance getting rolled into production).
You still need backups of your data. What, where, when are the backups? I doubt tape robots connect into containers, but I could be wrong.
So there's definitely ops work to be done, and configuration management is a part of it. Maybe you outsource this, but it has to be done.
Let's go back to the what goes into the container. You're going to be running an application, and depending on the language you may need to compile it, and your production containers are going to be slim so you strip the build tools. So you need some other kind of build container or host to manage this.
In most (all?) cases you're going to want to test your code. This means a CI system, and probably a CD system since you want containers to be built automatically with the latest code so it's easier to deploy. What manages the CI/CD system? More importantly, who? DevOps, in the conceptual sense, even if the title changes.
As docker is a userland[0] app it does not provide that natively (there are some workarounds).
My workflow:
1. machine setup - puppet or ansible 2. Is machine ready for app? If yes pull app using Docker or Git 3. Need to modify update? Change configs, commit (always version your puppet/ansible configs and apps) 4. Profit
[0] - https://docs.docker.com/get-started/#container-diagram
Function as a Service platforms such as AWS Lambda are definitely a step in the right direction.