Published: 18 May 2012
There’s a good chance you’ve never heard of the DevOps movement, but if you’re a network engineer you’ll have to learn about it soon enough. DevOps, a composite of “development” and “operations,” is an IT industry movement driven by the software development community to integrate software development organizations with IT operations.
As with so many areas of IT innovation, the cloud is the catalyst for change when it comes to DevOps and the network. Since both system administration and development can now take place in the cloud, the future will require developers to know system administration and system administrators to know programming.
In fact, Steve Shah, director of product management at Citrix Systems, sees the DevOps movement as a new wave in system administration. Five years from now, new systems administrators will be programming APIs to replace the old school tasks of managing physical infrastructure, he said. Networks will be a part of that, and network engineers will find themselves in meetings with DevOps teams asking them about the compatibility of their infrastructure with this new technology.
In this Q&A, Shah offers some background on the DevOps movement.
Why do networking pros need to know about the DevOps movement?
Steve Shah: Let me start by providing a little bit of context about how we all came into the DevOps ecosystem. Citrix has a special kind of reverse proxy server that is designed to make web applications go faster. So we’re using—as a platform—the largest websites in the world, eBay and Amazon [Web Services (AWS)].
As traffic is flowing into the web-based application, we’re able to do to a lot of optimization on that traffic. [This includes] everything from cleaning up TCP/IP and speeding up processing to actually changing the way that applications are accessed so that there’s quality-based access and controls for being able to designate locations for that data. An image, for example, might be moved to one set of servers, and if it’s an application, [it could be sent] to a better set of servers. Managing all of this cost effectively could cause network problems, not to mention financial managerial issues.
It has almost become the case, where the ability to understand infrastructure is secondary to the programming ability.
Where did the DevOps movement come from?
Shah: System administrators started looking at things like automation when they found themselves dealing with tens of thousands of servers as early as 2003-04. They would come to us and say, ‘Someone has written a script that will change configuration and a bunch of software engineers changed some of the commands we were using to automate.’ So, they’d have to go back, change commands, adjust how it worked, etc. Around 2005, we started developing APIs for SILK-based access, and XML was all the rage.
Citrix provided a SILK-based interface that people liked because it didn’t change. Even if the way that information was displayed did change, you could still count on the configuration. From the developer’s perspective, changing configuration on a version-by-version basis was cumbersome, so each API did a nice job of managing that problem.
Secondly, programmatically accessing data made network automation a lot cleaner. That kind of developed into a loop. And what made it really click for a lot of people—and what became the genesis of DevOps—is the fact that a lot of the admins were early on in this space, and they were all network administrators who knew cables, routers and switches, and a lot them knew how to do basic-level programming. They started turning to these tools to help them churn through their network issues because you take somebody who has a hundred infrastructure devices out there just doing network load balancing, and they want to aggregate that data.
What were all these systems doing at a given moment, and how would servers react as a result? They would poll all of these devices for information, and then they would want to churn it up as data written to an API called PERL to really reach a logical process and come up with a solution to a problem. That way, managers could report back to say, for example, ‘Based on what I’ve learned, you to need to change your policy this way. I want you to redistribute the load in the network according to this new information.’
That really drove the start of the idea that we shouldn’t be using general system management tools, that we should be using programming languages as our primary interface for managing our infrastructure.
This idea has created a whole new kind of system administration. Where system administrators before were valued based on their expertise with devices and infrastructure, the DevOps administrator is valued for his programming skills and his ability to understand infrastructure. It has almost become the case, in some places, where the ability to understand infrastructure is secondary to the programming ability. So with all of that motion happening, the next phase of the DevOps movement was formalized around the availability of REST-ful (Representational State Transfer) interfaces.
Why did they feel the need to create new interfaces?
Read more on the DevOps movement
A DevOps primer for network engineers
Network technology trends 2012: Out-of-band management and DevOps
Survey Results: No longer an emerging trend, DevOps is here to stay
From DevOps to NoOps: IT operations pros dwindle, developers rise
How will network engineers work within the DevOps movement?
Shah: First and foremost, you’ve got to get comfortable with writing scripts, automating basic tasks, even before you get fancy and talk about a lot of automation. That capability has always been there, but not many network engineers can manage it. So for adoption of that field to really become commonplace, you want to get into DevOps, understand it and leverage it.
Once you’ve gotten that foundation, something that you want to be able to do is get comfortable with the interfaces that your devices offer you. A lot of the companies that offer APIs are much like Citrix—we’ve been doing it for a couple of years already. The APIs are mature and documented, so you pick up the documentation and start. It’s easier than it’s ever been.
From there, [rather than] go through how to add a piece of configuration, change a policy and things like that...I need to know my end-to-end workflow. I need to go and get, for example, two racks of servers up and running. And then I can really start to see the advantage of scripting. So I turn on the server and make sure its responding to me before I start it in traffic flow.
By the time you’re done, you might have a monster amount of code, but you’re able to replicate it into the data center, so the time it took to write that script might have been the same amount of time to roll out a rack of equipment. But now, out of the 10 to 20 racks I had to deploy, I can take that one rack and roll it out over and over again, and it takes minutes.
Do networking professionals need to open up their infrastructure to be manipulated by these scripting technologies?
Shah: The short answer is yes. However, the devil’s in the details, so if you want to have access that is roles-based, controls are as important as ever. Like any process that gets defined in a data center, you will write down steps. Make sure people follow those steps over and over again. You want to have someone looking over your shoulder and make sure it works correctly and that it has no unintended side effects. Then when you execute this, you really have to leverage the API, and before you even know how to use the API you should be asking: Who has access, what can they do?
Do you think that networking vendors are going to be introducing new products into the market that will support the DevOps movement?
Shah: Absolutely, I think if you look at the broader motion of what’s happening in networking, the big topic for all of this is fabric networking. And where you want to go with this is optimized routers and switches to make it less complicated, so you have one big full network—though you still have a bunch of other problems related to virtualization.
To play that out a couple years forward, one of the areas you start seeing that is interesting technology is called OpenFlow. It’s all about being able to do programmatic controls for all the traffic going to the network. OpenFlow really puts DevOps at the center of how networks get managed. Search around OpenFlow and you’ll see links to all the products that have been created around it. It helps you automate all the scripts that you’ll use and so forth.
OpenFlow is still an extremely nascent technology. The fabric movement as a whole is still nascent, but it’s happening. Application delivery controllers are transitioning to be integral to how the fabric operates; it’s a key part of how we see networking evolve over time with DevOps automating policy in the network.