Microservice Architecture:

From my previous blog, you must have got a basic understanding of Microservice Architecture. But, being a professional with certified expertise in Microservices will require more than just the basics. In this blog, you will get into the depth of the architectural concepts and implement them using an UBER-case study.

In this blog, you will learn about the following:

Definition Of Microservice Architecture

Key Concepts Of Microservice Architecture

Pros And Cons Of Microservice Architecture

UBER – Case Study

You can refer to the What is Microservices, to understand the fundamentals and benefits of Microservices.

It will only be fair if I give you the definition of Microservices.

Definition Of Microservices

As such, there is no proper definition of Microservices aka Microservice Architecture, but you can say that it is a framework which consists of small, individually deployable services performing different operations.

Microservices focus on a single business domain that can be implemented as fully independent deployable services and implement them on different technology stacks.

Refer to the diagram above to understand the difference between monolithic and microservice architecture. For a better understanding of differences between both the architectures, you can refer to my previous blog What Is Microservices

To make you understand better, let me tell you some key concepts of microservice architecture.

Key Concepts Of Microservice Architecture

Before you start building your own applications using microservices you need to be clear about the scope, and functionalities of your application.

Following are some guidelines to be followed while discussing microservices.

Guidelines While Designing Microservices

As a developer, when you decide to build an application separate the domains and be clear with the functionalities.

Each microservice you design shall concentrate only on one service of the application.

Ensure that you have designed the application in such a way that each service is individually deployable.

Make sure that the communication between microservices is done via a stateless server.

Each service can be furthered refactored into smaller services, having their own microservices.

Now, that you have read through the basic guidelines while designing microservices, let’s understand the architecture of microservices.

How Does Microservice Architecture Work?

A typical Microservice Architecture (MSA) should consist of the following components:

Clients

Identity Providers

API Gateway

Messaging Formats

Databases

Static Content

Management

Service Discovery

Refer to the diagram below.

Figure 2: Architecture Of Microservices – Microservice Architecture

I know the architecture looks a bit complex, but let me simplify it for you.

1. Clients

The architecture starts with different types of clients, from different devices trying to perform various management capabilities such as search, build, configure etc.

2. Identity Providers

These requests from the clients are then passed on the identity providers who authenticate the requests of clients and communicate the requests to API Gateway. The requests are then communicated to the internal services via well-defined API Gateway.

3. API Gateway

Since clients don’t call the services directly, API Gateway acts as an entry point for the clients to forward requests to appropriate microservices.

After receiving the requests of clients, the internal architecture consists of microservices which communicate with each other through messages to handle client requests.

4. Messaging Formats

There are two types of messages through which they communicate:

Synchronous Messages: In the situation where clients wait for the responses from a service, Microservices usually tend to use REST (Representational State Transfer) as it relies on a stateless, client-server, and the HTTP protocol. This protocol is used as it is a distributed environment each and every functionality is represented with a resource to carry out operations

Asynchronous Messages: In the situation where clients do not wait for the responses from a service, Microservices usually tend to use protocols such as AMQP, STOMP, MQTT. These protocols are used in this type of communication since the nature of messages is defined and these messages have to be interoperable between implementations.

The next question that may come to your mind is how do the applications using Microservices handle their data?

5. Data Handling

Well, each Microservice owns a private database to capture their data and implement the respective business functionality.Also, the databases of Microservices are updated through their service API only. Refer to the diagram below:

The services provided by Microservices are carried forward to any remote service which supports inter-process communication for different technology stacks.

6. Static Content

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).

Apart from the above components, there are some other components appear in a typical Microservices Architecture:

7. Management

This component is responsible for balancing the services on nodes and identifying failures.

8. Service Discovery

Acts as a guide to Microservices to find the route of communication between them as it maintains a list of services on which nodes are located.

Subscribe to our youtube channel to get new updates..!

Now, let’s look into the pros and cons of this architecture to gain a better understanding of when to use this architecture.

Pros and Cons of Microservice Architecture

Refer to the table below.

Pros Of Microservice Architecture

Cons Of Microservice Architecture

Freedom to use different technologies

Increases troubleshooting challenges

Each microservice focuses on single business capability

Increases delay due to remote calls

Supports individual deployable units

Increased efforts for configuration and other operations

Allows frequent software releases

Difficult to maintain transaction safety

Ensures security of each service

Tough to track data across various service boundaries

Multiple services are parallelly developed and deployed

Difficult to move code between services

Let us understand more about Microservices by comparing UBER’s previous architecture to the present one.

UBER CASE STUDY

UBER’s Previous Architecture

Like many startups, UBER began its journey with a monolithic architecture built for a single offering in a single city. Having one codebase seemed cleaned at that time, and solved UBER’s core business problems. However, as UBER started expanding worldwide they rigorously faced various problems with respect to scalability and continuous integration.

Figure 4: Monolithic Architecture Of UBER – Microservice Architecture

The above diagram depicts UBER’s previous architecture.

A REST API is present with which the passenger and driver connect.

Three different adapters are used with API within them, to perform actions such as billing, payments, sending emails/messages that we see when we book a cab.

A MySQL database to store all their data.

So, if you notice here all the features such as passenger management, billing, notification features, payments, trip management and driver management were composed within a single framework.

Problem Statement

While UBER started expanding worldwide this kind of framework introduced various challenges. The following are some of the prominent challenges

All the features had to be re-built, deployed and tested again and again to update a single feature.

Fixing bugs became extremely difficult in a single repository as developers had to change the code again and again.

Scaling the features simultaneously with the introduction of new features worldwide was quite tough to be handled together.

Solution

To avoid such problems UBER decided to change its architecture and follow the other hyper-growth companies like Amazon, Netflix, Twitter and many others. Thus, UBER decided to break its monolithic architecture into multiple codebases to form a microservice architecture.

Refer to the diagram below to look at UBER’s microservice architecture.

The major change that we observe here is the introduction of API Gateway through which all the drivers and passengers are connected. From the API Gateway, all the internal points are connected such as passenger management, driver management, trip management and others.

For Example: If you want to change anything in the billing Microservices, then you just have to deploy only billing Microservices and don’t have to deploy the others.

All the features were now scaled individually i.e. The interdependency between each and every feature was removed.

For Example, we all know that the number of people searching for cabs is more comparatively more than the people actually booking a cab and making payments. This gets us an inference that the number of processes working on the passenger management microservice is more than the number of processes working on payments.

In this way, UBER benefited by shifting its architecture from monolithic to Microservices.

I hope you have enjoyed reading this post on Microservice Architecture. I will be coming up with more blogs, which will contain hands-on as well.

Interested In Learning More About Microservices?

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 Architecture” and I will get back to you.