Kubernetes is not a provisioning system. Really? What is it then? Let's see... Kubernetes (commonly referred to as "k8s") is an open source container cluster

Kubernetes is not a provisioning system. Really? What is it then? Let's see... Kubernetes (commonly referred to as "k8s") is an open source container cluster manager originally designed by Google and donated to the Cloud Native Computing Foundation. It aims to provide a "platform for automating deployment, scaling, and operations of application containers across clusters of hosts"[1] Automating deployment? I guess deployment has nothing to do with provisioning a resource... really, if you are going to argue for these tools, you should understand the concepts which they are trying to solve. Or are you one of the developers of one or some of these tools, and this is just rubbing you the wrong way, because it means that your tool isn't required? If so, just state that upfront, so everybody knows where you stand, and we don't have to discuss this any further. [1] http://kubernetes.io/docs/whatisk8s/ http://kubernetes.io/docs/whatisk8s/ Moving right along... your comparison of Docker and Kubernetes to OS packages, Kickstart, and PXE is outright laughable. You clearly do not understand the various purposes of these tools. Okay, then you explain to me why I need Docker to do what I can do with PXE, KickStart, and OS packaging? This ought to be really good... Why not add SmartOS to your list of unnecessarily technologies and apply the same critical thinking? Because SmartOS uses zones, which give one fully isolated, true UNIX servers running at the speed of bare metal, and because it uses ZFS, fault management architecture (fmadm(1M), svcs(1), and svcadm(1M)), performance and post mortem analysis tools, and because it has everything required for massive datacenter and cloud deployments, built right into the operating system from the beginning, and not as an afterthought, knee-jerk "oh shit, we have to scale Linux to massive deployments now" reaction. By professional system and kernel engineers with formal education in those problem domains. imgadm(1M) and vmadm(1M) in SmartOS are the functional equivalents of JumpStart (or KickStart, in redhat's jargon, and AutoYaST in SLES one). That's why. They're not proprietary, they're open source, and you only need one of the four. Proprietary means that someone owns it, or that it is specific to something or someone, not that it is closed source. A product can be both proprietary and open source, and freeware all at the same time if the proprietor is providing the source code and giving the product away for free. They do: Ruby or Python and system calls. Neither of those programming languages are part of the operating system consolidation on a proper UNIX, and on Linux, they are provided in various versions by various people who are volunteers. And anything which is not part of the OS/Networking consolidation on a real UNIX is a third party and unbundled application. That's the only distinction we have ever needed, and the only distinction we have ever made. This mistake was already made once on UNIX, when Perl was hip just like Ruby and Python are now: we are still coping with the fallout of ripping out, and replacing all the Perl garbage which has since been integrated into the OS/Networking consolidation. You haven't yet been busted by that on Linux, but you will be, because Linux keeps repeating the same mistakes which UNIX made. Except we learned from that, and on Linux it just causes more flapping. Between Ruby, Python and shell and AWK, I will always pick shell and AWK (and not even bash, but traditional Bourne shell), because they are stable, the interfaces won't change, the syntax will stay the same forever, they are well understood, easy to learn, and they are small and fast, very fast. I have regularly beaten Python with AWK both in code density and speed (latest: 487 lines of Python code in 183 lines of AWK, and no kernel hooks required like with the Python code). So if you're implying that Ruby and Python are ideal for massive deployments and configuration management just because they're hip right now, that's insane, and I'm not buying it. Okay, so use Chef Zero or Ansible. Why? What does the Ruby dialect of Chef offer me, that I couldn't do in %pre, %post, %preun and %postun in a RPM package? Policy? Policy is best solved with a throughly thought through change management process. Capability Maturity Model and all that, you know? Why aren't you writing your configuration management in C? And just what do you think svcadm(1M) is written in? (Wait, why are you writing it in C instead of assembler?) Who says I'm not? Use the right tool for the job. The problem here is, none of these Chefs, Puppets, Ansibles, Salts, Dockers or Kubernetes are the right tools for the job. Even Linux as the substrate for all of this is not the right tool for the job! But then again, judging by the other comments here, people are starting to realize that, and that's a good thing.