For better or worse, IT has long been a land of specialization. Network administrators didn’t talk to storage administrators, who didn’t talk to server administrators. Application developers didn’t talk to operations. Silos sprouted not just among applications, but among departments. There are those who suspect that such fiefdoms thrived because they provided easy targets for finger-pointing when something went wrong and wasn’t easily fixed.
The problem is not only that such stratification can’t survive forever, but it’s also besieged by other factors. For instance – if the business is demanding responsiveness from IT, it’s unlikely to get results from groups of people who have no experience talking to each other, much less collaborating.
At the same time, with virtualization infiltrating each department, it behooves administrators to learn together, not only about how “software-defined” affects them, but also how their systems, storage, and networking realms are affected by advancements such as converged infrastructures.
Forward-thinking technology folks have made efforts to improve the situation. On the one hand, they’ve created the role of a virtualization administrator to work side-by-side with the other admins. Just as pertinent to software-defined networking is the development of the DevOps team.
It’s just what it sounds like: an agglomeration of the development and operations teams, in order to help each side understand just what happens when an application hits the system, and then improve one or the other in order to make the next iteration that much more efficient. As SDN Central notes, “In software-defined networking (SDN) and virtualized environments, DevOps tools are essential to creating a more flexible and responsive infrastructure. Integration of DevOps focuses on product delivery, quality testing, feature development, and maintenance releases to increase reliability and faster development. DevOps also promotes a set of processes and methods for communication and collaboration.”
To integrate DevOps into SDN is really so logical, Mr. Spock could have come with it. SDN is about programmability. What better way to make it responsive to business needs?
As Search SDN’s Crystal Bedell notes in her article, Where SDN And DevOps Tools Meet, “Until now, the network has not been agile enough to play a key role in this transformation in management. … But SDN promises to change all of that. Among many other features, SDN will enable automated provisioning of virtual networks that can be responsive to applications. This provisioning can be integrated into a larger orchestration context. That's when the network will take on a key role in the DevOps revolution.”
If you want to know more about the convergence of SDN and DevOps, check out SDN Central’s collection of videos. There, systems integrator Colin McNamara presents some compelling arguments for how the two not only work together, but make the other better. In the DevOps: Moving Into the Network video on the video page, he offers kudos to Martin Casado and the others who created SDN, noting that they “forced the incumbent players to release programmatic controls of cool networking stuff. Now we’re seeing networking itself starting to contain the capability to be programmed, controlled, instantiated, tested with that same level of control of system storage and networking. We can use a lot of the same tools and methodologies we’ve used in the past for devops … to control [the network] like a program.”
In the Who is the Real Threat? video, a discussion of who really has the power to bring down your network, he says that DevOps can help “provide safety to [changes], mapping the interactions of network systems, storage, and applications. [With DevOps], you can provide validation and a tool chain which allows you to quickly and safely validate that your network will stay up, that your application will stay up.”
Finally, check out this document relating to the OpenStack subgroup Neutron, the goal of which is “to implement services and associated libraries to provide on-demand, scalable, and technology-agnostic network abstraction.” In it, Nuage Networks’ Scott Sneddon describes the goal of “policy-driven networking,” one that creates an application-centric approach to networking. The goal – cadged from OpenStack itself – is to create “a highly abstracted interface for application developers to express desired connectivity of application components, express high-level policies governing that connectivity,” but to do so “without imposing constraints on the underlying implementation.”
As Sneddon restates the worthy goal: to “remove the burden of the ‘network design’ from the actual instantiation of a network service.” Silos and those unwilling to collaborate beware.