Is DevOps the best approach to software development?

Cyclic DevOps model 

However, effort is being wasted when a “one-off” experiment needs to be scrapped and started afresh in order to evolve or scale a prototype. Rather than throw away this work, a cyclic DevOps model builds on an agile approach to software development, and combines it with operational deployment. The aim is to build a closed-loop lifecycle: plan, build/code, integration and test, release, deployment, operation, monitoring and feedback. 

Unlike previous stepwise approaches, DevOps elements run continuously within the lifecycle through continuous integration, continuous delivery and continuous deployment. As such, there needs to be a different approach to tooling, which is why Chef, Docker and Puppet have become established DevOps names. 

However, the many challenges and aspects to DevOps means that a portfolio of tools is required to support the changes in people and processes. 

Different views of DevOps 

DevOps tends to polarise viewpoints. It is either viewed over-cautiously as a dangerously chaotic approach that introduces risk, or over-zealously as the holy grail that transforms both software development and the business. For most, neither accurately reflect reality. DevOps does, however, significantly affect people and processes, as well as technology. 

It is understandable to want to claim the advantages of transforming software development, but there are a number of well-recognised challenges that often occur during DevOps adoption. 

The first is commitment. Without serious executive sponsorship or senior management buy-in, the model breaks down. The entire development and operations team has to believe that it has been empowered by DevOps. 

Everyone has their own opinion of what DevOps is and this varies within and between organisations. DevOps teams will often be working alongside traditional teams and third parties.  

Fully open, transparent and complete communications are vital for building a common understanding. But inertia or resistance to change is common in most organisations.  

There might be a fear (justified) of failure or other barriers or compensation models that prevent or dissuade even those individuals who would embrace change from doing so. The organisation itself might be structured and funded in a way that means it is slow to change. This is the biggest challenge facing those wanting to take advantage of a fully agile DevOps approach. 

Management commitment 

Beyond the individual DevOps teams, there has to be sufficient management commitment to drive the process, change the culture and ensure everyone understands the message. To build on that, there are internal and external operational “relationship” and procedural challenges to address. These are crucial areas for making decisions on investment in tools and technology. 

One area of friction is maturity mismatch between roles. Those who have already adopted agile processes and methods will be further along than other team members. Those involved in operations, test and quality assurance may be less familiar and less confident with what seems like a rapid and less structured approach, and they need to be offered more support.  

Tools from companies such as PulseSecure and Arxan help keep the focus on security. Given the levels of automation required to gain maximum advantage, operations and test engineers may also need to learn or re-energise coding skills. 

It is also necessary to integrate with traditional software development, as most organisations do not have the luxury of starting from scratch with a greenfield set of requirements, people and resources. DevOps demands significant changes in how people work together. They need tools to foster and support multi-cloud-based development. As well as strong push from the major cloud suppliers – Amazon, Google and particularly Microsoft with Azure – others, such as Atmosera and Morpheus, offer ways to effectively deploy DevOps in a controlled manner. 

Given that few organisations have all the skills and resources required in-house, external providers are sometimes needed. However, the tightly coupled, fast-paced and experimental style of DevOps is not well aligned to the traditional outsourcing cost models. External relationships will need new foundations. 

The significant benefits from the “continuous” aspects of DevOps depend on process optimisation and automation. Tools that support the continuous cycle to fit IT more closely to business needs, such as those from Electric Cloud and Plutora, can be transformative in speeding up the software delivery process. 

While the initial DevOps focus needs to be on people and processes, there are some challenges affecting technology adoption. These can be more pronounced in larger or well-established organisations, but will affect any firm adopting a DevOps strategy. 

As with any emerging trend, there is a sudden rush from many quarters to join the bandwagon and offer “the solution”. Many suppliers have positioned their products or services as “buy this and you will have DevOps”. A better bet is to find suppliers with a track record of improving developer effectiveness – not only speed, but also quality. 

As regards DevOps tool choices, there is little benefit in being stuck with a proprietary solution. Many innovations prevalent in DevOps tooling come from grassroots advances and open source, with companies such as CloudBees adding enterprise support for Jenkins, Docker containerisation software coming in both open source and paid enterprise variants, and HashiCorp building automation tools on its own open source tools. 

However, allowing too much developer choice and freedom causes other challenges, not least of which is long-term maintenance and viability. There are also challenges when working with third parties and despite the value from the range and variety of tools available, it is necessary to create standards and frameworks for good governance. 

Organisations are fairly used to restructuring business processes and are very familiar with moving in different technology directions, but cultural change, while often discussed, is difficult to accomplish. Despite this, in DevOps, there are a number of frequently recurring themes: 

•  Why DevOps? First, determine what the DevOps strategy is being put in place to achieve. Is the aim to speed development, improve quality or get closer to customer needs and expectations? The over-arching goal will drive behaviour. 

• Senior executive buy-in. Get commitment to empower the team with support from the top. DevOps allows for experimentation and with this comes failure without retribution. Get an active stakeholder and ensure that the team know the goal, and that they have the full support and backing of senior management. 
• Start small. Go for a real identifiable business need and start with a self-contained, product-isable project that will have visible customer impact. 
• Build a coalition of the willing. Start with the most enthusiastic and DevOps-aligned team, but don’t make the mistake of positioning this as the “star” or special team. It must work alongside everyone else. 
• Over-communicate. DevOps culture does not need to pervade the entire organisation, but awareness of it does. Communicate regularly, widely and clearly. 
• The place for pace. Put all the team in one location. Create some “buzz”. Closer collaboration should be aimed at improving the quality, relevance and immediacy of communication, not its volume. 

• Get quick wins and share. “Never overlook a good crisis.” Fix a problem, but don’t pick the hardest, biggest and most influential project, because failure will give any doubters an excuse to stop. Momentum is key. Go for quick wins and promote successes widely – not to gloat, but to replicate. 
• Build a centre of excellence. Lay the foundations that will enable DevOps to spread. Use the team as a focus for learning and sharing with other development teams. Rotate people through so that everyone can understand and learn, but start with a small team. 
• Standardise. Define common services and tools. Build a governance framework for DevOps to fit alongside slower-paced or traditional development projects. Define standard rules of engagement for third parties. 
• Remove obstacles. Share out responsibility for quality – and security – across the team. Design quality in throughout the whole process, rather than relying on quality assurance to test everything out at the end. There still need to be individuals occupying these key roles, but acting as areas of authority,  
  not gatekeepers.