Yesterday I have read an article called From J2EE to Jakarta EE. Surprisingly enough, it is about emergence of what is nowadays known as Jakarta EE. It appeared to be quite a nice summary, though a bit short and only scratching the surface.
But then there is a part in which the term “microservices” is “explained”. Allow me to quote here the whole paragraph I will be disputing with for the rest of this text:
“Other solutions closer to real Jakarta EE alternatives have emerged as well, and among them, Netty, Quarkus, or Helidon are the best-known and most popular. All these solutions were based on a couple of software design principles like single concern, discrete boundaries, transportability across runtimes, auto-discovery, etc., which were known since the dawn of time. But because the software industry continuously needs new names, the new name that has been found for these alternative solutions is microservices.”
I was left jaw-dropped for a moment. I was like dafuq did I just read? Not that I wouldn’t agree with Nicolas Duminil (the author) that “the word microservice became one of the most common buzzword”. But twisting the whole thing into a mere alternative to traditional Java enterprise applications? Boy, this is wrong on so many levels!
So, what is a “microservice” then?
It is a mental concept, a design pattern if you like. It teaches you to break your large application into smaller independent pieces communicating to each other via network API calls. Instead of having one large codebase that becomes harder to maintain over the time, you break it into much smaller pieces. Those pieces are independent, so you can implement new functions or refactor much easier. And then deploy the result independently without having to build and ship those behemoths that became known as “monolithic applications”.
This formerly unique approach has its pros and cons. And like every rule tends to do, overusing it and following it blindly may cause more troubles than benefits. Many production teams (including mine) have already found numerous pitfalls including the fact that microservice != microfunction. The monolithic applications deserve to be decoupled, but not torn down to single functions, each wrapped in its own microservice. The proclaimed benefits would then be cancelled with the configuration and maintenance overhead. From my experience it turns out it is more practical to group functionality on logical domain basis into something that should be called “micro modules”.
But from the higher perspective – this is still a microservice – a piece of functionality, that can stand alone, but doesn’t quite make sense being just alone. Only together with other such pieces it would assemble an application. And there is one important thing to remind now – those pieces are platform and language agnostic!
Therefore, microservices ain’t no contradiction to Java EE / Jakarta EE applications. Quite the contrary, there is an intersection. You can easily have a bunch of Tomcat servers running old-fashioned "fat" Java .wars written purely with Jakarta EE libraries and it could still be a “microservices architecture”. In fact, this is what we are implementing for one of our customers right now – taking 15 or more years old apps, wrapping them into containers and building on premise “cloud” from them. This is phase one. Shall it be successful, we may move towards re-writing some of those apps into modern cloud-native solutions. And maybe we won’t, who knows what the next years bring?
However, there is a reason why the above won’t be outperforming in high-demand cloud environments. We already see the immense amount of memory consumed by our runtime server instances. And talking about some dynamic scaling? When containers are starting for tens of seconds, even minutes?
What Quarkus and other Java-based “alternatives to Jakarta EE” really try to do, better or worse, is to address those bottlenecks. They are reducing the image size by stripping out unnecessary burden of unused classes to help with resources overconsumption. They also do various things to speed up cold starts, thus allowing creation of new instances in just fractions of seconds.
Obviously, not every project would benefit from such capabilities. Not every project would adopt them successfully. Some would fail or already have failed miserably. And for sure Jakarta EE will still have its place in the vast Java ecosystem. But please, stop making misleading definitions.
Top comments (0)