The most challenging part of managing a complex IT infrastructure is not in the silos but the boundaries between those silos. Tools, processes, and even people have to be particularly flexible at the points where workflows intersect. And once these intersection points are codified (through tooling infrastructure, specific procedures, or training), they are exceedingly difficult to change.
The truth is that in most data centers today, orchestrating workflows across disparate IT systems is more dream than reality. For far too many people, automation means writing a Perl script that saves some keystrokes on a simple provisioning or monitoring task. The idea that these workflows can span multiple infrastructure elements, each with its own data and interfaces, is foreign to the vast majority of operations teams.
But SDN and DevOps are going to change all of that.
Imagine buying into the highly-orchestrated vision of SDN, and layering on the automation promised by DevOps. It takes somewhere between a few months and maybe a few years to get the right people, design the right solution, and stand the whole thing up. You spend all of this time and money on an orchestration project only to find that the solution you have implemented works with about 30% of your infrastructure.
What happens next? You update your resume, reach out to some colleagues on LinkedIn, and start paying closer attention when recruiters give you a call.
There's a reason that management is so hard and so few viable options exist. Creating a central management solution depends on that platform being able to control the various elements over which it presides. Even if the management solution is limited to just networking, it means that the management software has to be able to speak all the various flavors of networking-ese that exist across whatever parts of the network are under management.
When a new feature is released by Vendor X, the management platform has to support the feature. If you are relying on that management solution, it means that you cannot even upgrade your network until both the device and the management software support the new capability. Now imagine that Vendor X is executing against a broad roadmap of features, across a wide assortment of platforms. How does the management platform keep up? And then add in Vendors Y and Z with their roadmaps, and you see how hard it is for any management solution to keep pace.
The result is that you go with a solution that is not fully-featured, or maybe you hire an OSS vendor and pay millions for them to keep up, or you limit your architecture to a single vendor so they can provide a management solution. Whatever the path, the end state is ugly. And it ends up being so fragile that any real changes threaten your ability to actually manage your infrastructure. Our industry talks so much about lock-in being in the protocols and device capabilities, but the hardest thing to change is everything but the protocols.
So what happens when you extend the management domain to include more than just networking? How do you achieve real workflow orchestration when you have to now consider both compute and storage environments?
The answer is pretty obvious: the whole thing breaks down pretty quickly. As a vendor, you either have to control the scope (through a tight integration of components), or you have to open things up.
It might be tempting to think that Vendor X can create a management solution that will effectively control Vendor Y, but it is very difficult for Vendor Y to put themselves in that position. The sticky part of IT is how everything is controlled. Making yourself willfully subservient to another vendor is like digging your own grave, hopping in the casket, and handing the shovel to your competitor. Once they own how the solution is controlled, they essentially determine when new capabilities are turned on. Vendor Y creates an awesome new feature, but sadly Vendor X doesn't support that feature in the management solution. Who wins?
So what does opening things up look like?
The currency of orchestration is data. Orchestration is not about subordination; it is about delegation and distribution. You want to take some initial input, and convert it into a set of device or infrastructure behaviors that can be executed by the constituent elements in the solution. The data is all that matters. From that data, you can create subordinate relationships if you want (server is set up, then network is configured), or you can have everyone run off and do their thing semi-autonomously.
But who owns the data relay mechanism? Answer: no one ought to.
This is exactly the kind of thing that open source is great for. A common platform that is vendor and technology agnostic allows the data to be centralized without creating unnecessary vendor tie-ins. If you want to swap something out underneath, the data is still there. Changing out infrastructure doesn't require re-architecting the management solution, re-integrating new tools, revising processes, and re-training your staff. It requires incremental data integration, but even that can be decoupled from the rest of the infrastructure.
Open source also means that you are not bound by a single vendor's R&D budget and priorities. Orchestration is relatively nascent. There is going to be a lot of change in the coming years as we grapple collectively with what it means to manage application workloads across various resource pools. The surest way to maintain an even keel is to keep everyone at the table. Our industry needs to be more inclusive, more collaborative. During these times of massive change, anything that closes doors is just limiting opportunity.
[Today's fun fact: An average-size aardvark weighs about 150 pounds.]