DevOps is officially an amalgam of Developers and Operations, two separate strands of the software management and network administration processes. Development and Operations are often in contention with each other – but both are essential to success.
DevOps sets out to bring the two together, and have them work in harmony. It started as a buzzword, morphed into a trend and is currently evolving into a global movement that could impact an entire businesses – not just IT.
A Clash of Cultures
Stereotypes have been part of the problem. Traditionally, developers have been viewed as tweakers and innovators – risk-takers willing to do whatever is necessary to move a project forward. Operations people are quite the opposite: their concern is to keep things running smoothly – “Don’t rock the boat”, and all that. For them, change isn’t good unless it can contribute to maintaining the status quo – preferably after having been field tested and verified, for several months.
Not the best climate, for advancement and success. And increasingly at odds with current trends toward Web-based applications and service delivery, and the shift to mobile.
Continuous Beta
You may have heard of “agile development” – a sort of fast-track method of producing software and network code that was proposed in the so-called “Agile Manifesto” of February 2001.
Speed element aside, much of the focus of agile has been on customer-centered activities. Its emphasis shifts to determining what users really want, how easily they can use software and site features, the overall user experience and how rapidly changes to existing elements could be made.
Google set the ball rolling with GMail, whose continuous stream of updates has kept the email application in a state of “continuous beta
.” It established the protocol for Web-delivered applications, which can be continuously tweaked and improved by downloading modifications through the user’s Web browser. The same approach applies to modifying websites.
New versions can be rolled out on a daily or even hourly basis, amending and improving features one at a time. Anything that doesn’t work can be rolled back, to a previous iteration. It’s a methodology that sits in stark contrast to the historical approach of upgrading software on an annual basis, with a major release that might not address current and recurring problems.
Changing Mindsets
The shift toward the Web and mobile applications has put pressure on developers to abandon the old ways of writing up specifications for new and ongoing projects: months of data-gathering and research, testing and retesting, then implementations that can also take months. Do that in the current climate, and you’ll soon go out of business.
Websites and applications now are in a constant state of flux – and the development process has to reflect this. To update and tweak on a daily or hourly schedule, your infrastructure has to be synonymous with your code – and you need automation, to keep up.
The need for automation extends to network administration as well; software is required to help manage all that infrastructure. At present, network operating systems aren’t geared up too well, for automation. But there’s a move toward software-defined networking, which will add “infrastructure as code” into the repertoire of network hardware.
A Cultural Shift
Organizations that have embraced DevOps tend to produce cloud-based software, and use automation tools like Chef or Puppet. But beyond the tech, DevOps is a philosophical approach – one that can extend beyond developers and operations teams.
The enterprise as a whole can benefit. Mutual respect and co-operation between departments need not be limited the IT division. Sales, Human Resources, Finance, and Management can get in on the act. What’s required is some change in attitudes, and a bit of empathy.
Empathy? What’s That?
The ability to step into another person’s shoes. To see things from their point of view – to acknowledge and appreciate their motivations, needs, and limitations.
Sounds woolly – but it’s an integral part of the DevOps process.
Breaking Boundaries
The best DevOps practitioners are willing to learn new skills – in the DevOps ideal, from their colleagues in other departments. This is a multi-disciplinary mindset, shared by people who can be as comfortable writing code and testing new features as when they’re configuring network infrastructure.
There aren’t too many of these people around, right now. So the imperative of the DevOps movement is to identify those who are currently out there, and to recruit and train new talent, grounded in this approach.
Best Questions – Not Practices
It’s very much a work-in-progress, so a best practices guide isn’t really available. The guideline takes more of a questioning angle:
• What can we do, to really satisfy our customers?
• How can we determine what our customers and users really want?
• What do our developers require, to create software and systems that can be easily managed?
• What do our operations people need, to run our websites and systems most effectively?
• How can we promote effective and productive interaction, between the various divisions in our enterprise?
• What are the problems that need to be addressed, within our organization?
And so on.
Some Resources
Patrick Debois, The Build Doctor, RI, Planet Infra, Bitfield, Unix Daemon, and Agile Sysadmin blog on and about the DevOps movement.
The Agile System Administration group on Google is a low-volume mailing list that includes most of the DevOps founding members. They can also be found on Twitter.
William Thompson
William Thompson is the Marketing Manager at Power Admin, a server monitoring software business in the Kansas City area. You can find him on Google+ and Twitter. William has been a professional in website design, digital marketing and 3D/graphic design for over 20 years.