Today’s cloud environments rely on microservices, service meshes, containers, and orchestration tools and are too complex for traditional tools to measure and monitor performance metrics effectively. The number of interdependent services—and the inherently ephemeral nature of cloud workloads—make it challenging to identify which metrics to monitor and issues to troubleshoot down to the root cause.
When performance monitoring was enough to help assure availability
In the early days of cloud applications, developers built them like they built applications deployed on VMs or on-premises hardware. They defined the processes the application would use and allocated the system resources needed to support them. This style of application development made application performance monitoring (APM) straightforward. You knew in advance which processes supported which applications, the resources the processes and applications required, and the amount of load they could support. Based on this knowledge, you could quickly develop meaningful performance metrics, baseline performance, track trends, and define and prioritize alert notifications.
In this well-defined environment, troubleshooting was relatively easy. You knew the processes and resources each application used. When something was slow or unavailable, you could immediately narrow the scope of your troubleshooting efforts to this known set of processes and applications. You knew which alerts were likely to be significant, which logs to search for exception events, and which resource metrics to check. And though you could end up spending considerable time fully understanding and then correcting the issue, it was still a known universe of potential problems.
Knowing what could go wrong also let you anticipate issues. If an authentication service was non-responsive, you knew the applications calling the service, including which users logged into those applications. The ability to anticipate the impact allowed you to mitigate issues by manually rerouting requests, bringing additional resources online, and, if necessary, notifying users of potential performance impacts. These mitigation measures, however, relied on constant monitoring and frequent human interaction.
The shift to containers and microservices
This style of application design, however, wasn’t well suited for cloud-deployed applications. For example, when IT teams allocated cloud resources to support an application, the resource was removed from the available resource pool and became no longer available to support another process. And for those applications deployed in a public cloud, regardless of the resource going unused, it would incur a charge, driving up application costs. Finding the right balance between enough resources to support the application while not leaving too much unused capacity was a continual challenge.
The primary drawback of these structured applications, however, was scalability. The cloud promised to deliver unlimited scalability and responsiveness, enabling applications to dynamically respond to surges in demand. Unfortunately, defined services and resource allocations inherently throttle scalability by building in constraints and bottlenecks.
To achieve the promised scalability while limiting the cost of running applications in the cloud, teams had to rethink application design. With the drive for faster innovation and quicker releases, development teams adopted higher velocity and more agile release cycles. They divided processes and services into smaller, discrete components reusable across multiple applications—enter microservices. Independent teams developed these components, simplifying release planning and accelerating feature delivery.
The merging of development and operations functions into a single DevOps team highlighted requirements for application portability and enabled deployment and operational concerns to be integrated into application design and development. And containers that simplify testing, avoid many deployment issues, and provide a consistent, well-defined environment have become a popular choice.
Challenges monitoring distributed applications
As these trends converge, we see increasing adoption of microservices, containers, and container orchestration frameworks, all driving up the complexity of distributed cloud-native applications. These new microservice- and container-based applications are dynamic and short-lived, spinning up containers and services when there’s demand and killing them when loads decrease. Using these new tools, organizations can achieve the responsiveness and scalability promised by the cloud while limiting the costs of unused resources.
Unfortunately, these technologies also dramatically increase performance monitoring complexity. Monitoring teams no longer have a set of defined monitoring and measuring resources to identify issues potentially impacting application performance since containers and services are continually in flux. The transitory nature of containers makes it more challenging to locate relevant event logs for error scanning, and there’s a risk the event data disappears as containers die. Troubleshooting becomes more complex as services are reused across processes and systems become more interdependent.
APM tools are designed to meet this need specifically by combining metrics, traces, and logs as well as user experience data into a full-stack visibility solution. These tools can trace a single request through the system, identify issues, and accelerate root cause analysis. APM tools are also great at tracking performance trends, providing performance tuning, and adding context to log data.
Enter application observability
Application observability expands APM by building in intelligent automation and machine learning into the system. With application observability, teams can identify what’s broken and why, including specific users and the business impacts of issues. They can move from reactive monitoring to predictive modeling of performance impact.
With application observability, telemetry data such as user interactions, application requests, and resource performance are interwoven, creating context around each system interaction. This context is then used to simplify root cause analysis and understand the interdependencies and relationships between components. This new context can predict the impact of system performance behaviors from specific users to the business as a whole.
The shared context, intelligence, and automation offered by application observability can automatically prioritize and filter events and alerts based on impact. It ensures important events are not lost in the noise of chatty systems and empowers teams to prioritize resources to address the issues mattering the most. Identifying and understanding all areas of impact at the time of the incident enables teams to align with the business and drive better outcomes.
Like traditional application performance monitoring, application observability measures the overall health of systems, detects outages and performance degradations, and accelerates troubleshooting. However, application observability extends these functions so teams can understand how dependent systems interact, show how they might impact each other, predict performance changes, and identify unknowns having never existed in the past. Application observability with automation, intelligence, and machine learning, is purpose-built to effectively monitor and manage the performance of highly distributed cloud applications while delivering the best business outcomes.
