In the last two years, we have seen VMware win a lot of market share by delivering limited orchestration capabilities. The key success factor is that VMware has abstracted the operating system from the underlying hardware, such as CPU, RAM, storage array and networking. The ability to move Windows and Linux servers from servers to server is hugely cost-effective. It seems that these successes have driven a sea change in vendor attitude to "allowing" orchestration unless they are frozen out of a collaborative market.
This business drive, coupled with the success of "Web 2.0" platforms, means that most vendors now developing, publishing and supporting APIs that allow external configuration. For example, Cisco Nexus switches expose a complete XML API using upcoming industry-standard NETCONF/YANG; storage arrays (including EMC) have proprietary and open (VAAI and VASA) standards; Mware has several APIs for Java, C# and Perl, as well as Web APIs.
In addition, the rise of decent programming skills and tools is at the point where useful software is now much cheaper to develop and deliver.
The Case Against Any of This
Let's summarize arguments against orchestration (but you recognize more than a few traditional negative change problems, too).
- It's never worked before. Why should the new software work any better?
- It's not able to be trusted. Only manual configuration devices lead to certainty that it will work as planned.
- It requires extra resources to manage and maintain, as well as multidisciplinary skills.
- This is new, and skills on these products will be hard to find.
- It becomes a change prevention tool in its own right. Upgrades to orchestration software must match hardware and software of the individual elements. The loss of flexibility may cause service delivery impact.
- We have never done it that way before.
- Many companies aren't big enough to comprehend and use orchestration.
- There will be a loss of troubleshooting skills.
- Dependency on orchestration platform becomes organizational weakness and potentially leads to skills loss.
And the list goes on. The reality is that orchestration is a big thing, requiring big changes in organizations, changes in skills and team disciplines. And it's risky. Mucking around with live services on the crucifix of change control and unrealistic SLAs make sweeping changes difficult or impossible. Knowing what you are up against, is it worth it? More importantly, what can we do to raise the chances of success?
