There are 4 (Dev) Ops in IT
#DevOps #SDN
While some might still be focused on SDN with an OpenFlow-style twist, 30% of the organizations in our survey this summer (report forth coming, I promise!) were looking at SDN to improve time to market. Of those, 73% considered an API-enabled infrastructure to be important to very important.
That makes sense, considering that programmability is increasingly seen as an enabler to improving time to market through automation and orchestration of provisioning and deployment processes as well as abstracting "the network" into services provisionable by line of business and application owners, a la IT as a Service.
These same types of efforts are ongoing in other operational areas under the moniker of DevOps. But as has been recently expounded upon, DevOps is not just about automation no matter how closely we associate the latter with the former. Yet most people, when asked, clearly indicate that automation and programmability are critical to a successful DevOps initiative.
54% of respondents from CA's "What Smart Businesses Know About DevOps" named "IT Automation" as the most critical component of DevOps, and Puppet Labs "2013 State of DevOps" found that 82% of the highest performing organizations relied on automation.
What might make everyone happier and clear things up a bit is if we start referring to the tools and programmability as what they are: software-defined operations or SDO. Some might prefer the term "continuous delivery" but that's an outcome of software-defined operations, not the tools and technologies themselves, IMO.
Much like its network-focused counterpart, SDN, SDO is about operationalization. It's about using APIs and templates and data path programmability in conjunction with automation and orchestration tools like Puppet and Chef, Ansible and VMware, and software-defining operations.
Why muddy the waters with another TLA? Because DevOps isn't just applicable to one group of operations in the datacenter. DevOps is, in fact, an approach highly applicable to network (and security) operations, too. There are four "ops" in core IT, and each one can benefit from DevOps because it isn't a set of tools or standards, it's an approach. The reality is that “ops” isn’t a single silo within IT. Every domain within IT has a segment of its population that are operations. Network operations, security operations, storage operations, and the group apparently with no other name but that focuses on app operations. DevOps is (or should be) about all ops and it’s really important to remember that because any ops left out will immediately become an obstacle to scaling the data center and a bottleneck in the quest to improve time to market.
SDN is DevOps for network operations. SDO is DevOps for app operations. When you put them together you get an end-to-end approach to operationalizing the deployment of applications.
Most of the time, introducing a new term into an already confused marketplace isn't a good idea. So introducing a term that spans two already confused marketplaces might be considered, well, crazy.
But in this case, making the distinction might actually help to clear up some of that confusion. Because what we've got now is an incredibly diverse set of opinions on what DevOps is and isn't, and what SDN is, and isn't that isn't really helping any one.
Stepping back and looking at the problem from "what are people trying to do with these architectures and approaches " yields a pretty simple and understandable picture.
Even if we don't call it SDO (and I don't really expect anyone to do so), the point is to recognize that SDN and SDO are really subsets of DevOps, each with a focal point on a different piece of the app deployment puzzle: one on the network, one on the app infrastructure. DevOps as an approach is the best way right now to address the bottlenecks that impede the time to market for applications critical to gaining and/or maintaining a competitive edge. It can reduce the risks associated with deployment and produce consistent, predictable and repeatable processes that are better able to manage more and more frequently deployed apps.
Its benefits aren't peculiar to either "app infrastructure" or "the network". DevOps benefits can be realized in both arenas and, in fact, must if we're going to enable the business to take advantage of the new application world.
Shameless plug: There will be a lot more discussion about the concept (DevOps and Networking) at Devops4Networks this month. Check it out and swing by if you can! If you can't, follow along on the Twitters @devops4networks