This year at JavaOne 2015 there was a recurring theme across many of the Cloud and DevOp tech sessions that was promoting self-contained deployable Jars (not EARs or WARs) as a more efficient approach for deploying lightweight Java based services. This approach also plays well for a microservices type architecture and can also easily make use of containers, like Docker, PaaS offerings like CloudFoundry or Heroku, or even Oracle’s new Java SE Cloud Services offering.
Being able to deploy small, self-contained services (compared to large, monolithic EARs) brings a whole range of benefits, like being able to deploy more often, and deploy individual services individually without touching or impacting any of the other deployed services.
If you go a step further to consider a deployable unit as a disposable Docker container, then you have to start asking questions about whether a traditional Java EE App Server is still required, or even fits at all this this kind of deployment approach.
Oracle has a supported project on GitHub for Dockerfiles to build images running Weblogic 12c… if you try to do this you also wonder just just how practical it is to even attempt to run Docker containers that are 2GB+ in size… yes, you can do it, but are you really getting the benefits of the lightweight and lean, disposable containers at this point?
I came across this article by James Strachan, “The decline of Java application servers when using docker containers“, which is an interesting read on this topic. The more you look into Docker, containers and lightweight services, you have to question whether Java EE App Servers are losing their relevance. Or at least whether they are relevant for this approach of containerized deployments.