Borg: The Predecessor to Kubernetes
I think it'll be quite interesting to see how the smaller players organize themselves around the multitude of cluster resource management tools emerging as a natural reaction to Kubernetes growing out of the work Google's done on Borg.<p>I am curious to see how long of a shake-out period will exist before there's either a de facto stack of "compute resource" tooling, or if there's always going to be a highly fragmented and diverse way to accomplish your goals. Just off the top of my head (and there's way more) I'm thinking about Tectonic[1], Mesosphere[2], Rocket [3], Kismatic [4] as a few examples.<p>As a technologist and a planner, it's been challenging to see far enough into the future to decide on what tools to devote myself to learning at this point. I do think we're certainly in a "post-public cloud" timeline where we're getting good enough (or will be in 6-12 months) at abstracting virtualization right up to a millimeter or two below the application layer of our stacks. How we choose to do so seems to be currently up in the air.<p>In my mind, this opens up the possibility of compute as a resource much wider than had previously been possible. We'll be less reliant upon Azure, AWS, and GCP's mixture os Paas and Iaas and much more interested in compute as a resource, likely from bare metal or private cloud providers.<p>I'm looking forward to the increased efficiency (both through compute power and cost) and security available in moving from a application-level virtualization to operating system-level virtualization.<p>[1] <a href="https://coreos.com/blog/announcing-tectonic/" rel="nofollow">https://coreos.com/blog/announcing-tectonic/</a>
[2] <a href="https://github.com/mesosphere" rel="nofollow">https://github.com/mesosphere</a>
[3] <a href="https://github.com/coreos/rkt" rel="nofollow">https://github.com/coreos/rkt</a>
[4] <a href="https://github.com/kismatic" rel="nofollow">https://github.com/kismatic</a>