The impact of DevOps has grown over time, particularly within today’s competitive and face-paced IT environment. The abundance of programming languages, tools and software services has created near-unlimited options for developers to build and create innovative applications. But to remain agile, the creator is also the implementor. The line between developer roles has become blurry and it is no longer sufficient to be an expert in one particular area. From the small startup to the large enterprise, teams are embracing DevOps culture to push their applications forward and respond to changes quickly. This slideshow, from Chris Kelly, developer/evangelist at New Relic, will discuss five characteristics of a successful DevOps culture.
Click through for five characteristics of a successful DevOps culture, as identified by Chris Kelly, developer/evangelist at New Relic.
When hiring, look for individuals that know how to build the tools that remove pain points rather than individuals that are experts in a particular software or technology. Companies and products shift over time, and we want people that can ease the friction from those shifts. We need generalists that take the best from multiple disparate areas to create novel value. We need our operations staff to think like a software developer. As DevOps methodologies mature, our infrastructure will begin to look more and more like software.
We want to take the concern out of releasing a new feature and putting code in front of our users. Instead of extensive specifications and endless QA cycles, we want developers to push code that is automatically tested. Code is tested while it is being developed, giving developers immediate and actionable feedback, keeping them focused on the code at hand. Code that is continuously tested should be less error prone, and easier to release. DevOps is about empowering a team to get their code out to a user quickly. Continuous integration removes the hurdle of traditional QA cycles.
In order to maintain confidence in a rapid release cycle, you need to be monitoring your application first. And to truly understand your application, you need to view it through multiple metrics. Monitoring CPU, memory and I/O usage is traditional. We also want to monitor page render times, database calls, and network latency. But none of those are the most important metric. We must be monitoring our application at the business level. How many sign-ups were processed? How many shopping carts were abandoned? How many login attempts failed?
These metrics give us significant insight into how the code changes affected the application’s performance. By monitoring at these levels, we can easily detect regressions and get fixes out to production quickly. We want to focus on our mean time to response (MTTR) and not our mean time between failures (MTRF). So we need the tools to both fail fast and recover fast, and monitoring is critical to both.
At this point, we should have confidence in our code through continuous integration, and confidence in our ability to respond through continuous monitoring. The final hurdle we want to overcome is getting new code into production as quickly as possible, and that is achieved through continuous deployment. Teams with a DevOps culture will empower the creator to also be the implementor. Full responsibility for that code release lies with the developer that created it. This creates a culture of responsibility and high standards. We’ll learn more from our real users than any other source, and getting our code in front of them should be the highest priority. Implementing a continuous delivery pipeline in your application is key to seeing improvements, releasing features and responding to failures.
Nothing can damage your focus more than having to respond to an emergency or application outage. We need to build apps that are able to withstand the inevitable failures of a complex system. Our applications should degrade gracefully. They should be built such that one component cannot catastrophically impede the functioning of the application overall. Having a resilient application allows us to respond to failure with cooler heads and thoughtful decision-making. Knowing that our continuous delivery pipeline is in place allows us to focus on solving the problem and bringing our application back to full functionality without unnecessary hurdles.