If you have been following the evolution of microservices architectures and container-based applications, you have also heard ample references to the need for visibility.
The decomposition of monolithic applications into microservices isn’t just an architectural change - it also implies a change in people’s responsibilities and internal processes. The architecture simplifies management and maintenance of functional components in applications but it also frontends the need for developers to understand how services are found, how the application is “wired” together, how services perform together, and the rules that govern their interactions. Many of these were previously considerations for the IT and operations teams when it came time for production deployments. It is no wonder that the term application visibility gets tossed around a lot. But, the term visibility is overused and has come to mean everything from a simple list of all the services running, to command line tools that can provide query results, all the way to much more detailed graphical views with nitty-gritty details. When its use gets overloaded a seemingly simple term to describe a capability becomes confusing. So, what are the essential capabilities needed for application visibility as it applies to container-based applications?
Visibility to New/Updated Services - Service Discovery
When a single application can be made up of hundreds of different services and new services can be introduced dynamically it quickly becomes difficult to keep track of how services find each other and communicate. Individual services may be developed by different groups of app developers and may be introduced into the application at any time. Developers need a way to discover services and their dependencies automatically as soon as they brought live. Application visibility tools should automatically display new services as they come up.
Visibility to Application Dependencies
Perhaps the most obvious need for visibility is to understand the dependencies between the functional components of the application and how services interact among themselves. This means displaying the graph of dependencies among services to make it easy to understand the overall structure and interactions in the applications. The dependency graph makes it possible to troubleshoot application connectivity issues visually.
Visibility to Security and Micro-segmentation
The functional decomposition of microservices results in an explosion in the number of ephemeral endpoints which require the same degree of attention from a security and networking standpoint. With the significantly higher number of interactions inside the data center network, the need to set up policy-driven interactions between services becomes even more important. Visibility to current as well as desired application interactions is necessary to set up the right micro-segmentation policies using accept lists and deny lists. App maps enable the transition to an allowlist-based security posture (just allow authorized interactions - everything else is disallowed), as opposed to a denylist-based posture (just block some interactions - everything else is allowed). Accept-list security postures are inherently more secure.
When container visualization also shows real time policy violations it makes easy for developers to troubleshoot application security issues or perhaps modify policies to account for service interactions not considered previously. Displaying unauthorized accesses, simplifies the timely detection of breaches and compromised instances.
Visibility to Performance and Health Status
A significant portion of developer time is spent identifying performance issues, system bottlenecks, and latency issues. Developers spend several hours debugging connectivity issues or seek the help of the network team in order to identify the source of problems. As the number of services (and interactions) increase, the importance of visibility into performance increases even more. At a higher level, application teams often need the “gestalt” view of the application’s health so that they can zero-in on problem services. To simplify development and maintenance, the system should display the overall health of services based on latency and throughput between services to provide a quick path to troubleshoot problems. Developers will want to drill down to each service to understand performance of inbound and outbound requests.
Visibility by Tenant
CI/CD practices and blue-green approaches to app deployment are becoming common and enterprises have multiple teams rolling out applications and updates. In such environments, visibility should account for role-based access to specific applications. For example, to prevent accidental updates or policy changes to production environments app owners may want to provide visibility only to development and test services by default and restrict production visibility to specific administrative users.
The answer to what is visibility in microservices shouldn’t be, “it depends on who you ask.” Look for the aforementioned capabilities when looking for solutions to help you with the insights that you need as you develop container-based microservices applications.
Learn more about application services and traffic management for microservices
