Microservices examples

There is no one size fits all approach when implementing microservices. In this section, different examples are analyzed to crystalize the microservices concept.

An example of a holiday portal

In the first example, we will review a holiday portal--Fly By Points. Fly By Points collects points that are accumulated when a customer books a hotel, flight, or car through their online website. When a customer logs in to the Fly By Points website, they will be able to see the points accumulated, personalized offers that can be availed by redeeming the points, and upcoming trips, if any:

Let's assume that the preceding page is the home page after login. There are 2 upcoming trips for Jeo, 4 personalized offers, and 21123 points. When the user clicks on each of the boxes, details will be queried and displayed.

Holiday portal has a Java, Spring-based traditional monolithic application architecture, as follows:

As shown in the preceding diagram, Holiday portal's architecture is web-based and modular with clear separation between layers. Following the usual practice, Holiday portal is also deployed as a single war file deployed on a web server such as Tomcat. Data is stored in an all encompassing backing relational database. This is a good fit for the purposes of architecture when the complexities are less. As the business grows, the user base expands and the complexity also increases.

This results in a proportional increase in the transaction volumes. At this point, enterprises should look for rearchitecting the monolithic application to microservices for better speed of delivery, agility, and manageability:

Upon examining the simple microservices version of this application, we will immediately see a few things in this architecture:

• Each subsystem has now become an independent system by itself--a microservice. There are three microservices representing three business functions--Trips, Offers, and Points. Each one has its internal data store and middle layer. The internal structure of each service remains the same.
• Each service encapsulates its own database as well as its own HTTP listener. As opposed to the previous model, there is no web server and there is no war. Instead, each service has its own embedded HTTP listener, such as Jetty, Tomcat, and more.
• Each microservice exposes a rest service to manipulate the resources/entities that belong to that service.

It is assumed that the presentation layer is developed using a client-side JavaScript MVC framework, such as Angular JS. These client-side frameworks are capable of invoking REST calls directly.

When the web page is loaded, all three boxes, Trips, Offers, and Points, will be displayed with details such as points, number of offers, and number of trips. This will be done by each box independently making asynchronous calls to the respective backend microservices using REST. There is no dependency between the services at the service layer. When the user clicks on any of the boxes, the screen will be transitioned and will load the details of the clicked item. This will be done by making another call to the respective microservice.    

An example of a travel agent portal

This third example is a simple travel agent portal application. In this example, we will see both synchronous REST calls as well as asynchronous events.

In this case, portal is just a container application with multiple menu items or links in the portal. When specific pages are requested, for example, when the menu is clicked or a link is clicked, they will be loaded from the specific microservices:

The architecture of the Travel Agent Portal backed with multiple microservices is shown as follows: 

When a customer requests a booking, the following events will take place internally:

• The travel agent opens the flight UI, searches for a flight, and identifies the right flight for the customer. Behind the scenes, the flight UI will be loaded from the Flight microservice. The flight UI only interacts with its own backend APIs within the Flight microservice. In this case, it makes a REST call to the Flight microservice to load the flights to be displayed.
• The travel agent then queries the customer details by accessing the customer UI. Similar to the flight UI, the customer UI will be loaded from the Customer microservices. Actions in the customer UI will invoke REST calls on the Customer microservice. In this case, the customer details will be loaded by invoking appropriate APIs on the Customer microservice.
• Then the travel agent checks the visa details to see the eligibility to travel to the selected country. This will also follow the same pattern as mentioned in the previous two points.
• Then the travel agent makes a booking using the booking UI from the Booking microservices, which again follows the same pattern.
• The payment pages will be loaded from the Payment microservice. In general, the payment service will have additional constraints, including the Payment Card Industry Data Security Standard (PCIDSS) compliance, such as protecting and encrypting data in motion and data at rest. The advantage of the microservices approach is that none of the other microservices need to be considered under the purview of PCIDSS as opposed to the monolithic application, where the complete application comes under the governing rules of PCIDSS. Payment also follows the same pattern described earlier.
• Once the booking is submitted, the Booking Service calls the flight service to validate and update the flight booking. This orchestration is defined as a part of the Booking microservices. Intelligence to make a booking is also held within the Booking microservices. As a part of the booking process, it also validates, retrieves, and updates the Customer microservice.
• Finally, the Booking microservice sends a booking event, which the Notification Services picks up, and sends a notification to the customer.

The interesting factor here is that we can change the user interface, logic, and data of a microservice without impacting any other microservices.

This is a clean and neat approach. A number of portal applications could be built by composing different screens from different microservices, especially for different user communities. The over all behavior and navigation will be controlled by the portal application.

The approach has a number of challenges unless the pages are designed with this approach in mind. Note that the site layouts and static contents will be loaded from the Content Management System (CMS) as layout templates. Alternately, this could be stored in a web server. The site layout may have fragments of User Interfaces, which will be loaded from the microservices at runtime.