DevOps disillusionment: Nobody said it was easy

The hype over continuous delivery needs to be balanced by realism

The following is a contributed article by Justin Vaughan-Brown, director of technical strategy at performance monitoring company AppDynamics

At a time when businesses are adopting continuous delivery to improve customer experience, many are looking to instil DevOps principles across teams. With Accenture claiming that users can expect time-to-market improvements of up to 50 per cent and a dedicated fan base ready to shout about its benefits, its success seems inevitable. Recent deployments by large scale enterprises such as British Gas and Lloyds Bank indicate that DevOps is likely to be mainstream within the next few years, and most are keen to follow suit.

That said, some signs suggest this enthusiasm is waning. At Gartner conferences between 2015/2016, 87 per cent of attendees surveyed said DevOps had not delivered on expectations, and the most recent Hype Cycle showed it edging towards the trough of disillusionment. For technology teams looking to adopt a DevOps approach, it is understandable how these stats might be confusing when compared to the enthusiasm touted by so many businesses. The myriad webinars, MeetUps and conferences that shower it with praise could be setting up inflated expectations, without emphasising the level of change that is required to make it a success. This could encourage businesses to approach DevOps adoption without fully realising the level of effort involved.

In its early stages, DevOps can consist of a merged development and operations team sat separately from the rest of the business. This may result in modest improvements, but will not deliver the results that many expect. The creation of a new team ultimately means a new divide is born and it cannot be a long-term solution. Rather than seeing DevOps as a simple process of placing these two teams together in another silo, it should be considered an ongoing process that sees a radical change in culture, involving development, operations and the wider business. It is only then that its full effect will be felt.


Getting the team on board

To start, this means employees must be clear on their new roles and required behaviours. Development and operations may be sat together, but if their working style does not change, this will have little impact on deployment times. Where previously, developers could focus almost solely on writing code, more time must now be dedicated to testing, deploying and understanding the impact on the rest of the team. Operations must also learn skills that allow them to play a bigger role in the development process, including new languages, tools and architectures such as containers and microservices. Teams must be aware that training and restructuring will take some time, but remain aware of the wider vision and benefits in the long term.

To instil these values within staff, it is useful to establish a specific DevOps evangelist. By having a go-to person to oversee the process, employees have a central point of contact for any concerns, while having a common goal to work towards. Without leadership, it can be easy for roles to become undefined and different interpretations to take hold. It may be the case that specific DevOps roles are created, emphasising the importance of skills that can be applied across the required tools, databases and other areas.


Why data is key

Leadership will not be possible unless effective metrics are put in place. Clear stats can allow teams to spot the root cause of problems instantly while removing a tendency to blame the other side. As sampling techniques pioneer W. Edwards Deming once commented, “Without data, you’re just another person with an opinion.”

This will foster a more efficient culture of collaboration. Some of the most important points to monitor include frequency of deployment, to assess the rate that new code is released, mean time to resolution, to ensure issues are being fixed quickly, and the amount of time taken from development to production. In addition to speed, metrics on application performance and a record of the number of failed deployments give an essential overview of the quality of the code being released. Along with operational benefits, metrics will make sure that small improvements are being seen, reducing the chance of disappointment from those expecting results straight away.

When implementing these metrics, it is important to note that data centred around certain disciplines within the team will not facilitate a truly collaborative culture. Dashboards should be easy to understand by all members and link back to a common language. By relating all metrics to business results, this can help teams to work together more effectively, while making better decisions on what steps to take to drive the digital strategy forwards. Rather than just keeping the lights on, speed, quality and innovation should be the key end goals, and data will play a key role.


The long road to success

Any attempt to significantly change behaviours will of course be a long drawn out process. However, the critical importance of fast, high quality releases means businesses will come under more pressure to make the switch to DevOps. When embarking upon a rollout, businesses must be prepared for a long journey that is likely to hit obstacles along the way. This will not happen overnight, but companies that dedicate the time and effort to making DevOps work will certainly reap the benefits. When rolled out thoroughly, DevOps will not disappoint.



Also read:
DevOps is a CIO’s theory of evolution
Six ways DevOps is changing the IT role
The marriage of SecOps and DevOps