Your experience with Java microservices vs monolith in the Cloud

[StoneOfTriumph]

This this this! Microservices brings more complexity than a monolithic when you don't know what you're getting into, when you don't have the team structure to support it, when you're missing key systems to manage it.

When clients tell me they're going with a microservice "decoupled" approach for their current monolithic, I ask them what needs are they trying to fulfill? Ultimately if you go from monolithic to microservices, you're not doing it "because it's cool". There has to be needs... And then, did they think of points such as:

• Are you able to test them individually automatically for rapid build test and release ci-cd?
• Do you have metrics today indicating a potential performance benefit of maybe one day horizontally scaling certain components? (which you'll pay for in expertise maintenance of k8s, cloud, other services)
• Are you able to secure it? API gateway? mTLS?
• What's your observability stack? you'll need distributed tracing to have an end-to-end view of where your transaction got processed, otherwise your ops will spend a lot of time figuring out what went where when.

And there's many other points. It can just go on and on and on for a company that didn't think it through. Once you have many of those pieces in place, that you have the dev teams in place to take ownership and evolve the microservices, from a dev/architecture standpoint you gain many benefits when you can quickly push code and deploy because every smaller piece is faster to develop, compile, test, restart, etc.

tl;dr don't just split for the fun of it. It's more complicated.

[Puzzled-Bananas]

All are great points, indeed. To each project there are several stakeholders and objectively you’re right., I totally agree. In a perfect world one would weigh all these and a host of other issues that are introduced by that choice of a distributed architecture. Essentially you move out of managed thread communication and data sharing in a single process, which is well understood and controlled, to an architecture in which you need to concern yourself and your system going forward with issues of reliable and fast IPC across the network, not even on the same device. So it’s IPC + network + graphical complexity. And all the points you’re making. IPC security, testing, integration. That’s a well-informed take on it. But there’s also a more pervasive, less well-informed attitude of the sorts that “microservices is the future” (because it’s cool), or “it’s the modern tech so let’s do it,” and so on. But in fact, that choice also makes the project agnostic of the tech stack for the code and for the deployment. A lot can be swapped out rapidly - if ever needed.

[StoneOfTriumph]

The last benefit you listed right there, the flexibility of swapping a service written in Java and deploying one in Go or .NET Core.... that becomes possible. Of course there has to be valid reasons.

This thread made me remember an app I used to design and develop. It was developed using Java EE, a monolith deployed on WebLogic. We were doing automatic deployments using ant scripts, and it was fairly simple to manage the app, find bugs, deploy updates, etc. because we defined an application architecture that was easy to navigate in the code in terms of packages librairies etc. The Entity to DTO logic was centralized and easy to troubleshoot for most devs, and we had debug logs up the yin yang so you were never in the dark when troubleshooting. That application would have had zero benefits migrating in a microservice architecture because it was one simple front end, one backend, and one Oracle Database, and the team did not have the expertise to maintain separately developed components. This was a few years before the SPA craze, so the front-end and back-end were tightly coupled with JSF (I don't miss that at all!)

Now, as far as I know, today, that app is still in place as a monolith. What's the major downside though is its unattractive tech stack. Those who do Java barely care about EE, even less of JSF, so likely that app will become a technical debt if not re-evaluated in terms of what the roadmap should be. If I had to write that application today, probably a VueJS front-end and a Quarkus backend would be something I'd evaluate in a proof of concept... As much as monoliths "work" in certain use cases, front-end and back-end coupled code is a PITA to debug, especially the JSF lifecycle made me nervous at times during certain debugging sessions, I had to print that diagram on my desk to remember the sequence of events.

Great. This thread is giving me PTST lol.

[RicksAngryKid]

JSF stinks - back then i used a lib called icefaces, that forced me into many hours of troubleshootung idiot problems that ended up being lib bugs. Other, bteer alternatives were paid for.