Following this approach, the application server is shipped in a container, containing only a single application. The one application per application server approach also matches the idea of shared-nothing architectures.

The question is whether application servers introduce too much overhead if a single server instance only contains a single application. In the past, the storage and memory footprint certainly was significant.

Modern application servers considerably improved in this area. There are container base images of servers such as TomEE that consume 150 MB and less, for the server including the Java runtime and operating system, mind you. The memory consumption also significantly improved due to dynamically loading functionality.

In enterprise projects installation sizes are usually not an issue to be concerned with, especially if they're not exceeding all bounds. What's much more important is the size of the built and shipped artifacts. The application artifact, which in some technologies contains megabytes of dependencies, is built and transmitted many times. The runtime is only installed once per environment.

Container technologies such as Docker make use of layered file systems that encourage the moving parts to be small. Zero-dependency applications support this approach.

Making each and every Continuous Delivery build only shipping kilobytes of data is far more advisable than saving a few megabytes in the base installation.

If the installation size still needs to be shrunk down, some application vendors offer possibilities to tailor the container to the required standards, especially the MicroProfile initiative, which includes several application server vendors, and defines slimmed profiles.

Java EE microservices don't need to be shipped as standalone JAR files. On the contrast, applications shipped in containers should leverage the use of layered file systems and be deployed on enterprise containers residing in the base image. Standalone JAR files oppose this principle.

There are possibilities to combine standalone JAR files with thin deployments, by so-called hollow JAR. This approach, however, is not required when using containers.