| So let's consider the hypothetical future where you hand a dockerfile to a container service. 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. |