Can a Java EE application platform really be used for microservices?

A Definition of Microservices

Before attempting to answer the question if a Java EE application platform be used for microservices, let’s establish a simple definition of microservices. For the purposes of this competitive review, microservices represent an architectural approach for software solutions. What sets microservices apart from other architectural approaches is that it treats each service as a discrete and independent part of the architecture. Each microservice serves a single, clear purpose and is accessed using well-defined parameters. Microservices can be implemented using a variety of languages and technologies including Java EE.

Microservices Architectures on JBoss EAP

Java developers can develop and then deploy microservices styled solutions to run on JBoss EAP. An application platform that is scalable and capable of running deployed microservices independently or within a container application platform like OpenShift by Red Hat.

Deployment packaging for microservices on JBoss EAP and other Java EE application platforms is done using WAR and EAR files. The typical application development model for a Java EE application. It is important to note that the packaging of microservices is a separate issue from the design and implementation of them. While WAR and EAR files are well known for being used for monolithic applications, there is no reason that packaging can’t be used for microservices as well.

Now that the compiled code is packaged, next comes the question of deployment topology. JBoss EAP supports multiple choices for this. One popular choice dictates that a single microservice is deployed to a single instance of JBoss EAP running inside a single container. When deployed this way, multiple threads provide vertical scalability for any given microservice. This topology also allows for multiple JBoss EAP containers fronted by a load balancer. This adds horizontal scalability and high availability. Another possible deployment topology is to run multiple, separately deployed microservices on horizontally scaled and load balanced JBoss EAP instances.

There are many opinions on the right and wrong way to deploy microservices. There are no hard and fast rules. Therefore if you want to deploy one microservice per application container instance, you can. If you are comfortable with each deployed microservice logically separated, but executing in the same application container instance, you are also correct. Ultimately, the selection of what deployment pattern to use comes down to customer preference and adherence to deployment standards that make sense.

For all the aforementioned deployment options, developers can take advantage of JBoss EAP modularity to minimize the server resource footprint as discussed earlier. Looking forward, the open source project WildFly Swarm is exploring the concept of uberjars. Microservices can be deployed using a just-enough application server to support whatever subset of traditional Java EE APIs an application deploys as a single jar file. While there are no guarantees this functionality will be part of a future JBoss EAP release, it is an example of innovation that takes place in the JBoss upstream open source community projects.

Pivotal and 12-factor applications

Pivotal does not offer a Java EE certified application platform. However, it does offer technology, through the Spring framework, for creating and deploying 12-factor applications which Pivotal also calls microservices. Once created, Spring framework applications can be deployed on multiple types of on-premise environments such as the Pivotal tcServer and even JBoss EAP. Vertical and horizontal load balancing would also need to be decided and implemented using on-premise options.

More commonly, Pivotal recommends creating Spring framework based microservices that run in Cloud Foundry. But even in this case, developers will not find a full Java EE environment available if needed. Instead, developers using Pivotal are required to create microservices using only one of the supported application types: Spring Boot, Spring, Java Web, and Java standalone. The common thread is 12-factor application design, using Spring framework modules, and executing on Cloud Foundry. Pivotal encourages development concepts such as 12-factor applications, continuous integration and deployment, and containers, all of which are also available using JBoss EAP and OpenShift by Red Hat. However, a significant but understated difference between Red Hat is that Pivotal is forcing Java developers to learn and embrace specific non-Java EE approaches to creating applications. Red Hat is offering Java EE developers a way to use the skills they have, and optionally migrate new development to emerging architectural patterns. Red Hat is offering an evolutionary approach. Pivotal arguably is offering a revolutionary approach and a riskier path to take.

Liberty Profile and Microservices

IBM technically can run microservices on either the traditional WebSphere Application Server or the more recent WebSphere Liberty Profile Java EE application platforms. However, given the lack of modularity in traditional WebSphere Application Server that leads to heavy resources requirements, it is not the best choice for microservice deployment.

IBM blogs and presentations commonly discuss microservices within the context of deployment using WebSphere Liberty Profile. Like JBoss EAP, WebSphere Liberty Profile offers  modularity to control the application platform footprint. Like JBoss EAP, developers have a choice of microservice deployment options that offer vertical and horizontal scaling plus failover advantages.

Ultimately, both JBoss EAP and WebSphere Liberty Profile both can be used as a Java EE application platform for microservices. However, organizations that use microservices both on-premise and in the cloud will need to negotiate different entitlements for use with IBM. In addition, existing on-premise WebSphere Liberty customers will find that their entitlements are not readily transferrable to cloud entitlements.

WebLogic, Microservices, and Resource Constraints

Oracle WebLogic Server is similar to JBoss EAP insofar that both can be used as a Java EE application platform for microservices. Like JBoss EAP, developers have a choice of microservice deployment options that offer vertical and horizontal scaling plus failover advantages. However, the lack of modularity to tune the Oracle WebLogic server resource footprint can limit the density of WebLogic instances that can be achieved on any given computing resource. Resources such as memory and CPU are typically not unlimited, and the more microservice deployments you have on Oracle WebLogic instances, the more resources you need. The resource requirements for Oracle WebLogic simply grow faster than the same type of deployment using JBoss EAP. Even more so when the JBoss EAP modularity advantages of Oracle WebLogic are taken advantage of.

Comments are closed.