Have you ever wondered what it takes to refactor an existing Java EE monolithic application to a microservices-based one?
This blog explains how a trivial shopping cart example was converted to microservices-based application, and what are some of the concerns around it. The complete code base for monolithic and microservices-based application is at: github.com/arun-gupta/microservices.
Read on for full glory!
Java EE Monolith
A Java EE monolithic application is typically defined as a WAR or an EAR archive. The entire functionality for the application is packaged in a single unit. For example, an online shopping cart may consist of User, Catalog, and Order functionalities. All web pages are in root of the application, all corresponding Java classes are in the `WEB-INF/classes` directory, resources in `WEB-INF/classes/META-INF` directory.
Lets assume that your monolith is not designed as a distributed big ball of mud and the application is built following good software architecture. Some of the common rules are:
- Separation of concerns, possibly using Model-View-Controller
- High cohesion and low coupling using well-defined APIs
- Don’t Repeat Yourself (DRY)
- Interfaces/APIs and implementations are separate, and following Law of Demeter. Classes don’t call other classes directly because they happen to be in the same archive
- Using Domain Driven Design to keep objects related to a domain/component together
- YAGNI or You Aren’t Going to Need It: Don’t build something that you don’t need now
Here is how a trivial shopping cart monolithic WAR archive might look like:
This monolithic application has:
- Classes for the three components are in separate packages in `WEB-INF/classes` directory. Any utility/common classes used by multiple classes are packed here as well.
- Configuration files for each component are packaged in`WEB-INF/classes/META-INF` directory. Any config files for the application, such as `persistence.xml` and `load.sql` to connect and populate the data store respectively, are also packaged here.
It has the usual advantages of well-known architecture, IDE-friendly, easy sharing, simplified testing, easy deployment, and others. But also comes with disadvantages such as limited agility, obstacle for continuous delivery, “stuck” with a technology stack, growing technical debt, and others.
Even though microservices are all the rage these days, monoliths are not bad. Even those that are not working for you may not benefit much, or immediately, from moving to microservices. Other approaches, such as just better software engineering and architecture, may help. Microservices is neither a free lunch or a silver bullet and requires significant investment to be successful such as service discovery, service replication, service monitoring, containers, PaaS, resiliency, and a lot more.
don’t even consider microservices unless you have a system that’s too complex to manage as a monolith.
Microservice Architecture for Java EE
Alright, I’ve heard about all of that but would like to see a before/after, i.e. how a monolith code base and how a refactored microservice codebase looks like.
First, lets look at the overall architecture:
The key pieces in this architecture are:
- Application should be functionally decomposed where User, Order, and Catalog components are packaged as separate WAR files. Each WAR file should have the relevant web pages (#15), classes, and configuration files required for that component.
- Java EE is used to implement each component but there is no long term commitment to the stack as different components talk to each other using a well-defined API (#14).
- Different classes in this component belong to the same domain and so the code is easier to write and maintain. The underlying stack can also change, possibly keeping technical debt to a minimum.
- Each archive has its own database, i.e. no sharing of data stores. This allows each microservice to evolve and choose whatever type of datastore – relational, NoSQL, flat file, in-memory or some thing else – is most appropriate.
- Each component will register with a Service Registry. This is required because multiple stateless instances of each service might be running at a given time and their exact endpoint location will be known only at the runtime (#17). Netflix Eureka, Etcd, and Zookeeper are some options in this space (more details).
- If components need to talk to each other, which is quite common, then they would do so using a pre-defined API. REST for synchronous or Pub/Sub for asynchronous communication are the common means to achieve this. In our case, Order component discovers User and Catalog service and talks to them using REST API.
This application is fairly trivial but at least highlights some basic architectural differences.
Monolith vs Microservices
Some of the statistics for the monolith and microservices-based applications are compared below:
|Number of archives||1|| 5
|Web pages||8||8 (see below)|
|Configuration Files|| 4
|| 3 per archive
|Total archive size||24 KB||~52 KB (total)|
Code base for the monolithic application is at: github.com/arun-gupta/microservices/tree/master/monolith/everest
Code base for the microservices-enabled application is at: github.com/arun-gupta/microservices/tree/master/microservice
Issues and TODOs
Here are the issues encountered, and TODOs, during refactoring of the monolith to a microservices-based application:
- Java EE already enables functional decomposition of an application using EAR packaging. Each component of an application can be packaged as a WAR file and be bundled within an EAR file. They can even share resources that way. Now that is not a true microservices way, but this could be an interim step to get you started. However, be aware that ‘@FlowScoped’ bean is not activated in an EAR correctly (WFLY-4565).
- Extract all template files using JSF Resource Library Templates.
- Breakup monolithic database into multiple databases require separate ‘persistence.xml’ and DDL/DML scripts for each application. Similarly, migration scripts, such as using Flyway, would need to be created accordingly.
- A REST interface for all components, that need to be accessed by another one, had to be created.
- UI is still in a single web application. This should instead be included in the decomposed WAR (#15) and then composed again in the dumb proxy. Does that smell like portlets?
- Deploy the multiple WAR files in a PaaS (#12)
- Each microservice should be easily deployable in a container (#6)
Here is the complete list of classes for the monolithic application:
./target/classes/org/javaee7/wildfly/samples/everest/cart/Cart.class ./target/classes/org/javaee7/wildfly/samples/everest/cart/CartItem.class ./target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogItem.class ./target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogItemBean.class ./target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogItemType.class ./target/classes/org/javaee7/wildfly/samples/everest/checkout/Order.class ./target/classes/org/javaee7/wildfly/samples/everest/checkout/OrderBean.class ./target/classes/org/javaee7/wildfly/samples/everest/checkout/OrderItem.class ./target/classes/org/javaee7/wildfly/samples/everest/checkout/Shipping.class ./target/classes/org/javaee7/wildfly/samples/everest/uzer/Uzer.class ./target/classes/org/javaee7/wildfly/samples/everest/uzer/UzerBean.class ./target/classes/org/javaee7/wildfly/samples/everest/uzer/UzerItem.class
Here is the complete list of classes for the microservices-based application:
./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/ApplicationConfig.class ./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogItem.class ./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogItemREST.class ./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogItemType.class ./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/ServiceRegistration.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/cart/Cart.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/cart/CartItem.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogBean.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/catalog/CatalogItem.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/Order.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/OrderBean.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/OrderItem.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/Shipping.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/ServiceDiscovery.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/ServiceDiscoveryStatic.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/ServiceDiscoveryURI.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/ServiceDiscoveryZooKeeper.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/uzer/UzerBean.class ./everest/target/classes/org/javaee7/wildfly/samples/everest/uzer/UzerItem.class ./order/target/classes/org/javaee7/wildfly/samples/everest/order/ApplicationConfig.class ./order/target/classes/org/javaee7/wildfly/samples/everest/order/Order.class ./order/target/classes/org/javaee7/wildfly/samples/everest/order/OrderItem.class ./order/target/classes/org/javaee7/wildfly/samples/everest/order/OrderREST.class ./user/target/classes/org/javaee7/wildfly/samples/everest/uzer/ApplicationConfig.class ./user/target/classes/org/javaee7/wildfly/samples/everest/uzer/UserREST.class ./user/target/classes/org/javaee7/wildfly/samples/everest/uzer/Uzer.class
Once again, the complete code base is at github.com/arun-gupta/microservices.
Some of the future topics in this series would be:
- Are containers required for microservices?
- How do I deploy multiple microservices using containers?
- How can all these services be easily monitored?
- A/B Testing
- Continuous Deployment using microservices and containers
What else would you like to see?