Spring is compliant with and reliant on many of the JavaEE specifications - JDBC, Servlet, JAX-RS, etc. It provides DI that is not JavaEEs CDI. I'd consider S

Spring is compliant with and reliant on many of the JavaEE specifications - JDBC, Servlet, JAX-RS, etc. It provides DI that is not JavaEEs CDI. I'd consider Spring as more of a non-JavaEE application server. Pick either Spring or Wildfly/Glassfish/Websphere/etc and you're either using part of the JavaEE specification with the former or the full specification with the latter. Avoiding JavaEE for micro-services requires moving to something like DropWizard. Instead of a 200MB application server you end up with a 20MB application. Unfortunately, running that application in a Docker container will spin up a 180MB JVM. So the main reason we're moving away from JavaEE is actually more related to our move to container orchestration and that was originally driven by our adoption of micro-services. If you write a micro-service with a single end-point why should it use 500MB of memory?