Why adopting DevOps doesn’t have to be an all or nothing decision for IT operations teams

Gavin Payne is a principal architect for Coeo, a SQL Server professional services company, and a Microsoft Certified Architect and Microsoft Certified Master. His role is to guide and lead organisations through data platform transformation and cloud adoption programmes.

The principles of DevOps mean it has many similarities with Agile development – value, approach, scope and scale – making its implementation straight and necessary forward for some and an impossible dream for others. However, every IT operations environment – not just those supporting Agile software development – can benefit from the guidance DevOps offers.

The era of Agile software development

Over the last five years, Agile software development has arrived and bought positive changes to how IT delivers new functionality and value as quickly as possible. The most visible change for operations teams has probably been the shift from large and infrequent deployments to small and regular releases. The intention being each release regularly provides small increments in solution business value and welcomes constant business feedback, hopefully making wasting large amounts of development effort on something the business doesn’t want a thing of the past.

The need for DevOps

Unlike waterfall based software development, Agile’s rapid development and iterative release cycles make new demands of IT infrastructures and their operations teams. Its need to re-write the rules about release management wasn’t because there’s no place for process and rigour but because the pace of change is too fast in the Agile world for how we often did it before. Instead, the barriers between Development and Operations teams didn’t just need to improve - they ended up merging – to form DevOps.

For me, DevOps in a sentence is an infrastructure focussed framework that supports the rapid deployment of software created with Agile software development methods. Other definitions certainly exist and almost certainly are more accurate – but you might find the uniqueness of mine gives a different perspective.

The remainder of this article considers what we can use some the principles of DevOps to improve release management in any IT environment – whether modern or traditional.

Developing and testing on production-style platforms

Traditional development lifecycles often meant developers rarely got access to infrastructures representative of the production environment. Think of a web application developer who writes code on their standalone desktop PC while the production environment has multiple load balanced web servers. At what point would their code first get tested in with a web balancer?

Is it unfair in the era of Software Defined networking, servers and storage services –– and when cloud services can be used on a pay-per-use basis –– for a developer to write code on a platform similar to the production environment even if it doesn’t have the same performance? By testing on production-style platforms as early as possible in the development lifecycle, infrastructure compatibility as well as code problems can be found as early as possible.

Automated deployments

In the cloud era, scripting is king and automation is even better. Although this particular principle integrates best with Agile development’s continuous deployment methods, wider lessons for any environment can still be learned.

Rather than using a portal to deploy and configure services, DevOps promotes the idea of creating scripts to do everything – and then wrapping those scripts around orchestration tools – such as Chef – to automate their use. We might think scripting changes is nothing new and making configuration and code changes using them certainly isn’t. What the all-virtual cloud era allows us to now do is create and deploy servers, storage and networking all from scripts.

Imagine in our previous section the developer wants their own clone of the production infrastructure – instead of self-building it they can now use scripting and automation to deliver an exact copy cloud component by cloud component.

Not only do scripts save time, they ensure repeatability. Similarly automation doesn’t just save time, it broadens the range of people who can use those scripts.

Monitoring solution quality early

Effective solution monitoring can offer the most value when it describes business as well as technical activity. Whether an organisation’s key performance indicators are cars per hour or text messages per day – having that data to hand when troubleshooting IT issues not only puts context to measurements, it helps determine whether utilisation spikes were down to poor code or more customers.

The challenge often comes in collecting that data – Windows performance monitor isn’t going to have a counter for books sold per hour or revenue per day but the IT systems themselves almost certainly will.

Collecting data early is also another DevOps principle. We can often be too focussed on the functionality of development systems to think about their non-functional capabilities, most specifically performance. While maybe not as thorough, non-production monitoring can give you baseline data for the day of go-live and help you find your infrastructure bottlenecks early.

Encouraging feedback

Finally, DevOps encourages regular feedback from every stakeholder as often as they have some to give to promote faster correction of issues and the delivery of greater business value.

A common definition of the term agile is about an ability to respond to change. Long release cycles in IT have previously meant sometimes it was too late to solve issues that didn’t risk missing the solution sponsor’s key drivers. DevOps encourages regular and quick feedback from everyone with any to give.

Feedback from IT operations teams needs to be welcomed during development not after go-live. It becomes even more valuable when development and testing is done earlier and earlier on production-style platforms. Early operational behaviours and insights can be formed and issues then solved earlier – providing every team is given a regular opportunity to share their feedback.

As a closing thought, very much like Agile software development merging the roles of Development and Operations to perform DevOps maybe a necessity for some and impossible for others. However even where it’s impossible, DevOps can provide refreshing new guidance to traditional IT operations environments.

If you are interested in DevOps then join us for Day 2 of TechDays Online 2015, particularly at 15:10 - 15:45 (GMT) in which Tarun Arora (MVA) will be talking about DevOps in Microsoft Azure with Chef and Puppet for heterogeneous cloud environments.