I’ve written before about all the things that go into a trend we and others are describing as ‘DevOps.’ The subject of a coming 451 Group report, DevOps at its heart represents the intersection and integration of enterprise software development and enterprise software deployment, a.k.a. IT operations. To more closely examine the topic and gather other perspectives on devops, I attended DevOps Days in Mountain View, Calif. last week. Here’s some of what I encountered:
Culture of DevOps
One of most frequent words, discussions and topics was ‘culture,’ which similar to devops itself consists of many layers, including corporate culture, developer culture, admin and operations culture, management culture and open source culture. One individual cultural difference mentioned centered on how operations pros tend to be specialists in storage, network, Web operations, etc., while developers tend to be more generalized in their tasks and expertise. This was only one perspective, but I think it is one that is fairly common and true. Another cultural point was that sysadmins can be good developers, but aren’t always aware or don’t always know of the best tools and practices, which are more natural for a software developer. A related point was that this devops is good stuff that good sysadmins have been doing for years. It is true that as we describe and discuss devops, many organizations are recognizing that they are already doing it and already capable of it. Some of the other discussion on culture centered on changing from the bottom-up, which is where we see parallels between devops and open source, or from the top-down, where effective leaders such as those at the conference could steer an organization in the right direction.
The event also provided an opportunity to learn about additional resources, and several acknowledgements were made to Visible Ops, a handbook on improving IT operations written by Tripwire’s Gene Kim, who was in attendance. There was also reference to Leading Geeks by Paul Glen.
On the panel I was on, ‘Making the Business Case,’ I made a point that devops seems to be creeping and seeping into enterprise organizations similar to the way open source did — through the developers and ops people in the trenches, without cost or procurement or policy or awareness from the executives. However, I was reminded from a devop in the audience of the importance of maintaining respect for all of the different stakeholders in devops, which I’ll discuss in a bit. Bottom line, there needs to be trust and respect for devops and opsdev to work, understanding that each role and step in the hopefully improving process is important.
Aside from being a major focus of the conference, culture (and proof you were truly in a big room filled with devs and ops geeks) was also readily apparent with Ignite sessions including a Chief Eff You Officer and a job offer: ‘If you like to write code and hate all crap you have to deal with …’
Stakeholders of DevOps
It doesn’t take long when discussing devops to realize that it involves a lot more than people from dev and people from ops. While these folks, and many in attendance, report bouncing between development and operations, transitioning from one to the other or betting hired as an actual devop, there are a number of other people that come into play. Topping the list are the business requirements people who are increasingly shaping the application itself and when/where/how it is deployed. Those keeping track of company, product, team or division success, productivity, responsiveness and improvement are also involved in devops, and tracking and proving efficiency and performance are critically important. Of course, at some point, the leaders and executives of a company need to be involved, but it also goes the other way to users, who may be the first judges of devops as they give code and processes their first real-life tests. There are yet more stakeholders in devops, including security pros, which leads to another class of devops: secops.
Of course, like open source, devops probably wouldn’t amount to much if it didn’t have some champions, and one individual who seemd not only ready, but excited to carry the torch is Dan Nemec, who provides some of his thoughts on devops at Geeks Gone Mad. Canonical’s Clint Byrum also told a common story of working both sides – dev and ops – to understand the challenges and rewards of both groups and how they might both be better off in it together.
Another stakeholder that I hear about in devops is the single CIO, VP of Products or VP of Product Quality or other title who is in charge of an enterprise application from development to deployment, or as heard at the conference, ‘from code to cash.’ The many stakeholders that can have a hand in devops also highlights the need for a proper handoff, whether code and communication are going from dev to op, op to dev or back again.
Lastly on stakeholders, VMWare’s Javier Soltero, formerly CEO of Hyperic before it was acquired by SpringSource before it was acquired by VMware, made the point that the different people of devops have different tools and responsibilities, and it often comes down to paying enough money for the best people and keeping them.
Technology of DevOps
While much of the discussion was about culture and people, this is still the software and IT industry, and there was no shortage of discussion regarding technology. Attendees seemed to agree that technology and tools are perhaps most effective at changing culture and improving both software development and deployment.
Hitting on a common theme of the need for predictability, OmniTI Founder and CEO Theo Schlossnagle stressed that a devop, or anyone for that matter, should never wonder what’s wrong with an application, but rather that the application should tell you what’s wrong. Automation also figured in frequently to the discussion and serves as a critical underpinning for devops, at least successful devops. Along with automation is its elder cousin, agile, which also brings web application development and lightweight application development, leading some to wonder whether devOps is actually WebOps? What really got a reaction was when late in the day, someone on the panel talked about giving developers root access to the systems, to which one enthused devop, or op-dev, or some guy replied: ‘Yeah!’
The bottom line for the technology of devops is that it must win both sides time while removing the hoops through which they must jump. Devops do need to be able to tackle issues and do the work of devops, but they must also be able to prove their improvement and justify it, thus emphasizing the need for monitoring and tracking, which has long been an integral part of devops.
Throughout the presentations, there were references to devops communities and tools groups, including devops-toolchain.
Future of DevOps
As we continue to prepare our report on the topic, we have little doubt about the current and coming impact of devops. There will be more sharing of culture, code and practices. Open source software is one thing both devs and ops seem to already have in common, and we’ll also be watching that part of the story. In addition to sharing open source software tools for development and operations, these groups are also sharing open source practices such as collaboration, transparency and speed, all of which can contribute to successful devops.
We also expect trends such as virtualization and cloud computing to both encourage devops by facilitating more communication, co-management and mutual consideration and to also force devops by putting time, quality, uptime and other pressures on both devs and ops.
It’s here and it’s spreading. Have you thought about devops?