What do customers have to do with DevOps? If you think in conventional terms, your answer is likely to be "not much."
As the very term "DevOps" — a portmanteau of "developer" and "IT Ops" — implies, DevOps was conceived as a way to improve the work of IT personnel by helping different teams to collaborate better. It was not primarily designed to help customers. To the extent that the customer enters into the DevOps equation at all, the customer's role has traditionally been to provide some feedback and complain when an application breaks.
Forward-thinking DevOps teams shouldn't settle for this simplistic treatment of customers. In order to stand out from the crowd in an age when almost everyone is doing DevOps, organizations must perceive the customer as more than a source of feedback. They must instead make the customer experience the focus of every stage of the software delivery pipeline.
As this blog explains, adopting a customer-centric approach to DevOps is the only way to ensure that the activities of IT staff constantly contribute to the creation of business value — which rests ultimately on their ability to satisfy customers. Below, we'll take a look at two examples of common DevOps practices, and how they can be transformed to place the customer first.
For a more detailed explanation of why the customer needs to be at the center of DevOps processes, and tips on achieving a customer-centric delivery chain, we invite you to download CA's free eBook, "Taking DevOps to the Next Level: Putting the Customer First."
To illustrate what customer-centric DevOps looks like in practice, let's take the example of container monitoring. In a world where 24 billion containers have now been downloaded, container monitoring has become a routine part of the job descriptions of many SREs and DevOps engineers.
If you take a traditional approach to DevOps, you approach container monitoring in the same way that you monitor other types of infrastructure. You set up tools that let you know when a container has failed so that you can create a new instance. You track changes in network traffic in an effort to identify irregularities that could signal performance problems. You scan images in your container registry to check for known security vulnerabilities.
This type of container monitoring strategy might help you to maintain a stable container environment. But it does not necessarily translate into an excellent customer experience. Why? Because when it comes to containers, the types of activity and metrics that would be irregular in another type of environment might not actually be cause for concern.
Part of the purpose of containers is to provide a deployment environment for highly scalable, rapidly changing applications. In such an environment, rapid fluctuations in network traffic may reflect normal operations. Similarly, failed containers are not necessarily indicative of a problem, as long as sufficient instances of the container continue to exist to keep the application available. And while container image scanning is one way to help improve container security, it is by no means the only type of security operation that you need in a containerized environment. Runtime security is essential, too.
For these reasons and more, a conventional approach to monitoring will not guarantee an excellent customer experience when applied to a containerized environment. Admins who attempt such a strategy will find themselves distracted or confused by misleading metrics, and they will waste time responding to issues that don't actually impact the user experience.
A customer-centric approach to container monitoring is rooted in a monitoring strategy that can address the highly dynamic nature of containerized environments. It involves setting dynamic baselines, rather than inferring information based on static measures of "normal" activity. It requires the ability to determine when a failed container is actually a problem, and when it can be safely ignored. It entails being able to roll back container image updates quickly in the event of a failure, before customers are impacted.
The bottom line: Customer-centric container monitoring requires thinking beyond traditional DevOps monitoring principles. Containers are fundamentally different from legacy infrastructure technologies, and the monitoring strategies for containers that add up to an excellent customer experience are different, too.
Application Performance Management
As another example of the ways in which customer-centric DevOps differs from traditional DevOps, consider application performance management, or APM.
Traditionally, the main focus of APM was to identify availability or performance problems within an application or the infrastructure that hosts it. A non-responsive server, a web application that is taking longer than expected to respond to requests, or an application service that has become intermittently available are examples of the types of issues that APM tools help to identify.
While problems like these are indeed important for DevOps teams to know about, a realistic DevOps operation that focuses on satisfying the customer above all else requires a more nuanced approach to APM. In today's complex software environments, it's a sure bet that something will always be broken, or will fail to perform optimally. It's unrealistic for DevOps engineers to respond to every problem in real time.
That is why they must adopt an APM strategy that is designed first and foremost to guarantee a positive customer experience. Maintaining excellent application availability does not necessarily translate into an excellent customer experience. Services that are "up" may still perform sub optimally.
In addition, a fixation with maximizing uptime can distract engineers from other priorities that have a more significant impact on customer satisfaction. For example, deploying applications to a broader set of geographic regions in order to increase response time for users in those regions may be a more useful activity than attempting to maximize the uptime for services that are hosted in a less comprehensive group of regions.
In short, a customer-centric DevOps strategy focuses on APM practices that maximize the overall quality of the user experience, rather than fixating on uptime or other metrics that do not directly correlate with user satisfaction.
Conclusion and Further Reading
Traditionally, DevOps has prioritized technical goals and metrics. Engineers have strived to maximize software delivery speed and application uptime.
These are worthy goals, but only if they help to advance the most important mission of all, which is maximizing customer satisfaction. DevOps teams that lose themselves in a forest of technical priorities are at risk of undercutting their ability to drive value for the business by pleasing customers.
To learn more about what customer-centric DevOps entails, and for a broader discussion of the role played by processes like monitoring within customer-first DevOps, we invite you again to download our free whitepaper, "Taking DevOps to the Next Level: Putting the Customer First."