Claude Moore

Tim Cooke wrote:The system I'm referring to was a pretty serious financial trading engine so not trivial at all. It used jpa and messaging, although Tibco FTL rather than RabbitMQ, and was a decent size codebase. My point here is that serious "enterprise" grade systems work just fine without a fancy framework.

I suppose the only way for you to be sure if spring adds any significant overhead is to compare and measure it. Then do a cost benefit analysis to decide what to do. Cost in this context being memory usage primarily.

May I ask you what was the overall computational power consumed by the project you were referring to ?

Tim Cooke wrote:If each of your services really are micro in size, then would you consider forgetting about spring boot altogether and just using Java? I worked on a system a few years back where performance was of critical importance and we did not use any such framework, just straight up Java. We got along just fine with it.

That's a good advice, but each service isn't probabily going to be really "micro", and each service will need to interact with a message broker (RabbitMQ, to name the preferred choice) and to use JPA (or similar) to work with database.
Not sure that there would be a sensible difference between a plain java solution and a restricted choice of Spring started (in terms of memory, of course).

Ron McLeod wrote:The tech stack I've used for number of recent microservice based solutions is:
 - Quarkus framework using microprofile APIs for applications
 - GraalVM to perform AoT compilation and produce a Linux native binaries (often reduces RAM footprint to around 25% of JVM requirements, and startup times in the few tens of milliseconds)
 - Buildah to create container images (often using Redhat UBIs for base images)
 - Podman to run and manage containers (daemonless, SELinux aware, and has good support rootless, supports Pods)
 - GRPC (protobuf over HTTP/2) RPC operations or pipelining using streams
or
 - RabbitMQ Broker for for pub/sub realtime communications (MQTT/AMQP) or Streams for Kafka-like functionality
 - Separate (typically NoSQL like MongoDB) datastores for each microservice
and/or
 - Data respository microservices (still using NoSQL datastores) when shared state is required to support multiple instances of the same service running in either a loadsharing or active/standby configuration
 - Linux platforms for execution (typically Oracle Linux using RHEK)

If you not are fixed on Spring and Docker, maybe look at Quarkus and Podman.

Thanks for you very detailed recipe ! Have a cow !
By the way, I've considered Quarkus as a viable solution, but I've the strict constraint to choose a technology team is skilled on. What's its learning curve ?

And, by the way: thanks a lot both of you.

Tim Cooke wrote:
I don't think micro services is the right term for what we're discussing here. You have an infrastructure platform management problem. How to host multiple docker based applications on a single host, or more specifically how can I reduce the system resource requirements of each docket based application so you can host more of them on a single host.
Does that sound about right?

You've got the point. At this moment, it's unclear to me as well whether these 'colocated application services' (a term that may better suit the project for now; let's avoid 'microservices' as it might be misleading) will collaborate with each other or operate in isolation. The overall design may evolve during the analysis; for instance, a repetitive task like reading data from an RDBMS might warrant implementation as a 'utility [micro] service.'

That said, as Tim succinctly put it: given Spring's resource demands, especially RAM, how can we minimize its impact? And more broadly: is Spring Boot truly well-suited for microservices applications, considering its resource requirements?

Liutauras Vilda wrote:Design diagram would speak a lot, whether those services talk to each other and to which degree. Understandable if those could not be shared.

I'm sorry Liutaras, cannot share nothing publicly, but at the moment seems that no service will talk to each other, at least not intensively.
If you want, we can think in abstract terms by saying that a certain number of functionally separate applications need to be implemented in Spring, which share the need to read and write data to relational and non-relational databases, exchange messages, and expose (few) REST APIs, or possibly none at all – they will be pure services with no user interaction. That being said, what could be a valid deployment strategy to minimize memory usage as much as possible, considerating also that Docker it's a must-have requirement ?

Tim Cooke wrote:I've been working on the assumption so far that what you're describing is a single software system decomposed into many components, each running as a "micro service". But would I be right in saying that what you are really describing is multiple separate and completely unrelated software systems? All that need to be hosted on a single VM?

My apologies, Tim, please accept them !! I've misread JVM instead of VM !!!
The client intends to create separate servers to host the project; the idea is to use Linux servers with Docker on board. Nothing prevents the possibility of having Windows services in the future, interacting with the platform via message exchange through a messaging broker, but as far as we're concerned, at least initially we'll have a single VM hosting the whole thing.
And yes, each "micro service" will be responsible for managing a specific business process, for example handling customers' orders issued via an external e-commerce application and register them on main ERP, or updating available goods quantities on e-commerce. Another service - for example - will be responsible to send invoices to customers, or to send purchase orders to suppliers and so on. As a whole, all process will be somehow related; but taken as single computational unit, are quite uncorrelated.

Tim Cooke wrote:
[cut]
For me one of the motivations of micro services is environment and/or platform independence, which you don't seem to be able to avail of with the one big VM you have.
...
[cut]
The primary cost of micro services is messaging. You must now design and manage communication between services, which is a non trivial task. What if a message doesn't arrive? What if it arrives more than once? What if it takes a long time to arrive? What if a service goes down? What happens to messages sent to it now? What happens to the message it was processing when it went down? And since you're doing all this inside a single VM, what happens to the state of the system when the VM goes down? How do you recover from that?

It's a difficult exercise.

I never thought it would be a simple task, quite the opposite. The messaging part will be the backbone of the project, and an orchestrator will be developed to coordinate the processes – unfortunately, I can't go into too much detail. There will also be some services that, for application-specific reasons, will be developed in .NET Core or Python. Not all of them will necessarily be developed in Java, but most of them will.
I would still be curious to know how it would be possible to have independent modules within the same VM: if you're talking about queues and threads, I remain quite skeptical, and my first impression is that it's a somewhat — shall we say — makeshift solution. Sure, I can define n @Services, but it's certainly not the same as having n containers, each with its own lifecycle management.
Wouldn't it be better, in that case, to develop and deploy separate WAR files and deploy them in Tomcat (for example)? Could this reduce the overall overhead?

Liutauras Vilda wrote:
And this is where it becomes a bit tricky ...

I understand what you mean, but I can assure you that, although the microservices work on the same DBMS, each of them will access specific tables (there will be no cross-cutting tables). The database is simply pre-existing, and there is no intention to refactor it

Liutauras Vilda wrote:

Claude Moore wrote:Micro services are of course not mandatory, but we're going to develop a number of services which must be run independently each other

Out of interest, what's the plan about the database? Shared for all those aforementioned micro services or one per service?

Many service will act as ETL transformer, reading from a datasource A and writing on a datasource B. We'll have services running actual business processes as well, with a shared database instance (even if it's not a best practice, I know)

Tim Cooke wrote:The target environment is a single physical server? What's the motivation for micro services?

Well, not physical in strict sense. It's a VM running on a cluster; still on premise, not in cloud.
Micro services are of course not mandatory, but we're going to develop a number of services which must be run independently each other; we'd like to be able to scale them and not to be tied to a specific technology stack,
even if at least initially they're going to be all developed using Java (and Spring).

At the moment, there are no strict constraints; it is believed that the client might agree to have a server—with Docker Engine installed, essentially, along with all the various container instances—with 64 GB of RAM (overall, a reasonable requirement for a company of the client’s size). However, having 2 GB per service personally strikes me as a demanding memory requirement. While I’m not questioning Spring Boot itself, I wonder—and I ask the forum members as well—what strategy could be adopted to minimize the resource effort required by a single service as much as possible.

I think the issue of Spring Boot’s RAM consumption is objectively a critical point; otherwise, the rise of alternative frameworks or specific approaches like GraalVM’s native compilation—which are more or less aimed at mitigating this issue—would not be explained.

I need to develop a microservices application, and given the team's technological background, the almost mandatory choice is to use Spring Boot. This framework is fully justified by its modern approach, vast library ecosystem, and adherence to contemporary development standards. What raises concerns is not the quality of the framework itself, but its significant memory footprint. A rough estimate for the project foresees around a hundred microservices of varying complexity. The plan is to group several of them to avoid excessive fragmentation of the overall project, following an 'area-based' approach: for example, one service (not so 'micro') will handle customer orders, others will focus on warehouse management, and so on. With this approach, we estimate reaching about thirty deployable units.

As the complexity of individual services grows, we estimate a minimum memory usage of 1.5–2 GB per service, leading to an overall requirement of around 50 GB of RAM, even with a conservative calculation.

Excluding paths we’re not ready to explore—like using Spring Native + GraalVM—what deployment strategies could help minimize computational requirements? Currently, the choice is leaning toward using a JDK (OpenJ9/Temurin) known for efficiency and low footprint, along with properly configuring the JVM to optimize GC and memory allocation for threads.

We are also considering sharing the JAR files of various starters and deploying Spring modules as WARs inside a container instead of individual Docker instances. However, we want to avoid unnecessary complexity and are unsure if this approach would effectively reduce memory usage. Any advice?

Tim Holloway wrote: ...just as container security does for JEE.

..and also Spring Security does. Just mentioning it since OP talked about Spring and social login.

You don't have to implement JWT from scratch: JWT is an industry standard, have a look at this site and choose the jwt library that best fits your needs.