4

Our future architecture is to move towards docker /micro services. Currently we are using JBoss EAP 6.4 (with potential to upgrade to EAP 7) and Tomcat.

According to me JEE container is too heavy (slow, more memory, higher maintenance etc) for microservices environment. However, I was told that EAP 7 is quite fast and light weight and can be used for developing microservices. What is your input in deciding EAP 7 vs Tomcat 8 for docker/microservices? Cost and speed would be consideration.

user1664338
  • 262
  • 3
  • 13
  • Maybe can be help http://wildfly-swarm.io eg https://github.com/wildfly-swarm/wildfly-swarm-examples/tree/master/docker/docker-jaxrs – Federico Sierra Feb 07 '17 at 13:34

2 Answers2

10

EAP7 vs Tomcat 8 is an age old question answered multiple times here, here and here.

Tomcat is only a web container where as EAP7 is an application server that provides all Java EE 7 features such as persistence, messaging, web services, security, management, etc. EAP7 comes in two profiles - Web Profile and Full Profile. The Web Profile is much trimmer version and includes only the relevant implementations typically required for building a web application. The Full Profile is, as you'd expect, contains full glory of the platform. So using EAP 7 Web Profile will help you cut down the bloat quite a bit.

With Tomcat, you'll have to use something like Spring to bring the equivalent functionality and package all the relevant JARs with your application.

These discussions are typically helpful when you are starting a brand new project and have both Java EE or Spring resources at hand. Here are the reasons you may consider using EAP7:

  • You are already using EAP 6.4. Migrating to EAP 7 would be seamless. Using Docker would be just a different style of packaging your applications. All your existing monitoring, clustering, logging would continue to work. If you were to go with Tomcat, then you'll have to learn the Spring way of doing things. If you have time and resources and willing to experiment, you can go that route too. But think about what do you want to gain out of it?
  • EAP 7 is optimized for container and cloud deployments. Particularly, it is available as a service with OpenShift and so you know it works OOTB.
  • EAP 7 will give a decent performance boost in terms of latency and throughput over EAP 6.4. Read https://access.redhat.com/articles/2607521 for more details.

You may also consider TomEE. They provide Java EE stack integrated with Tomcat.

Another option, as @Federico recommended, consider using WildFly Swarm. Then you can really start customizing on what parts of the Java EE platform do you want. And your deployment model is using a JAR file.

As for packaging using Docker, they all provide a base image and you need to bundle your application in it. Here are a couple of important considerations for using a Docker image for microservices:

  • Size of the Docker image: A container may die unexpectedly or orchestration framework may decide to reschedule it on a different host. A bigger image size will take that much more longer to download. This means your perceived startup time of the service would be more for a bigger image. This also means dynamic scaling of the app would take longer to be effective.
  • Bootup time of the image: After the image is downloaded, the container may startup quickly but how long does it take for the application to be "ready"?

As a personal note, I'm much more familiar with Java EE stack than Tomcat/Spring, and WildFly continues to be favorite application server.

Community
  • 1
  • 1
Arun Gupta
  • 3,965
  • 5
  • 31
  • 39
5

Besides using traditional Application servers, which are not really that heavy, you can taste different flavor of Java EE, called microcontainers.

Java EE is just a set of standards. Standard results in an API specification and everyone is then free to implement the specification. An Application Server (AS) is mainly a fine-tuned collection of this functionality. Those APIs were not brought to life for no reason. These represent functionality commonly used in projects. Application server can be viewed as a "curated set" of those functionalities. This approach has many advantages - AS has many users, therefore it is well tested over time. Wiring the functionality on your own may result in bugs.

Anyhow, a new age has come, where with Docker, the application carries its dependencies with it. The need for a full-blown application server with all the functionality ready to be served to applications is no longer required in many cases. In times past, the application server did not exactly know which services the applications deployed will need. Therefore, everything was bundled in. Some of more innovative AS like WildFly instantiated only the services required. Also, there are Java EE profiles which eased the monolith Application Server a little bit.

Right now, we usually ship the application together with it's dependencies (JDK, libraries, AS) inside a Docker - or we're heading there. Therefore, an effort to bundle exactly the right amount of is a logical choice. But, and it is a "big but", the need for the functionality of the AS is still relevant. It is still good idea to develop common functionality based on standards and common effort. It only no longer seems to be an option to distribute it as one big package, potentially leaving most of the APIs inactive. This effort has many names, be it microcontainers, uberjar creators ...

There are Java EE server so light it is doubtful to use anything else. * Spring Boot is not based on Java EE and in default configuration present in the Getting Started guide, Tomcat is used internally.

The key point is, your Java EE application should be developed as an independent Java EE application. Wrapping it with "just enough" functionality is delegated onto these micro solutions. This is, at least in my humble opinion, the right way to go. This way, you will retain compatibility with both full-blown AS and micro-solutions. The uber-jar, containing all the dependencies, can be created during or after the build process.

WildFly Swarm or Payara Micro are able to "scan" the application, running only the services required. For a real-world application, the memory footprint in production can be as low as 100 MB - for a real-world application. This is probably what you want. Spring Boot can do similar things, if you require Spring. However, from my experience, Spring Boot is much more heavyweight and memory hungry than modern Java EE, because it obviously has Spring inside, so if you are seeking lightweigtness in terms of memory consumption, try Java EE, especially WildFly Swarm (or pure WildFly) and Payara Micro. Those are my favorite AS and they can be really, really small. I would say WildFly Swarm is much easier to start with, Payara micro requires more reading, but offers interesting functionality. Both can work as a wrapper - you can just wrap your current project with them after the build phase, no need to change anything.

Payara Micro even provides Docker images ready to use ! As you can see, Java EE is mature and ready to enter Docker lands :)

One of the very good and reliable resources is Adam Bien, for example in his Java EE micro/nanoservices video. Have a look.

  • I would only add that, in my opinion, application servers / microservers / anything with shorter release cycle is better in the age of Docker. Developers, unlike admins, are able to swap the dependencies quickly and with ease. This way, updated versions with latest functionality come to production almost instantly :) WildFly is one of the containers with relatively short release cycle, not sure about the others. –  Feb 08 '17 at 19:15
  • WildFly releases 2x a year, WF Swarm 12x a year, Payara 4x a year (12x for support suscribers), TomEE 4x a year. You have wide range of options nowadays if you want short release cycles. – OndroMih Feb 15 '17 at 07:57
  • This is absolutely a move forward, as we do not have 1 major release per 2 years anymore. –  Feb 15 '17 at 09:08