If I unite many web apps into one, will I save resources?

Question

I'm comparing 2 different approaches of J2EE application architecture:

1. Divide independent parts as modules of one big web app.
2. Divide independent parts as different web apps running on same server.

Between these approaches I prefer the second one because it allows me to make changes without redeploying the whole application. Imagine that you want to change something in app2. In the case of one big app you have to redeploy the whole application. In the second case you have to only redeploy app2.

But I have some doubts about resources consumption such as memory usage and CPU usage. I personally think that each J2EE application, no matter how large it is, has some minimal limit of memory it will necessary use. This minimal limit is what is needed for context loading, web framework config files, jar libs and other things. My hypothesis sounds like "Having many web apps running on same server leads to multiplication of wasting of default minimal resources." Is the picture below correct? Does one big application save me from default resorces overhead multiplication shown on the picture?

Answer 1

It is a little unclear if you mean sharing the same J2EE container or physical server. Regardless, my suggested approach is the same but I don't know if I am suggesting option 2 (which I think I am) or a third option you had not considered.

If you try and host lots of apps as one app it means you will suffer from far more from things like threading overhead within the app. The OS is better at managing this sort of thing usually. Also especially as the number of apps grows, that being able to deploy just one thing point is very useful. In general it will be a little less but a larger app will have more minimum overhead so the difference is not as pronounced as your diagram indicates and we are talking about such small amounts of resources that you should favour the robust and flexible approach over scrimping for a few megabytes of memory.

My company recently threw out a monolithic Jetty container in preference of lots of tiny webapps each with their own embedded Jetty server running on the same server. Mostly because it was taking over 30 minutes to restart the server!

Yes it can use a little more in the way of initial resources but the coordination resources are lesser. You also gain the ability to split them across several boxes. Also one component crashing is less likely to affect the others. Also you can scale them individually e.g. you may need 3 instances of app 2 but only 1 of the others. In addition you can tweak the minimum resources assigned on a per-app basis which would likely let you pair it down smaller.

Additionally joining them together can make tracing down the cause of a problem harder as the root cause may not be in the app that failed. This again comes down usually to resources in that App2 may be creating lots of objects starving App3 causing an OOM in app3. This would take down all 3 but would look like app3 was the cause when it was actually app2

Thus advice in terms of resources, flexibility, scalability and robustness is option 2, many small apps.

Answer 2

You might save a bit of disk space with the god application approach, which btw is an anti-pattern.
But you're gaining a maintenance nightmare, deployment nightmares, support nightmares, etc. etc. etc. I think you get the message.
Rather than deploying just one part that changed and leaving the rest you now need to every time some tiny thing changes in a subsystem deploy everything from scratch, not a good idea.

Answer 3

I know this question is about apps not services but you might want to read this article as the idea of splitting a service into microservices is not dissimilar to splitting an app into (possibly) micro apps.

Generally many smaller apps/services is the way to go, but ...

"Microservices imply a distributed system. Where before we might have had a method call acting as a subsystem boundary, we now introduce lots of remote procedure calls, REST APIs or messaging to glue components together across different processes and servers."

http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

If your separate apps will not need to interact with one another then all is good, but if by splitting up your single app into separate apps you then need to start making API calls to each other then you would encounter extra work and testing.

Another thing to consider are session cookies. With your current "god" app you probably just have one session for all the apps. If by splitting out the apps they truly are separate with their own authentication, session handling and web interface then all is good. But if not then you have some extra work to do.

The issue would then not be about saving resources but more about managing complexity.

Cheers,