Ten years ago, software developer Andrew Clay Shafer scheduled a “birds of a feather” session titled “Agile Infrastructure” at the Agile Conference in Toronto. After further thought, though, Shafer figured no one cared about the topic and he blew off his own session.
Another developer, Patrick Debois, did show up in the empty room, however. He was presenting a paper called “Agile Infrastructure and Operations” during the conference and Shafer’s session had caught his attention. The two later met up in a hallway and had a long talk. Three months later, they formed the Agile Systems Administration Group, whose goal was to foster greater collaboration between developers and systems administrators.
These events a decade ago are widely considered the “little bang” that gave birth to DevOps, the much-hyped movement that strives to unify development and operations through increased collaboration and automation in order to build, test and release software faster.
DevOps awareness and adoption clearly are on the rise. Nearly two-thirds of organizations were using DevOps to one degree or another by the end of last year, according to Gartner. Forrester labeled 2017 “the year of DevOps” and said its “questions and discussions with clients have shifted from ‘What is DevOps?’ to ‘How do I implement at scale?’ ”.
As more businesses that have been piloting DevOps in smaller teams and projects in contained environments expand these agile practices across the organisation, it’s a good time to ask what DevOps success looks, feels and smells like.
What are the telltale signs that DevOps has not only taken root in an organisation but has grown into a smooth machine powering a faster, better software development lifecycle?
I’d suggest that a company which has embedded the following four truths into its daily existence can say it is fulfilling DevOps’ promise. Here they are — the DevOps grand slam, if you will.
- It’s the velocity, stupid.
Just as the 1992 Bill Clinton campaign simplified its winning formula with the phrase “it’s the economy, stupid,” DevOps is about one thing: shortening the software development lifecycle. If you measure the time it takes for a feature to be programmed, developed and deployed into production and that time is decreasing, you know your DevOps objectives are being met.
But how do you get there? This is where things often get complicated.
It’s important to remember DevOps’ true origins – a desire by developers to sidestep perceived obstacles on the operations side of the house in moving code into production faster.
Popular tools like Jenkins and Kubernetes were created by developers for developers to meet the excellent objective of faster release cycles, and they often work well in smaller teams executing one-off projects.
But these tools are not consistently battle-tested and production-ready. If a company is trying to manage DevOps at a larger scale the cookie-cutter templates with, say, Chef and Puppet aren’t going to cut it.
To make sure their DevOps strategy can successfully scale, companies need a smart tools approach. Which leads to #2…
- DevOps doesn’t mean Dev and Ops must use the same tools.
While a telltale sign for a good working DevOps environment is a healthy collaboration between developers and operations, it’s a myth that each must use the same tools to achieve their mutual goal of delivering high-quality new services faster.
DevOps should not be the combining of developer and operations responsibilities, but rather a complementary relationship of equals. Operations should not be told to use tools that weren’t built for them. Operations should be able to use tools that were built for operations.
A healthy, mature DevOps culture doesn’t force tools made for developers down the operations staff’s throats and recognises that operations should be able to use the technology they feel is best for assuring the deployment of resilient, secure applications.
- It’s not just DevOps, it’s DevSecOps.
More and more organisations are adopting the next level of DevOps – DevSecOps, which requires development, operations and security teams to work collaboratively throughout the application lifecycle to detect security vulnerabilities.
This “everybody is responsible for security” approach differs from traditional models where the security team gets involved only after code is nearly final and “hardens” it in a process that can take weeks or even months to complete.
If a company is moving to the DevSecOps model, chances are it successfully mastered DevOps principles first and is applying lessons learned.
- Orchestration is crucial.
The DevOps world is strewn with moving parts – the aforementioned tools and others like Mesos… PaaS… Docker container managers… and on and on. This hodgepodge is difficult to wrangle into a coherent, consolidated workflow.
So if you’re not running scalable, automated orchestration (which is the responsibility of the operations team, by the way), you’re not properly prepared to run container clusters, and that means you’re not really doing DevOps right.
Organizations that want to succeed with DevOps must understand that orchestration tools have become essential as part of the DevOps process.
As DevOps enters its second decade and adoption continues to grow, it’s important that organisations know what success looks like.
Written by Scott Willson, Product Marketing Director for Continuous at CA Technologies
