With this article, our intention is to illustrate that microservices are a valid option for Java/Jakarta EE developers with the help of Payara.
Nowadays, the concept of microservices is more than a simple novelty. With the advent of DevOps and the boom of container technologies and deployment automation tools, microservices are changing the way developers structure their applications. With this article, our intention is to illustrate that microservices are a valid option for Java/Jakarta EE developers and how Payara Micro is a robust platform to reach that goal.
The main purpose of a microservice architecture is to break down an application into smaller standalone components that are easier to handle, deploy, scale and maintain in the long term. Sounds familiar? Yes, this is something that many developers have been doing since a long time ago! Encapsulation, cohesion and a good understanding of service-oriented architectures have helped them apply this “divide and conquer” strategy to software architecture for many years and will do so in the future as well.
So, what’s the advantage of a microservice architecture, then? Microservices are better understood when compared with their traditional counterparts: monolithic applications. Monolithic applications, or monoliths, are usually big enterprise applications structured into a single deployable package. If you want to introduce a new component or update an existing one, the entire monolith must be updated at once. This is the way enterprise applications were usually developed, focusing on the concept of tiers (UI, middleware-services, persistence, data) and the segregation of concerns across these tiers.
So, while a monolith is just a normal application developed with traditional means, the microservice architecture approach would be to break down such an application into its separate component units (or just services), so that each unit would fulfill the following criteria:
So, does that mean that microservices should be used instead of the traditional monolith in all cases? Not necessarily. Microservices not only define a new architectural style, but also require that development teams build applications in a different manner.
There are also some advantages and disadvantages regarding when to use a monolith and when to use microservices: (Considered advantages are green, disadvantages are red, orange is for variable benefits depending on the software requirements or the organization’s environment.)
MonolithsMicroservicesCost of changes across all tiers is high. A change of a single feature means a redeployment of the whole unit. Changes are easier to implement and not costly as they are targeted to specific services only. All components belong to a single unit, there’s no communication overhead. Remote calls are needed for communication between services, so this overhead factors in the performance of the overall application. The entire development team must be familiarized with the design and composition of the entire application. Each service can be handled by a separate team, so this favors separation of concerns and responsibilities. Developed with a technological stack in mind, using one or two languages of choice. A main language/framework is chosen to govern the software architecture. Each service can be developed using a different framework based on its requirements and needs. Standards are discarded in favor of improving each service with the right tools. Easier to deploy. The complexity of deployment increases with the number of services and the communication routes between them. Clustering can be as easy or difficult depending on all the features implemented across the monolith. Since each micro-service is small, clustering is generally easy, with scalability being a primary drive. Failure of a component can cause the entire application to fail and hinder the user experience. Failure of a service will only bring that specific service down, leaving other services untouched. There’s a focus on tiers and integration across tiers. There’s a focus on business needs and communication concerns between teams.
Microservices can help an organization develop their applications in such structured way. But sometimes, when applications are not critical to their business, or their quality attributes (performance, availability, scalability, security, etc.) are not specifically demanding, the traditional monolithic approach is more than enough.
The Java EE 8 set of specifications allows the creation of monolithic applications with ease. The main benefit of being a Java EE developer is that you don’t have to worry about handling technical concerns like network handling, transaction management or a resource’s lifecycle when the specific container service does that for you. This simplifies the developers' work allowing them to focus on business concerns instead.
In the case of Java EE, a monolithic application’s example could be an e-commerce application with the following characteristics:
Sounds complex? Yes. The previous scenario was a common occurrence in earlier Java EE days, but nowadays, with tools like Maven or OSGi, modularizing Java EE application has simplified the development of monoliths on Java EE, meaning that your entire application can be deployed in a single WAR file. However, if you would like to implement this e-commerce application as a set of microservices, a simple WAR will not be enough.
There are no technology restrictions that prevent you to create microservices using the Java EE APIs via an application server like GlassFish (and Payara Server by extension). However, there are some considerations to have in mind:
What is OpenJDK? OpenJDk or Open Java Development Kit is a free, open-source framework of the Java Platform, Standard Edition (or Java SE).
Companies need to be thinking long-term before even starting a software development project. These needs are solved at the level of architecture: business owners want to assure agility, scalability, and performance.
The MicroProfile project defines a programming model for developing microservice applications in an Enterprise Java environment.
In this article, take a look at the service mesh in the microservices world. The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.
In this short video I demonstrate how to use MicroProfile OpenTracing with Jaeger in combination with Payara Micro.