This microservices tutorial is the third part in this microservices blog series. I hope that you have read my previous blog, What is Microservices, which explains the architecture, compares microservices with monoliths and SOA, and explores when to use microservices with the help of use cases.

Let us explore the concepts of microservices through a use-case on Mediamore.com.

Mediamore is an entertainment company which provides streaming media and videos online. It consists of various genres of TV Shows with different languages. Like many other companies Mediamore started its journey with a monolithic architecture.

Let us now explore the monolithic framework of Mediamore.

Monolithic Architecture

Monolithic Architecture of Mediamore.

Refer to the above diagram. We can infer that all the features, such as the search, user-info, recommendations, video playlist and others are put on a single database using single code.

Now, let me tell you the challenges faced by the developers while using a monolithic framework by using some scenarios.

Challenges of Monolithic Architecture

Scenario 1: Scalability

Let's assume that the developers want to update the playlist according to the most popular TV shows and simultaneously want to update all videos to HD quality. The developers cannot scale the application simultaneously. New instances of the same application have to be created every time a new feature has to be developed or deployed.

Scenario 2: Agility

Assume that developers want to make immediate changes in the application. The monolithic application can definitely accommodate these changes. But, the problem here is that the developers have to rebuild the code for every small change.

Scenario 3: Hybrid Technologies

Suppose developers of this application are comfortable with various technologies like Jaca, C++, .NET, and C#. Even though they are comfortable with various technologies, they still have to build large and complex applications on a single technology.

Scenario 4: Fault Tolerance

Let's suppose that a specific feature is not working in the application. The complete system goes down because of this problem. In order to tackle this problem, the application has to be re-built, re-tested and also re-deployed.

So, how did the developers of Mediamore overcome these complexities? Developers decided to re-architect their monolithic application into multiple individual deployable components, called microservices.

Here lies the million dollar question!

What Are Microservices?

Microservices is an architecture wherein all the components of the system are put into individual components, which can be built, deployed, and scaled individually.

Let me explain it to you with a simple analogy.

You must have seen how bees build their honeycomb by aligning hexagonal wax cells. They initially start with a small section using various materials and continue to build a large beehive out of it. These cells form a pattern resulting in a strong structure which holds together a particular section of the beehive. Here, each cell is independent of the other but it is also correlated with the other cells. This means that damage to one cell does not damage the other cells, so, bees can reconstruct these cells without impacting the complete beehive.

Beehive Representation of Microservices.

Refer to the above diagram. Here, each hexagonal shape represents an individual service component. Similar to the working of bees, each agile team builds an individual service component with the available frameworks and the chosen technology stack. Just as in a beehive, each service component forms a strong microservice architecture to provide better scalability. Also, issues with each service component can be handled individually by the agile team with no or minimal impact on the entire application.

The next question that may come to your mind is how do the different components of microservice architecture work together.

But, before that, let me list down the components of the microservice architecture.

Remote Service - Enables the remote access information that resides on a network of IT devices.

Let me now brief you on how these components work together at Mediamore by considering a scenario.

Microservice Architecture

Alice is an avid user of Mediamore. She uses Mediamore regularly to watch her favorite series online. She recently missed watching an episode of her favorite TV show.

When Alice logs in to the application, she sees the most recommended content on her home page. After some searching, she finally finds her TV show.

But, what if Alice wants to get her TV show with a single click? How will the developers work together to fulfill Alice's request?

Alice's request is passed on to the Identity Provider. The identity provider thus authenticates Alice's request by identifying her as a regular user on Mediamore.

These requests are passed to the API Gateway which acts as an entry point for Alice to forward her requests to the appropriate microservices.

Each feature has its own working microservice, handling their own data. These microservices also have their own load balancers and execution environments to function properly.

Microservices Architecture of Mediamore.

Refer to the diagram below. Each microservice is handled by a small agile team such as content team, video uploading team, most trending team, search team, etc.

Division of teams at Mediamore.

The content team consists of millions of TV shows that the application provides.

The video uploading team have the responsibility to upload all the content into the application

The most trending team houses the most trending shows according to the geographical location of users and so on.

These small teams of developers relate each and every piece of content with the metadata that describes the searched content. Then, metadata is fed into another microservice i.e. the search function which ensures Alice's search results are captures into the content catalog.

Then, the third microservice, the most trending microservice, captures the trending content among all the Mediamore users according to their geographical locations.

The content from this microservice is what Alice sees when she first logs into Mediamore.

These individually deployable microservices are put in specific containers to join the application. Containers are used to deliver the code to the sector where deployment is required.

But before they join the application to work together, they have to find each other to fulfil Alice's request.

How Do These Microservices Find One Another?

Microservices use service discovery which acts as a guide to find the route of communication between each of them. Microservices then communicate with each other via a stateless server i.e. either by HTTP Request/Message Bus.

Communication between microservices.

These microservices communicate with each other using an Application Program Interface(API). After the Microservices communicate within themselves, they deploy the static content to a cloud-based storage service that can deliver them directly to the clients via Content Delivery Networks (CDNs).

So, when Alice searches for her TV Show, the search microservice communicates with the content catalog service in API about what is Alice searching for and then these microservices compare the typed words with the metadata they already have.

Representation of how the search operation is performed with the help of APIs.

Once the teams of developers capture the most typed words by Alice, the analytics team update the code in recommendations microservice and compare Alice's most viewed content and preferences to popular content among other users in the same geographical region.

This means that the next time Alice logs on to the application, she not only sees the most popular content but also finds a personalized playlist which contains the shows she has previously viewed.

In this way, Alice's request is fulfilled by the development team in a quick manner as they did not have to build the complete application again and just had to update the code to deploy this new functionality.

So this way microservices invoke parallel environments to satisfy millions of customers with varying interests.

Now in this microservices tutorial, my next section will focus on hands-on.

To demonstrate the concepts of microservices, I have created 3 Maven Projects called as Doctor_Microservice_Edureka, Diagnosis_Microservice_Edureka, and Patient_Microservice_Edureka using Spring Boot.

Refer to the snapshot below.

Before you understand how these 3 projects interact with each other. Let me brief you on the files of these projects.

To explain this, I will consider the project Patient_Microservice_Edureka and list its basic files.

Refer to the snapshot below.

Pom.xml - Dependencies are added for the creation of REST services.

Application.java - Identical class in all three projects. Acts as an initiator to Spring Boot.

Patient.java - A simple class consisting of input such as the patient's name, id, email.

PatientRest.java - Starts the implementation of the REST services in the project.

In this way, similar files are created for the other two projects with some additional files in Doctor_Microservice.

REST services are thus created to search patients and the diagnosis. Keys of patient and diagnosis are passed as a parameter to a method(PatientDetails) in Doctor_Microservice.This method gets the data of the patients and diseases.

Refer to the snapshot above. Here, we observe that Patient and Diagnosis classes are included in Doctor_Microservice_Edureka. These classes are cloned from their original projects.

Then to start the REST services, I have initialized Patient_Microservice_Edureka on port 8081, Diagnosis_Microservice_Edureka on 8082 and the Doctor_Microservice_Edureka on port 8083.

With the above configurations, when I run each service simultaneously, 3 different console windows run in the Eclipse console window.

As you can see below that after we run the projects, Spring Boot generates a boot log. This log consists information on initializing tomcat and its associated resources. The last line of the log indicates us whether our application has started or not.

To test if the patient and diagnosis services are functioning properly, one a browser (Mozilla Firefox) and go to http://localhost:8081/ and http://localhost:8082/ URLs. You should get the outputs as shown below:

Finally, to test the functionality of the Doctor_Microservice_Edureka, I simulated the information of the patient with id 2, suffering from a disease of id 3 and consulting a doctor with consultation 4.

The URL used is as follows: http://localhost:8083/doctor?idPatient=2&idDiagnosis=3&consultation=4

Refer to the snapshot below for the output.

In this way, three microservices interact with each other to produce the desired results.

I hope you have enjoyed reading this microservices tutorial. We have seen a simple example to understand how different microservices communicate with each other.

If you want the source code of the example shown, please comment out in the comments section.

After this Microservices Tutorial, we will be getting into the depth of practical implementations on microservices with the next blog, Microservices using Spring Boot. Stay tuned!