Since I’ve hopped the fence to the “vendor side,” affectionately known as the “dark side” to some of my peers, I’ve noticed a few things. One is the pervasive delusion that meaningful integration that lowers OpEx and improves the operational experience is someone else’s job or that it’s really not important at all. In fact, it is everyone’s job and the combination of two emerging trends will provide a path for coherently managed infrastructure.
Yelling Gibberish at the Teslas
Becoming an IT architect was one of the most disappointing experiences I have ever had. It was constant stress. Something was always broken. Every vendor promised a bold new future, but that future never came. When called out on it, vendors easily hid in the shadows of the ambiguity created by the overall complexity of an IT infrastructure. They have a palette of colors for painting a picture of blame: Some other piece of infrastructure, some other vendor, or the customer themselves. The overall problem never gets solved, of course. So what does this overall problem look like?
That list isn’t even a complete one and it doesn’t highlight further complexity added by dual-vendor approaches or outsourced services. Every one of those things represents a management touchpoint. Frequently, they require specialized knowledge to operate. On top of the inherent complexity of an IT infrastructure, this silo’d behavior makes getting stuff done hard, whether it’s provisioning, troubleshooting, or just getting stuff to talk. Every operator, engineer, architect, and IT manager has their war stories. Why is operating infrastructure so hard and so fraught with peril?
With the rise of automation and now SDN, many vendors proclaim loudly that they fully support this new way of thinking and they poop out a horrible API or worse a library that amounts to automated Expect scripting. The problem with this, of course, is that orchestration (or choreography) are hard to do. An organization that is already struggling under the weight of IT complexity does not have the cycles to design, implement, and maintain a home-grown orchestration control-plane.
Ethan Banks at PacketPushers recently blogged about application delivery. The point he makes is valid: The purpose of all of this is to deliver the applications. He made the statement that sometimes he wanted to stand on a corner in Silicon Valley and yell gibberish at the Teslas driving by. I know where he is coming from. IT is a disaster and collectively Silicon Valley is responsible. They’ve spent so long marketing and doing business in the context of silos that for some of them it’s impossible to accept that integration matters. They dismiss it as someone else’s job.
DevOps and SDN
DevOps has one goal in mind: Automate everything. Since traditional IT vendors have done little to nothing to help here, this practice is largely grass-roots, community, and Open Source aligned. Slowly but surely the number of plugins and modules for Puppet, Chef, OpenStack, and other tools is growing. Many of the items in the list above have plugins available, or plugins in development.
A number of SDN solutions that focus on the physical network adapt a concept known as “Single System Image” (SSI) for networking. This provides a way for the network to be represented as a single coherent entity. The reason this model is important is because, generally speaking, business policies describe what they want the network to do relative to some workload, system, or application attached to the network. A good SSI network solution allows the operator to express network-wide business policy more directly through intuitive abstractions and an intuitive policy expression framework.
Software in a good SSI solution evaluates all active policies against two broad categories of things: (1) The state of the network, including topology, capacity, buffers, table space, and existing workloads and (2) Information pulled from external systems relevant to the network (configuration, scheduled jobs, etc). Using this information, the controller can best align network resources with desired policies on a real-time, or near real-time basis.
The value of a network SSI solution to DevOps is that plain language network-wide policies can be integrated into existing workflow tools. These policies can be pushed to an SDN controller which, in turn, will do all the hard work of enforcing the policy. Conversely, DevOps tools such as Chef and Puppet have rich policy frameworks. Their configuration repositories are a good source of contextual information about systems and applications that the network supports. SDN controllers can leverage this warehouse of information to intelligently enforce policies. This synergy can not be understated. The combination of intuitive, network-wide policy abstractions and the policy expressiveness of infrastructure automation tools is an enormous step forward in the evolution of IT.
What are just a few simple examples?
- If you configure a cron entry to do an rsync backup on some class of servers using Chef, a simple policy could instruct the SDN controller to automatically locate and extract the relevant information from the Chef API to optimize the network for the duration of the backup.
- A number of plugins for DevOps tools identify specific elements within the associated system. For instance, the Chef module for Ceph (a distributed object store/file system) identifies the components within a Ceph install using the “roles” Chef idiom. This information could be used by an SDN controller to isolate replication traffic between storage nodes.
- A policy in Puppet could tell the controller to configure VLANs on edge ports according to what is configured in the attached hypervisors, and the controller could enforce this in real time by monitoring relevant events in vCenter or OpenStack or by periodically polling them for vSwitch configurations.
- We could leverage such tools to do bare-metal installs of the network itself!
- Lastly, wouldn’t it be great if the network could provide contextually relevant information about it’s state and health back to such tools?
The combination of SDN and DevOps tools is the clear path to real IT integration. Orchestration in the context of the larger infrastructure is the piece that is missing in many SDN discussions. Network vendors need to embrace and enhance tools that aim to fill this gap. What should a vendor do?
- Encapsulate the complexity of the network.
- Provide intuitive abstractions and policy expression northbound
- Continuous interaction with surrounding systems to enforce configured policies in real-time
- Participate in the DevOps community for the good of the community.
- When integrating with a tool you should honor the purpose, the design, the expected style, and the syntax of the tool.
The vendors that do this will win. And maybe, just maybe… you won’t have to work at 2AM on Sunday to configure a bunch of VLANs. You could be enjoying beer instead!