SOA vs. Microservices Monitoring
Some look at microservices as an extension of service-oriented architecture (SOA), and some would say the differences are too numerous to associate them together. Whichever end of this spectrum you’re on, there are realities to deal with when working with microservices. Perhaps the most important aspect when running microservice applications is how you monitor them. This is one aspect where the differences between SOA and microservices become evident.
Different Service Definitions
The key difference between SOA and microservices is in how they view a service. In SOA, the focus is on service reusability, whereas in microservices, service decoupling is the order of the day. Whenever there is a change to be made in an SOA-based application, the monolith is modified. With microservices, a new feature would be decomposed into its own service.
This has a bearing on how governance and monitoring works for these systems. With SOA, it’s a top-down model in which the whole is monitored and each part is monitored in respect to the whole. With microservices, each service requires monitoring of its own. Each service comes under the radar when assessing performance.
Because services are more focused, and each new feature becomes a new service, over time every service becomes laser-focused on one specific task that it performs exclusively. This results in many small services that are lighter, faster and easier to manage and monitor. Taken together, all the services will churn out more metrics in a microservices system than an SOA system. But this is a boon, as it provides more visibility and granular control at every level. So, when trying to understand the difference between monitoring an SOA-architected app and a microservices architecture app, how they view services plays a key role. The differences don’t stop here, though. They continue into what a service network is, and the underlying infrastructure unit.
Monitoring Service Communication
SOA uses an enterprise service bus (ESB) to handle communication internally between the various services that make up an application, and externally with other applications and clients. The ESB plays a central role in the functioning of an SOA application. It enables diversity in the protocols that services use to communicate with each other. It acts as a central mediator between all services and aims to provide out-of-the-box support for various protocols and, in this way, quicken communication.
SOA monitoring revolves around the processing of messages between services. The ESB is the layer that transmits messages between services, so if a service is running slowly or has failed, the number of messages to that service pile up at the ESB. Therefore, it’s important to track the number of messages in queue to spot latency or failures in services. (Related metrics to track are the oldest message in queue to know the extent of latency.) Additionally, for each service it helps to track the messages processed per minute or per five minutes and monitor any deviations from the average.
Microservices depart from the traditional ESB route to adopt a service API gateway. In microservices, each service uses an API to expose itself to other services and to consumers. These service APIs are decentralized, unlike in an ESB, yet still requires monitoring to understand if the APIs are communicating effectively with the rest of the services running in containers. Otherwise, the API becomes the blind spot in monitoring your microservices.
Infrastructure Monitoring
SOA has been prevalent from the times of hardware servers down to the virtualization era and considers certain constraints from the infrastructure that powers it. VMs are larger in size and take time to configure. Whenever there is an update to a VM, it is modified and left running, and a typical VM will run for months or even years with some changes. This means that services are chained to the infrastructure, and changes can only be made as much as the infrastructure allows.
Drastic changes in the number of underlying hosts or storage volumes historically have not been possible. Configuration drift is a constant challenge as VMs and the libraries in them become outdated quickly. Monitoring a VM-based stack involves watching static metrics including latency, throughput and IOPS. The components that affect these metrics are more like black boxes with limited controls to change. This has led to a shift in focus in the container-versus-VM battle, with containers coming out on top.
Microservices and containers go together. In today’s modern era of cloud-native applications, containers have become the preferred infrastructure to run microservices applications on. Containers bring many benefits over VMs: They are much smaller than VMs—just a few megabytes in size compared to the many gigabytes that VMs occupy on a server. They are created in a few seconds, unlike VMs, which can take precious minutes. Containers can be created and destroyed easily, and they enable immutable infrastructure where updates are delivered not in edits to an existing instance but by creating a completely new instance. The container stack is also much more intricate than a VM stack, with new components such as a container registry, an orchestration tool and detached storage volumes.
Monitoring for containers involves tracking every part of the system, including the container engine, registry, images downloaded, container instances being created and retired, storage volumes that are dynamically assigned to containers, network requests between containers, security and access controls and much more. Containers bring deep visibility into every step of the development pipeline, and they involve a wider range of metrics to keep track of, but they also give you the possibility of developing and shipping features much faster than SOA.
There are clear differences between SOA and microservices. When monitoring these respective applications, the approach varies accordingly. Microservices are not just different but also more evolved and advanced than microservices’ older counterpart, SOA. As you transition from SOA to microservices, consider how you can adopt these defining characteristics of microservices monitoring to see better results and have more clarity into application performance at every level.