Microservice Architecture — Explore UBER’s Microservice Architecture
From my previous article, you must have got a basic understanding of Microservice Architecture. In this blog, you will get into the depth of the architectural concepts and implement them using an UBER-case study.
In this article, you will learn about the following:
- Definition Of Microservice Architecture
- Key Concepts Of Microservice Architecture
- Pros And Cons Of Microservice Architecture
- UBER — Case Study
Before I talk about the UBER’S Microservices Architecture, 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.
The 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.
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 to 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 a 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.
The advantages of using an API gateway include:
- All the services can be updated without the clients knowing.
- Services can also use messaging protocols that are not web-friendly.
- The API Gateway can perform cross-cutting functions such as providing security, load balancing, etc.
After receiving the requests of clients, the internal architecture consists of microservices that 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.
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.
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 the scalability and continuous integration.
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.
- The units are individual separate deployable units performing separate functionalities.
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. If you wish to check out more articles on the market’s most trending technologies like Artificial Intelligence, DevOps, Ethical Hacking, then you can refer to Edureka’s official site.
Do look out for other articles in this series which will explain the various other aspects of Microservices.
2. Microservices Design Patterns
Originally published at www.edureka.co on February 27, 2018.
