Everyone uses fat JARs because it removes a lot of things that can go wrong operationally (especially when standing up new servers). The approach described in

Everyone uses fat JARs because it removes a lot of things that can go wrong operationally (especially when standing up new servers). The approach described in this article is the way Java was designed to work; but then everyone said you needed a "self-executing" service binary for portability. Enter the fat JAR, containers, orchestration layers, etc. JVM application servers are certainly the way to go if you run a bunch of Java. But then you're committing to maintaining a bunch of dependencies on your application servers, so really you're pushing the tech debt down the line to your ops folks who now have to ensure dependencies are synced, maven servers running and updated properly, proxies punched for new external dependencies, etc.