Introduction Observability is a critical pillar of operability in software systems. And the more complex the mesh of contributing components and infrastructure, the more important to have clear observability. The market for observability tooling is getting more mature with the explosion of the adoption of microservices and the standards for the interfaces are emerging with different vendors, adapting them at different levels. Plenty of SaaS and on-premise products are around to buy and start using and almost all of them come with a 5 minutes demo to show how easy they are to use!

Intro I was a guest at the The Exchange Nordics Podcast a while back around this subject and decided to write a bit more detailed blog post with my thoughts more organized. I recommend listening to the podcast as the other guests had views on the subject from different angles which enriches the understanding. What are Reactive and Proactive working? Looking at the Oxford dictionary for the adjective’s definition I find the brief but clear description as follows

Reading is one of the activities I enjoy, being sci-fi and fantasy books or textbooks around my career or other science and society-related topics. The same applies to newsletters and other types of well-researched opinion articles about science, tech, business, and philosophy. There are some excellent podcasts that I follow and listen to the choice of episodes or every episode they publish. The majority of my reading, when it comes to books, is in form of listening.

This is one of the common principles that not only software developers are adhering to, but also the whole of civilization is attempting to adhere to. But it is sometimes not as easy as it may sound to figure out the right problem, and, more importantly, what is the right level. A simple example is a pull request fixing a small bug that should not be blocked because of an architectural decision made a year ago and has about 5 engineer years’ worth of work built around it.

Fragmentation of Java runtimes in a microservices-based architecture There are many many differences between the monolithic architecture and microservices-based architecture. One of them is the number of independently deployed bits of software, with a monolith there are usually many replicas of the same distribution running on many machines, virtualized or not. With the Microservices the number of independently deployed software systems grows as the different contexts raise… or an already existing context boundary grows enough to be split.

From Monolith to Microservices Having redundancy in application space is pretty common. We have all seen them for decades in different ways. Hardware, software layer 4, or layer 7, etc. All of them what they do they direct traffic based on a given decision-making rule to a destination. Being weighted round-robin, resource/load-based metrics, etc. All they do is reliably direct traffic to a healthy node in the destination. In a very simple and basic view with VMs and data centers, if VMs fail the load balancer will direct loads to identical VMs, all nodes more or less can handle any of the incoming requests (ignoring stickiness, etc.