To be honest I only very recently got to know ansible and related techs so I maybe missing an opportunity to learn something. Even so I think you are forgetting the DEV part. With ansible and chef you can make a deployment to the real infra. With containers you can have infra locally in your DEV environment and have clean slates. The similitude of the DEV environment and the production are crucial for devops. There is nothing more annoying for developers than having something work locally and then needing some weird quirk for the production/ci. A lot of political infighting and hate for devops. I saw this being a tech lead for build system in a fortune 500 company.
Ah they have redhat based distro. Ultra stable! Problem is nothing from outside the company works out of the box, leading to blessed machines. A disaster that lead to so much unofficial workarounds that it is not funny. Lol the kernel is so old it cannot run docker:)
Ubuntu is better but ultra stable machines will tend to massive customizations that are very hard to keep when you finally want to upgrade. It was very common to reach End of Life of LTS distros, and then have the server upgrade being a nightmare due to the long evolution that happened in the mean time.
> With containers you can have infra locally in your DEV environment and have clean slates.
True, but you can do that with plain system containers such as with lxd, rather than having that bundled with the huge paradigm shift that Docker comes with.
My experience with lxd is very limited. Actually I worked with liblxc which is the underlying paradigm, and i kind of disagree with you. The paradigm of lxd is much more foreign to me than docker. I am pretty familiar with my application and the distro of the container in a user perspective. I am definitely very insecure about cgroups and kernel namespaces. In the end my application is connected with my business/work orders. Kernel minutiae is not and the technical skill requirements is much higher. That will put a higher price tag on my team's human resources.
> The paradigm of lxd is much more foreign to me than docker.
The paradigm of lxd is pretty much exactly the same as the paradigm of a regular distribution installed on bare metal or inside a VM. If you can operate a regularly installed distribution, then you can operate inside a lxd container. The commands to create and destroy lxd containers are trivial ("lxc launch ubuntu:bionic" for example).
> Kernel minutiae is not and the technical skill requirements is much higher.
I'm not sure why you think you need to know kernel minutiae, cgroups or kernel namespaces. Operating lxd needs none of that.
> I am pretty familiar with my application and the distro of the container in a user perspective.
