adam bien's blog

Due to low footprint, fast startup and low runtime overhead ("The Overhead Of Java EE Application Servers"), deploying multiple WARs into one application server instance running on a single JVM does not save a considerable amount of resources unless you have to deal with Netflix-like scale (ten thousands of dynamic VMs).

You could manage multiple WAR-microservices on a shared application server, but this approach would come with serious disadvantages:

1. Less Isolation: A misbehaving WAR can influence other microservices
2. Complicated Monitoring: it is harder to monitor the activity of a single WAR
3. Less Stability: a redeployment of a WAR could influence others (memory leaks, classloader leaks)
4. Less scalability: it is harder to scale a single process, than multiple processes
5. More complex CI / CD: an executable image will contain multiple microservices and requires coordination between teams

Java EE Application Servers are not suitable to host multiple microservices. The way to go is to ship exactly one Thin WAR ("Thin WARs, Java EE 7, Docker and Productivity") with one application server instance and consider the OS, JVM, applicaton server and the Thin WAR as the executable unit.

A Java EE microservice architecture is about multiple application servers hosting exactly one WAR ("Why Not One Application Per Server?) communicating with each other. Using a single application server instance as a microservice runtime is too brittle, too complicated and hard to justify with numbers.