Applications run at peak use more often than we would like causing significant problems. In fact, 83% of IT practitioners state that they have thousands of containers running at peak use. Monitoring applications in transient containers is a nightmare. The risk of incurring €100 million in costs due to cyber attacks such as the recent attack on the health services in Ireland could be avoided if systems were patched and tracked at all times.
The question is where do we get reliable data on our systems and how relevant is it? DevOps provides an answer by applying observability techniques and through continuous review for improvement.
You may have noticed that the IEEE 2675 DevOps standard doesn’t mention observability in the definition of DevOps. There are many things not mentioned in the definition but are firmly embedded in the standard. Let’s see how this works.
DevOps Processes Support the 3 Pillars of Observability
To begin we need to decide what the relevant metrics are through review and discussion. We should only record the relevant metrics to reduce cost and time. Use Monitoring, Logging and Tracing to gain the relevant data from the system. This information has to be correctly consolidated to provide the state information we need. To make the information easy to consume we use Visualization techniques to provide insights into our systems.
Remember that this provides the key insights. If you find a problem you may need to ‘dig deeper’ to get specific information at key times. The value of applying observability is that you know where to look. The value of DevOps is that you know the information is recorded. Left shift to design observability in from the beginning as retrofitting systems to apply observability later is never as easy.