Contain yourself – literally. You can't avoid Docker, K8s for long

"In addition, Docker solves another problem: installing software. Before Docker, developers had to use tools such as Chef or Puppet to install software reproducibly."

I would argue that the idea of Docker replacing the requirement for some type of configuration management is just plain wrong. Whilst it is true containerisation provides a very convenient way of deploying discrete applications without the risk of updating relevant libraries or packages, in my experience you still need a method of controlling the actual configuration of those microservices (things like nginx.conf or dhcpd.master for example).

The real power of containerisation is when you integrate that technology stack into a CI/CD pipeline where your unit testing (or whatever quality control is imposed) is as close to production as it's going to get. Part of that pipeline is usually something like Chef or Puppet which controls the state of those configurations as well as dynamically updating them depending on the environment (templating).

Other than that, pretty good article :)

Rocket/rkt?

How did you write this article without mentioning Rocket/rkt? My guess is that if Docker goes out of fashion it'll be because Rocket/rkt has replaced it.

vmware made things easy

Docker makes other things easy, but not nearly as easy as vmware did. There is a ton of work to do containers the right way.

In the early days of vmware you just installed vmware on your existing OS (before standalone hypervisor existed), and off you go, quite intuitive. For the most part things worked the same in VMs (from a functional perspective) as outside VMs.

There is some docker work going on at the org I am at, I haven't done any of it myself, but I have seen from the sides the amount of effort it is taking to tie it together. Not something I have any interest in getting involved with.

On the flip side I have spent a decent amount of time with LXC(and we have had it deployed to production for the past 3+ years) and it works fine, solves several needs(great for stateless web servers where scalability is not well known) though itself is not perfect. Far easier to get up and going with LXC than with Docker as by default LXC is similar to a Linux install. You have an IP, you have a file system, you can run all the regular linux things inside the container. We manage our LXC containers with Chef(I am no fan of Chef, way too complex, but more effort to change to something else than stick to it - I miss CFEngine v2 which I used prior to Chef) just like the VMs.

To clarify a bit we run LXC on bare metal hardware, that is one of the benefits for us anyway. Taking out the CPU scheduling component of the hypervisor. Running LXC inside of a VM(for me other than testing purposes) would be a waste.

Of course we don't use LXC like most people use Docker. My LXC containers have runtimes measured in at least months if not years.

To me docker solves a problem that shouldn't exist - horribly built applications that break often, agile, low quality, interdependency hell that makes DLL and RPM hell seem like a vacation by comparison(hello ruby and node), and just such crap that the only way they can manage it is by putting it all in one thing. It's really sad. Then there's the "oh just download this script, run it as root and it will setup everything for you" mindset which is just as bad.

I mean I thought ruby was bad when I first supported an app stack running it 11 years ago. But holy shit it's just gotten FAR worse(and node even worse than that) when it comes to bat shit crazy dependencies.

(been supporting in house apps/infrastructure at various companies for the past 18 years now)

docker build ... Ah, crap!

Docker is wonderful until you try to build a container, and it doesn't work because of some obscure thing. Right now I'm fighting a Python pip problem. Works great outside of docker, fails miserably inside. "No compiler or bogus args" is what the message is like. No fun.

Swarm and Docker EE

Docker (the company) eventually realized popularity of k8s and added support to enterprise edition, basically managing swarms and k8s all together. Same as AWS with EKS or MS Azure.

Virtualisation != containers

The two are typically used to achieve different things and for different reasons. Sometimes not very technical ones - for example to achieve cost-effective licensing of enterprise technology platforms. Yet every Docker article I read seems to compare (and never contrast) them. I haven't used containers but from everything I read I see no reason why the two would not be complimentary but they are not (necessarily) the same and exchangable.