SMEs, Steer Clear of Microservices!

How to Monitor Your Spring Boot Application with Spring Actuator and Micrometer

In the world of application development using Spring Boot, it’s crucial to focus not just on the development aspect but also on performance monitoring. In this extensive guide, we’ll explore the steps to set up monitoring for your Spring Boot application using Spring Actuator and Micrometer, and how to employ Prometheus and Grafana for effective metrics handling and visualization.

Understanding Spring Boot Monitoring

Monitoring forms an essential part of ensuring the health of an application. It allows developers to verify the smooth running of the system and detect any potential issues. In the context of Spring Boot, several tools, such as Spring Actuator and Micrometer, make application monitoring an effortless process.

Marcus Held

Goodbye Performance Issues: How Project Loom Eliminates Asynchrony

Anyone who develops a backend application with more than a handful of users knows that most performance problems are related to I/O. In modern web applications, these are typically network calls. Whether it’s REST requests to another service, queries to an external database, or communication with middleware. We handle all these cases - consciously or unconsciously - in asynchronous threads. This way, we no longer block the main thread. Doing this correctly is not trivial. Project Loom will be released in September with Java 21. Virtual threads will enable us to write our programs entirely sequentially. And yet, we are still making optimal use of our resources. But what opportunities does this open up for the Spring ecosystem and how will it affect us in the future?

Marcus Held

Accessing Non-Final Property Name in Constructor With JPA

The implications of JPA always manage to surprise me. Yesterday a colleague of mine made me aware of a warning in IntelliJ. The conversation went like that: “Marcus, in your blog you explained that we should check constraints in the constructor instead of bean validation . Me: “yeah”. “I wanted to make it right, but when I do it in this entity IntelliJ warns me with Accessing non-final property name in constructor”. So I dug into it. Fearing my conclusion would change the recommendation that I gave in (k)lean JPA two years ago.

Marcus Held

Don't confuse configuration and constants

From time to time I experience that an application is unnecessarily configurable. In a recent project I experienced how too many options lead me to feel much more complexity and increased my mental load. Looking deeper into some of the values I saw that these were actually constants that would be dangerous to change “on-the-fly” anyway. In this post I reflect on this and share my thoughts.

In this project the backend processes data from an embedded devices that communicate through LPWA networks. This sets specific constraints on the system. While we developed on that system the embedded developers figured out specific values for the best user experience in terms of e.g. timeout configurations. These values were intuitively implemented as spring properties, since we had to “play around” a bit in the beginning and the underlying library that we configured also called the properties a “configuration”. But then it stayed in the project. And in the application.properties. When I joined the project this confused me. It created the impression, that these values are meant to be configurable. But actually this is not the case. For our system - with the specific constraints - these values are constants.
I actually don’t want to configure them without testing the application. Also, these values are in sync with our firmware. So I can’t even change them without a coordinated effort. In these scenarios I rather want to have a separate deployment and force myself to go through the whole build-test-run cycle.

Marcus Held

Microservices are a Big Ball of Mud

Over the past years I attended hundreds of interviews. Many candidates proudly told tales on how they develop their projects with a microservice architecture. Often (I don’t want to say “always”, but from my memory I think it actually is “always”) it does not require many questions to see that they used a rocket launcher to kill a mouse. Microservices are hard. Everyone who experienced the pain of operating such an architecture can relate to it. The complexity kills you at one point or the other. You already had to do multiple refactorings of your architecture - because your domains didn’t work out. I wonder - why is this architecture so appealing to developers? And then I remember why I found them appealing 10 years ago.

Marcus Held