Why DevOps?

What is DevOps?

There are many definitions of DevOps. For some it’s a movement whilst for others it’s a natural shift to how applications are and will be delivered. In my professional capacity, I have heard many explanations ranging from it being a new process right through to it being a new way of thinking. In this post, I will provide a bit of background and what I’m hearing when speaking to my customers and why I feel a DevOps model could be relevant.

According to Wikipedia DevOpps was a term first coined by Patrick Debois in 2009 – he argued that DevOpps is a combination of software development and operations. It is an evolution of both Lean and Agile principles to deliver ‘continuous delivery’. These principles are important because without them DevOps would not exist. Lean and agile principles allowed developers to make immediate changes to a workflow before moving it onto production. Whilst this model made sense there was still a gap between deployment and development. This would result in bottlenecks as there is a disconnect between delivery and development. If a problem was discovered near the end of deployment the whole development cycle would need to start again. It was through this disconnect that Debois came up with the notion of DevOps. “The marriage of development and operations along with the extended best practices and principles associated with Agile had the potential to greatly increase efficiency and lower delivery risks”.

Why is DevOps relevant?

DevOpps is relevant because unlike Lean and Agile methodologies, DevOps seeks to implement actual organizational cultural change. What this means is two often separate parts of the business now working together as one to deliver one outcome, and with several business benefits:

-         Departments are well placed to reduce their time to market.

-         Customer satisfaction is improved as the organisation can continuously improve quality and respond to customer needs more quickly.

-         There will be a significant reduction in application errors as problems and opportunities are spotted rapidly and earlier in the development process.

I have worked with customers where operations and development are kept very separate. This traditional approach does have its benefits but in this instance we are seeing a slowdown in service delivery as different aspects of IT seem to be working against each other rather than for each other. As we move into this ‘digital data driven’ era it is important for these two functions to be unison so that business outcomes can be delivered quickly and departments can operate more efficiently.  

How do I know if my business needs DevOps?

The DevOps approach is not right for every business, and by that, I mean that each business may have its own way of operating and going to market. To make DevOps work and to know if your business is a good fit there are several software principles that must characterize your business. A well-known online news broadcaster and a client of mine would be a great example. Their business is reliant on frequent and rapid release cycles. That means they cannot afford any hold-up once an application is ready to be deployed. For this organisation, deployment to production is fully automated with automatic roll backs built in. In their application process, they have built-in continuous integration with automated testing at every process. This for them means faster delivery as if something fails the relevant team is automatically notified and a plan is in process. This is because developers, testers and operations are all working in unison. The reason why I feel DevOps works for this company is because management have empowered the team with the authority to make the changes it needs to make. They have broken down traditional barriers such as labelled teams and structured IT so they work in small teams who all collaborate together. This for them means fixing problems quickly, spotting opportunities sooner and ultimately going to market in hours/days rather than week/months. If your business is reliant on quick releases, continuous integration and automated processes than a DevOps structure is right for you.

What’s needed to make DevOpps work?

Communication, Integration and Collaboration are key traits needed to make DevOpps work. Now this in theory sounds great but what does it really mean? The simplest way to describe this process is a reorganisation of departments. It means departments that were once siloed open their doors and start collaborating with each other. By collaboration I mean sharing ideas, sharing code and most of all continually sharing feedback. A good example of this in practice would be Amazon. Historically, Amazon had run on dedicated servers. Their biggest challenge was to predict how much equipment to buy to meet traffic demands and estimate unforeseen traffic spikes. Consequently, 40 percent of Amazon's server capacity was wasted. Alarmingly, during the Christmas shopping season, when traffic could triple, more than three-quarters could be left unused—along with the money spent to purchase it. Once the online retailer moved to the Amazon Web Services (AWS) cloud, it allowed engineers to scale capacity up or down incrementally. Not only did this reduce spending on server capacity, but it also spurred a transition to a continuous deployment process that allows any developer to deploy their own code to whichever servers they need, whenever they want. Within a year of Amazon's move to AWS, engineers were deploying code every 11.7 seconds, on average. This agile approach reduced both the number and duration of outages, resulting in increased revenue. By operations and development both working collaboratively Amazon was able to detect errors quickly, accelerate development and drastically reduce the time to market. I appreciate this is a cloud based model that Amazon adopted and in a traditional on premise approach you have teams of network architects, developers, infrastructure engineers etc and moving to a DevOps model may not be easy but I think what can be learned from the Amazon example is by encouraging an attitude of collaboration and having teams work together systems and projects can be delivered quicker. Once this initial barrier of separation is broken down the building blocks will be in place to move towards a more agile DevOpps model.  

I hope this blog acts as a good intro to DevOps. I am not claiming to be an expert but just sharing my experiences from what I am witnessing when speaking to different customers. The company I work for coauthor The State of DevOps report and have a number of products that enable Devs and Opps to work together. Feel free to check them out!