Hi,

Microservice Architecture

This buzzword has become a trigger for me. I have written about it often.

Earlier this year, my article Microservices are a Big Ball of Mud trended on Hacker News

The 343 comments on my article clearly show how heated this topic can be 😉 Of course, the rational view on it is different from what I presented in that article. It ALWAYS depends on the context. AppContinuum is an excellent paper offering a reflective view on the subject.

But in this newsletter, we will again address how quickly massive problems can arise when building a MicroService Architecture

A week ago, I reported how a release at a client went wrong . We have now understood and fixed the cause. We had to adjust 1800 lines of code. Wow.

We could not process more than 2 requests per second. Then our connection pool overflowed. And we quickly identified the cause. While holding the database connection open, several Remote Procedure Calls (RPC) were executed. They just took too long. The connection had to be kept open the entire time, and the pool was depleted faster than you could count to three.

You might now say: “Well, obviously. Just make the calls outside of the Connection”

Yes. That’s correct. The solution sounds so simple. But, as always, the devil is in the detail.

Our Connection Strategy is Simple

We open a connection when a new request comes in. We roll back if an exception is thrown. Or we commit when we’re done processing. All of this is nicely encapsulated in a filter. In Spring, this strategy is called “Open Session in View” - I recently wrote an article about this .

The strategy is simple and safe. Every change to our database is atomic. We can’t create inconsistencies. That’s good. But in a Microservice Architecture, which is actually a distributed monolith, it kills us. Because you have to make RPC calls to your services in your domain logic to get the necessary information from the other services.

Now, of course, one might say: “But hey, if you have to do that, you’ve probably cut your services wrong. That should be the exception.”

Yes. True. In practice, however, I see plenty of systems where, under the guise of a Microservice Architecture, a distributed monolith has been built. It’s just too hard to cut the services correctly. Unfortunately, I too often experience a team deciding to develop several services. That is usually the beginning of the end.

Ask Yourself the Following Question

Can (and should) my service be fully maintained by an independent team? No? Then you are probably building a distributed monolith.

So it hit me again. What starts with good intentions ends in great complexity and painful problems. It’s just one of many examples from recent years. And it won’t be the last.

Rule the Backend,

~ Marcus