Microservices present big problems for monitoring. Instead of keeping tabs on a single monolithic application, IT operations now have to contend with dozens, hundreds, or even thousands of modules interacting in complex patterns.
To meet this challenge, IT ops need a fundamentally new approach to monitoring, one that provides end-to-end inclusivity and can provide granular insights into each service.
Why use microservices?
Almost every organization is moving to microservices to break big problems into small ones that can be solved quickly, without blocking progress on other issues.
Microservices require changes to processes, technologies, and the organization itself. Melvin Conway stated in 1968 in his well-known law that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations".
Most companies are based on a siloed structure, which provides a high degree of change control, but an extremely slow-moving organization. And as Conway's Law dictates, siloed structures pushes organizations toward highly siloed architectures:
Figure courtesy of Martin Fowler.
Microservices require an agile structure, with cross-functional teams that build small components of an overall application that communicate with one another via lightweight web APIs:
Figure courtesy of Martin Fowler.
The teams are able to work somewhat autonomously, selecting their own technologies, including programming languages and data platforms. The purpose of this is that, as technology advances, any component can be easily discarded and rewritten quickly. This means each team may select different technologies to build and support each component, like so:
The microservices monitoring challenge
The challenge is ensuring that these components and services work together to deliver a high-quality, highly performant, and engaging user experience. Measuring that these services are functioning together and delivering the user experience expected is a major challenge.
In the past, monitoring tools focused on infrastructure or singular software components, and on measuring operational health. The tools were only moderately successful in achieving this goal but worked well enough for the monolithic, legacy applications and infrastructure.
The advent of microservices has exposed the weakness in the tooling. Now, components are hosted within virtualized machines or containers located across a private cloud, public cloud, or a hybrid of the two. Ensuring that these services communicate with one another to deliver the desired results requires a couple of things from a monitoring perspective:
- Measuring the client performance and operations inclusive of mobile and browser devices. This is what is classified as end-user experience monitoring in application performance monitoring (APM) terminology, but increasingly it must be tied together with the rest of the transaction.
- Following the resulting system interactions needed to service the transaction, from the device through the associated microservices and any third-party components that are required to fulfill the user request and drive the user experience.
If monitoring is not done from an end-to-end perspective, isolating problems is a major challenge. Finding the team responsible for the service at fault can also be a challenge. Consider that a typical architecture looks something like this:
Monitoring also needs to occur in the continuous integration and continuous release pipeline to ensure that new code is performant. Keep in mind that with microservices, small teams are responsible for the entire service life cycle. That means these teams need both service-specific visibility as well as cross-service visibility during development, testing, and release.
Finally, keeping track of a complex set of shared and ever-flexing services is a challenge from a documentation and education perspective. New employees or team members must understand how these components interact with one another.
Keeping manual diagrams of services and service interaction is no longer feasible in many of these complex applications, yet that is often what is attempted today. New technologies have arisen that do much of this work for you in leading APM products, by discovering the application and visualizing the application in real time.
What a microservices monitoring solution needs
Critical features within a microservices monitoring offering should include:
- End-user experience monitoring
- End-to-end transaction tracing
- Key transaction monitoring
- Application topology visualization and discovery
- Views specific to a single service, enabling teams to understand their services
- Custom metric APIs
- Custom logging APIs
Other key areas to focus on include server or infrastructure monitoring, but very few tools handle this today. Much of the innovation in APM will come from deeper understanding of the infrastructure delivering applications, whether they be delivered from traditional data centers, private cloud, or public cloud infrastructure (IaaS) or platform-as-a-service technologies (PaaS).
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
