Distributed orchestration software is only just starting to become usable. See http://rancher.com/.. http://rancher.com/... I wouldn't call infrastructure softw

Distributed orchestration software is only just starting to become usable. See http://rancher.com/.. http://rancher.com/... I wouldn't call infrastructure software dead. It's the beginning. I think the problem is that most existing tools/engines/components which make up software systems (e.g. databases, memory stores, frameworks, etc...) were designed to run on a single machine and so far, it's been the DevOps' responsibility to scale them manually. Even for those components which DO support clustering; their approach is often not compatible with most orchestration systems (they tend to micromanage the cluster - Instead of micromanaging the cluster and thereby fighting the orchestrator, the focus should be on writing simple hooks for the orchestrator to invoke). Developers of tools/engines/components need to change their mindset and start building engines from the ground up to run on distributed orchestration software like Kubernetes, Swarm or Mesos and automatic scalability has to be BUILT INTO every component/service. A major problem is that there seems to be a massive skill divide between DevOps/SysAdmins and Software Developers - Software devs think of systems like Kubernetes and Swarm as being the responsibility of DevOps people and don't spend enough time thinking about how it impacts them. This is the wrong attitude - The two skillsets need to converge in order to build effective solutions. Orchestration management tools are the new operating systems - In the same way that one can build apps/systems which are compatible with Linux, Windows or OSX, we should build apps/systems which are compatible with Kubernetes, Swarm or Mesos. There is more to these orchestration tools than just writing up config files - The code within the components themselves have to be designed to play nice with the automatic scheduling/orchestration requirements.