Microservices in Java: when it is necessary to use
January 17, 2020

Software Development

Monolith vs Microservices in Java

By Olga Matuts

Microservices are the kind of service-oriented architecture that works with heavy-load handling systems and was implemented by such giants as Google, Netflix, Amazon, and eBay. This term appeared in 2011 and is still a subject of interest.

Let’s take a closer look at the definition and characteristics of microservices, as well as the ways how they are applied in Java.

What are microservices?

A microservice architecture relates to service-oriented architecture (SOA) that is used in systems with several independently deployable modules. Microservices differ in the degree of interconnection of modules; they are largely independent and particular. One server always equals to one business process.

Microservices offer an opportunity to use several programming languages and technologies, improve scaling, and reduce the amount of used memory. This is a helpful solution when the server can’t cope with the burden and consumes a lot of memory, or when more than one server is required.

Java is the best option for building microservices as it is a well-known programming language with a great number of appropriated lightweight and easy-to-use frameworks. Developers can use Spring, Spark, Swagger, Jersey, Dropwizard, Play, Restlet, Restx, or other frameworks at will.

Monolith vs microservices on a real-world example

Let’s see how the microservices architecture works in a web store. The system has several tasks: to register users’ profiles, take orders, and send the notification with the status of their order. 

Monolith 

First, let’s consider the case if developers used a monolith architecture in this situation.

There are one server and one database. The system consistently performs all tasks and completes them one by one. Connections between the involved units are implemented with inside-code calls. 

As a result, the sequence of system actions looks like this: security check, user registration, taking orders, sending the order confirmation, and finishing session.

There can be several problems in this case:

  1. Downtimes. If the server is overloaded or part of business logic is not available, the web application can stop. The system can’t proceed to the next step without completing the previous one first. That’s why users won’t get notifications about changes in the status of their orders.
  2. Constraints with updates. Changes of one part of business logic entail rewriting a large part of code. That’s why it can be complicated to add new functions or implement new technologies. To connect an updated version of the app, developers should shut down the current one that leads to the loss of users. Also, there are several important moments: in new parts of code, developers should use the programming language as in the initial system or the language compatible with it.
  3. UX quality. Growing monolith negatively affects the speed of the application that will work slower with every updating or increasing the number of users. It leads to negative feedback and the loss of customers.  

Even if developers duplicate the business logic and share the load between two similar servers with the help of a dynamic balancer, it won’t solve the problems with updating and program shutdown. 

Microservices

Let’s consider how developers can use microservices to build a web application with the same requirements. In this case, every independent server will implement a certain business function and the microservices architecture will consist of two steps.

1.Split the web application into microservices

Developers should single out independent microservices to deploy and maintain. In the case with a web application store, there are 3 servers that work with orders, 2 servers that are for user profiles, and 1 server that deals with notifications. The sync HTTP/REST or async AMQP protocols are used for communication between microservices.

  1. Ensure uninterrupted communication between components

This process requires the implementation of several frameworks and libraries.

First comes the realization of the gateway for the processing of customers’ requests. The gateway also deals with authentication and security, makes servers scalable and independent in deployment. The client side is free from storing server addresses. 

After the gateway realization, it is the turn of the Zuul 2 framework. This framework makes it possible to use the profits of non-blocking HTTP calls.

Then let’s move on to the implementation of the Eureka server as a server discovery which will establish connections between users’ profiles and the order server. The Ribbon load balancer will work as a backup of a system and guarantee the most efficient usage of scaled users profile servers.

Hystrix, a latency and fault tolerance library, is necessary when the server is down or overloaded. In this case, the Hystrix library avoids requests from going into the void while the server is recovering.

For async messaging between the notification server and other servers, developers can use the message broker RabbitMQ.

Let’s check, what is going with problems that were detected in a monolith architecture of web application:

  • Downtimes

Now several independent servers ensure the work of the web application, and there is no serious problem visible for a client, such as slow preloading or system crushing. The system can redirect the requests or continue the work after the server is recovered.

  • Constraints with updates

Developers shouldn’t rewrite the entire system anymore. All parts of business logic are independent. It is enough to modify the necessary servers to add new functions, and the rest will remain unchanged. 

  • UX quality

Internal system processes remain invisible for clients because independent servers can scale. Developers can add new or scale available servers if it is needed, as well as modify several secondary functions if they work slowly.  

Microservices are very useful for building complex web applications with multiple functions. This approach helps developers to avoid problems with loading and scaling, but excessive use of splitting can lead to negative consequences. That’s why to avoid any problems with the app implementation, it makes sense to turn to specialists in software development.

We use cookies to personalize our service and to improve your experience on the website and its subdomains. We also use this information for analytics.

Got it!