If it weren't containers it would be a new programming language, framework, or another agile methodology. Your argument has very little to do with containers.
Containers are just a better tool for writing OS configuration scripts. (If your team is full of Chef experts then it's not "better" for your team, but for a lot of teams it is).
What you're saying applies a lot more to microservices, which are a fundamental architecture choice. Containers aren't, they're just better than a tangle of bash scripts which create stateful VMs. And the problems you're describing apply no matter which tools a team uses.
Remember that you can use containers without complicated orchestration or microservices. I think a better argument would be to untangle these three things and describe how each one can solve certain problems or make the problem worse, and under which conditions.
> "If it weren't containers it would be a new programming language, framework, or another agile methodology. Your argument has very little to do with containers."
Agreed, containers are just one way to package software, they aren't the be-all-end-all when it comes to making software modular.
One example of a modular design abstraction that does not rely on containers is the data access layer ( https://en.wikipedia.org/wiki/Data_access_layer ). The idea being you can design a service that sits on top of a data store (whether that's a RDBMS or otherwise), that encapsulates the core business logic that you want the applications in your business to adhere to. This data access layer can potentially be shared by differing applications. The implementation of this does not rely on containers. Also, just in case "data access layer" (DAL for short) seems like a corporate IT term, I'd say the best tool I've ever seen that's used to build DALs is GraphQL.
>> Containers are just a better tool for writing OS configuration scripts. (If your team is full of Chef experts then it's not "better" for your team, but for a lot of teams it is).
No, not really. You could argue that dockerfiles are part image provisioning script and part process environment specification, but I think you'd still be missing the main advantage. Dependency isolation is the thing that usually gets touted, but that's only part of the picture. After all you can isolate dependencies now by baking images. That works great, it's well proven and reliable. But the vm that runs a single boot image can potentially run dozens of different containers, and using an orchestration platform you can easily and quickly shift those loads around, scale up and down, reconfigure and redeploy, all with far less overhead then deploying an image to a vm requires. Containers didn't become a popular tool because they don't add value. The use case for them has been clear for over four years now.
> Containers didn't become a popular tool because they don't add value. The use case for them has been clear for over four years now
Well, yes, they did become popular despite not providing anything
substantially new. The main value of containers is that programmer who works
with network now doesn't need (initially) to understand how to configure the
network, which is a dumb idea by itself. All the other things added by
containers boil down to distributing a tarball with whole operating system, so
you can run that in a chroot.
From where I stand it seems that programmers didn't want to learn how to
build, distribute, and configure software with OS packages, so they invented
their own binary packages system.
The irony here being I had to port our production RPM (rhel-based) build system to Docker just so it could have a reasonable API and be anything close to maintainable.
Edit: the extreme portability and "free" concurrency were just a bonus.
Containers are not OS configuration scripts.. they still need a host to run on. They still need networking managed.. im not sure how you figure that one out.
Chef experts likely deploy your underlying hosts, setup other required services (eg load balancers, state)
while you can provide a generic "container" that will run whatever you want and provide consistent ingress/egress points so the "chef experts" can run it without caring what it is they are running
Containers are just a better tool for writing OS configuration scripts. (If your team is full of Chef experts then it's not "better" for your team, but for a lot of teams it is).
What you're saying applies a lot more to microservices, which are a fundamental architecture choice. Containers aren't, they're just better than a tangle of bash scripts which create stateful VMs. And the problems you're describing apply no matter which tools a team uses.
Remember that you can use containers without complicated orchestration or microservices. I think a better argument would be to untangle these three things and describe how each one can solve certain problems or make the problem worse, and under which conditions.