Making the case for DevOps
Dan makes the case for DevOps and how to implement it as part of a long-term strategy.
Is it a culture? A job title? A piece of software? The next step in agile development? A vital step in our desire to speed up the delivery process? Or an entirely new philosophy? These are just some of the questions still being bandied around when it comes to describing DevOps. While there may not be a hard and fast definition yet (and may never be), businesses by and large seem willing to get on board, with DevOps delivering a clear benefit – improved collaboration between developers and IT to enable faster and more accurate delivery of code. The optimism around DevOps is clear in the uptake, with a recent report from Right Scale showing that adoption rose from 66 to 74 percent in 2015.
It all seems rosy, or at least in theory. In reality, businesses still face a series of hurdles when it comes to implementing a DevOps strategy. The interest is there but organisations currently seem to tail off somewhere in between enthusiastic and fed up. So how can we make sure we get on the right side of the numbers?
Who’s responsible for the ‘culture’?
Before the current evolution of DevOps, IT and development would often have no direct connection, with infrequent communication between the two functions.
For DevOps to work, this culture has to change, with some initial work upfront – particularly when considering a recent report from Gartner that gave any DevOps initiative a 90% chance of failure unless both development and operations are willing to collaborate.
But identifying who’s going to get things off the ground can be a problem. Is it business leaders, the IT team or your developers? Because DevOps is still fairly new, it can be difficult to bring these groups together and get someone to take charge – particularly for larger companies. A more effective method is to start with one department and roll out from there.
Organisations must communicate that DevOps is a long-term process; a learning curve where we look at different processes to find the right fit. According to the 2015 Puppet Labs State of DevOps Report, the longer an organisation uses DevOps methods, the better their IT departments perform.
Part Dev, part Ops — bringing the two functions together
As well as embarking on a cultural shift, there are some more practical changes that operations and development teams need to put in place in order to get things up and running.
Application Performance Modern developers use application performance monitoring (APM) tools to decrease latency, gaining complete access to code, databases, caches, queues and third-party services. But to successfully monitor applications, organisations need to make sure they’re up and running in the first place. This is where the operations team comes in, ensuring that all uptimes and service level agreements (SLAs) are in order. Traditionally, operations would rely on infrastructure metrics – CPU, memory, network, disk I/O and so on. Now, modern operations correlate all of those with application metrics to solve problems up to ten times faster.
Analytics A great developer recognises the importance of analytics in gathering feedback and understanding the end user. Strong development teams will constantly monitor end user latency and check performance across different devices and browsers. These performance analytics are important for the operations team too. Putting in automatically generated baselines across all metrics helps operations teams to understand what’s changed and where to focus their troubleshooting efforts. Putting alerts in place that pop up if and when you deviate from these observed baselines improves alert quality and reduces alert noise.
Code Developers need to ensure that deployments and new releases don’t implode or degrade the overall performance. This is where communication is vital. Communicating with the operations teams enables developers to flag any changes that are being made as well as possible glitches. Having this knowledge allows the operations to know about and fix problems before the end user complains, reducing the number of support tickets and eliminating false alerts.
Benefits Whatever your role – be it developer, implementer or business leader – different groups are interested in DevOps for different reasons. As we see it evolve, we’re experiencing greater cohesion between these groups as they merge together.
Faster, more frequent deployments means you no longer have to choose between speed and accuracy. Crucially, development, staging and production environments are all identical because the infrastructure has been written as code. An increased number of smaller deployments also means that if there are any problems with the code, it’s a much easier job to fix. Because of this you can be confident that code release tested in staging can be pushed to your production environment and just work.
Your deployments will be faster and up to 30 times more frequent too. This is because pushing the button to go live is no longer a big deal that’s fraught with worry. All this leads to a significant speed advantage over your competitors, with teams working more effectively to achieve a common set of benefits.
From legacy systems to working in silos to environmental restrictions, companies still face a few speed bumps. But collaboration and communication are becoming more commonplace, giving technical teams the tools they need to speed things up and work more effectively. Businesses still have a way to go when it comes to working on our culture but we’re definitely getting there.
