AWS Architect Certification Training
- 69k Enrolled Learners
- Live Class
Organizations are quickly moving towards Microservices architecture & hunting for professionals with Microservices Certification. I hope that you have read my previous blog on What is Microservices that explains the architecture, compares microservices with monolithic and SOA, and also explores when to use microservices with the help of use-cases.
In this Microservices tutorial, the following topics will be covered:
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 in different languages. Like many other companies mediamore started its journey with a monolithic architecture.
Let us now explore the monolithic framework of mediamore.
Figure 1: Monolithic Architecture of Mediamore – Microservices Tutorial
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.
Scenario 1: Scalability: Let’s assume that the developers want to update the playlist according to most popular tv shows and also 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 JAVA, C++,.NET, 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?
Here lies the million dollar question!
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 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.
Figure 2: Beehive Representation of Microservices – Microservices Tutorial
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.
Refer to the below diagram.
Figure 3: Microservices Architecture – Microservices Tutorial
Let me now brief you on how these components work together on mediamore by considering a scenario.
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. 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.
Figure 4: Microservices Architecture of Mediamore – Microservices Tutorial
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.
Figure 5: Division of Teams of Mediamore – Microservices Tutorial
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 i.e. 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 each other?
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.
Figure 6: Communication Between Microservices – Microservices Tutorial
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.
Figure 7: Representation of how to search operation is performed with the help of API – Microservices Tutorial
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.
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 down 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.
ApplicationConfiguration.java – Research configuration class responsible for exposing REST services for application users.
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 2 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, 3 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 i.e. Microservices using SpringBoot. Stay tuned!
If you wish to learn Microservices and build your own applications, then check out our Microservices Architecture Training which comes with instructor-led live training and real-life project experience. This training will help you understand Microservices in depth and help you achieve mastery over the subject.
Got a question for us? Please mention it in the comments section of ” Microservice Tutorial” and I will get back to you.