Mittelstand, Finger weg von Microservices!

Wie du deine Spring Boot Anwendung mit Spring Actuator und Micrometer überwachen kannst

Im Bereich der Anwendungsentwicklung mit Spring Boot ist es wichtig, sich nicht nur auf die Entwicklung zu konzentrieren, sondern auch auf die Leistungsüberwachung. In diesem umfangreichen Guide werden wir die Schritte zur Einrichtung der Überwachung für deine Spring Boot-Anwendung mithilfe von Spring Actuator und Micrometer sowie die Verwendung von Prometheus und Grafana zur effektiven Metrik-Verarbeitung und Visualisierung untersuchen.

Spring Boot Monitoring verstehen

Das Monitoring ist ein wesentlicher Bestandteil, um die Stabilität einer Anwendung sicherzustellen. Es ermöglicht Entwicklern, den reibungslosen Ablauf des Systems zu überprüfen und potenzielle Probleme zu erkennen. Im Zusammenhang mit Spring Boot machen verschiedene Tools wie Spring Actuator und Micrometer das Monitoring zu einem mühelosen Prozess.

Marcus Held

Performanceprobleme ade: Wie Project Loom die Asynchronität abschafft

Jeder der eine Backendanwendung mit mehr als einer Hand von Nutzern entwickelt weiß, dass die meisten Performanceprobleme mit I/O zutun haben. In modernen Webanwendungen sind dies in der Regel Calls übers Netzwerk. Sei es REST-Requests zu einem anderen Service, Queries an die externe Datenbank, oder die Kommunikation mit einer Middleware. All diese Fälle bearbeiten wir - bewusst oder unbewusst - in asynchronen Threads. Und damit blockieren wir den main-thread nicht mehr. Dies korrekt zutun ist nicht trivial. Project Loom wird im September mit Java 21 released. Virtuelle Threads werden es uns ermöglichen unsere Programme komplett sequenziell zu schreiben. Und dabei nutzen wir unsere Ressourcen immer noch optimal. Doch welche Möglichkeiten eröffnen sich für das Spring-Ökosystem und wie wird uns das in Zukunft beeinflussen?

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