In part one of this article, we discussed the history leading up to the Agile movement and its implications for software development. This new way of doing things – in short sprints and in constant dialogue with the business stakeholders – was a watershed moment. But technology continued to move forward and the innovations of the 2000s and 2010s created new architectural models that posed new and serious challenges to how software development was done. Operations began to play a larger role in the software development process; from building out servers to managing QA environments to the installation and support of the applications developers were writing, operations was now a key player in the development process. Software development methodologies needed to adapt to this new reality.
A Missed Connection and a Revolutionary Presentation
In 2008, what was to become the DevOps movement started in the most unlikely way. Andrew Shafer, a software developer, tried to start a “birds of a feather” session at a tech conference in Toronto called “Agile Infrastructure.” Sadly, only one person agreed to attend the session – even Shafer himself was a no show! The one person who did show up was system administrator, Patrick Debois, who took it upon himself to track down Shafer and started a discussion that eventually resulted in the formation of the Agile System Administration Google Group. More people flocked to this group and a larger discussion around bridging the gap between development and operations began.
A year later, John Allspaw and Paul Hammond gave a presentation at the Velocity 2009 conference, entitled 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, which revolutionized the industry. The very idea of deploying to production even weekly, let alone multiple times a day, seemed to many to be a distant dream, or a guaranteed nightmare. Most enterprises went months and sometimes years between production upgrades. This was seen as the best way to ensure a stable, working application. Allspaw and Hammond made the argument that the opposite was true. Encouraging rapid deploys to production would have the effect of limiting the amount of change connected to a production outage, while maximizing the commitment to quality. If developers know that the code they are writing was likely to make it into production in less than a day, it would help reduce the “throw it over the wall” mentality that is frequently the result of long development and testing cycles.
Now things really began to move. Building on the success of the Google Group, Debois held the first DevOps Days event in Ghent, Belgium. It would grow into a global phenomenon, with 22 events being held in 11 countries in 2015 alone. The release of Jez Humble and Dave Farley’s book Continuous Delivery in 2010 marked another major milestone. The book took the ideas promoted by Allspaw and Hammond and codified them into a working model that could be adopted by organizations large and small.
At this point, the DevOps movement had begun to reach critical mass. Technology people both in development and operations were beginning to embrace the idea of greater cooperation and commitment to quality. But what exactly did that mean? What exactly does the DevOps movement stand for? There’s still a lot of debate about that but we’ll lay out a few of the ideas that are common themes within the DevOps community.
A Culture of Cooperation – Eliminating Silos
Probably the central theme of the DevOps movement is the elimination of silos within IT organizations. This isn’t so much a removal of departments or roles within the organization as much as it is a changing of the focus from a “throw it over the wall” employee mentality to a strategic, goal-oriented one. Because of the disconnected nature of development, QA and operations are sadly still a leftover artifact from the waterfall days. It is essential that IT organizations orient themselves around delivering solutions that will improve the bottom line rather than focus on their specific world. Matthias Marshal says:
“On a cultural level, DevOps means that everyone has to own the overall business goals. It’s of no use to say, ‘well, my part works, but they can’t get it running’. Instead, everyone has to do his best to realize business value.”
Build in Consistency – Infrastructure as Code
While creating a collaborative environment focused on the bottom line is the central theme, most DevOps proponents advocate for tooling that will enhance this collaboration. One example of this are applications – like Chef, Puppet, or others – that implement a pattern known as “Infrastructure as Code.” These tools, when properly implemented, remove the need for administrators manually logging into servers and changing configurations by storing server configurations in programmatic but human readable files in source code.
This accomplishes two important things; first it eliminates the “configuration drift” that can result from a single individual changing one server and possibly forgetting about others that perform the same function. Secondly, it enhances collaboration by giving everyone involved in the application delivery process the ability to modify server configurations, while giving visibility into exactly what those changes were. Most of these tools even include testing suites to allow you to test your configuration before you implement it in any of your environments.
Build in Quality – The Continuous Delivery Pipeline
Lastly, DevOps advocate for the creation of a continuous delivery pipeline where everything that goes into implementing an application gets put through a battery of tests before deployment to production infrastructure. This is more than just running a build server and making sure things compile. It’s a gated, metric-driven, quality controlled approach that validates everything – infrastructure and application code – before applying critical changes to production.
It’s all about Collaboration
At its heart, DevOps is about collaboration. It achieves a similar outcome for development and operations as the Agile movement achieved for development and business stakeholders – a commitment to collaboration, with a focus on business priorities. However, this is not an easy task. It involves breaking down walls that have existed for decades for many people.
The good news is Maven Wave can help you in this process. We are a firm made up of strategic thinkers who seek to do more than just implement a technological solution. We will advise you on management practices that will help you and your employees embrace the vision you have set for your organization and allow your technology teams to move beyond the silos and into true collaboration.