Microservices Architecture

Today we will be learning about Microservice Architecture. Before I start with this article, let’s see about the previous system which was the monolithic architecture followed by its challenges, then we’ll jump on to the functionalities of micro-services and the best practices to design them. We will go through a real-life, use case of uber and understand them better.

What do you think monolithic architecture was?

I could say that it was like a big container where all the software components of an application were tightly packed together. Have you got any idea

• how the applications on this framework worked?
• how they looked like how they performed?
• how they communicated with each other?

Let’s look at the client-server model shown here what do you see as a user when you open a web UI you just see your website
but behind the scenes the server-side application has different features which have to be handled together feature such as handling HTTP requests retrieving and
updating the data from database and executing a domain-specific logic were
put on a single framework so if any one feature of the server-side applications
had not worked and the complete system would go down also
if only any one feature had to be updated then the complete system had to be built again
now let’s understand more about monolithic architecture by using a shopping cart application for reference as a user when you open a shopping cart application what all do you see you see different features for handling wish list new labels new brands in the markets customer services and so on.

but if the developers of this framework had decided to build this application on a single framework then all the features were put together on a single database. This not only created problems for scalability but also for fault tolerance and agility.

Let’s understand these challenges one by one specifically the first challenge that is agility let us consider an asset management industry.

Here different clients come with different investments who have to be offered different services so if any new services had to be given to any new clients or any new changes had to be made do you think one of the thing I could accommodate these changes well I would say it definitely could but yes there’s a problem here. The problem is here it could accommodate the changes but are the cost of reduced agility.

why do you think this happened this happened because even if a small
component in an application had to be changed the entire application had to be repackaged together. Let’s look at the second challenge consider yourself as a developer now so if you had bet any application you would obviously want it to scale as per the future trends but if you had built this application on a monolithic architecture.

how do you think you could keep up with the scalability well let’s take an example our shopping cart application is built on a monolithic framework. Now consider three customers come out to the application just to accommodate these three new customers three instances of the same
application have to be created also apart from the three new instances of
the application resources also get wasted for the services which need not
have to be scaled. let us now look into the third challenge which is fault
tolerance. consider your shopping cart application for reference suppose even if one feature of the application doesn’t work then the entire system goes down. this not only creates a problem for the users but also creates a problem for the developers as they have to rebuild it again.

so to avoid these challenges developers of these applications decided to shift from a monolithic architecture to micro-services. now many questions may come to your mind such as what were the advantages of new architecture? how could the developers benefit from the
new architecture? what were the new challenges that were faced with this
architecture? and so on. Let’s discuss each of them one by one
let’s start with what microservices are basically an
architecture where a monolithic application is decomposed into small and micro applications which were packaged and deployed independently. consider your shopping cart application for reference again imagine.

now the developers of this application have shifted its framework from a monolithic to a microservice architecture so this is how the architecture looks like now

even now as a user when you open a shopping cart application you just see features put on together on a single website now there are separate themes handling different features that mean there’s a team of developer handling deal of the day a team of developers handing new labels a team of developer handling customer services and so on. all themes now right cause for their features only making it easy to deploy individual features again and again whenever it is required

how do you think these individual supriya deployable units communicate with each other well these separate individual deployable units communicate with each other through a well-defined interface
of rest or message bus by now you must have understood what were the
functionalities of micro services and how they communicated with each other.
let’s learn more about microservices by looking at different components of its architecture, well the architecture starts with different clients from
different devices trying to perform different management capabilities such
as build surge notification and so on. then each and every functionality is
segregated into separate microservices handling their own data.

for example, macro service A could take care of the search operation. microservice B could take care of build operation. microservice C could take care of
notification feature and so on. all these individual microservices have their own load balancing and execution environments to perform differently
functionalities and capture their own data. these individual microservices
then communicated within themselves through the rest or messages passed to
perform different operational capabilities such as automation and
monitoring also the Qwest of clients were passed on to the
internal architecture through an API gateway.

let’s summarize the difference between both architectures. before moving forward to the features of microservices and the use case so in short monolithic architecture had a single framework for all the features on a single database whereas microservice architecture had different micro services for each and every feature handling their own database.

now what features may the developers ship from a monolithic architecture to microservices? let’s have a look at them the applications built using microservice architecture were easily built altered and scaled. they focused on a single capability all the components could be easily replaced the teams work independently. they allow frequent releases of these software applications treated as products. there were no standardized patterns and most importantly all the features were quickly developed.

let’s look into more of microservices and their implementation by using a real life use case of uber, what do you know about uber?
well uber technologies is a global tax a technology. company headquarter in San Francisco, United States, operating in 600 cities worldwide.

like many of the startups who were also started its journey with a monolithic architecture for a single city. let’s have a look at this architecture initially they had a REST API with which the passenger and the driver were connected this means that the mobile API was connected to the REST API which was then connected to the monolithic architecture as a back-end server. also for people accessing two web UI they were also connected to the same server. coming forward there were three more adapters which we use to perform different functionalities such as notifications sending mails or messages, billing, payment acceptor.

finally a my sequel database to capture all their data so if you observe here all the features such as passenger management billing notification, features trip management, driver management were composed in a single framework. this means that having one code base seemed cleaned at that time and solved Uber’s core business problems which included connecting drivers with riders buildings and payments. but as uber started expanding worldwide into many more cities it continuously faced the problem of scalability and continuous integration.

so developers could not continuously pill test deploy and release the software frequently as. and
when uber started expanding city wise throughout the world also adding new features and fixing bugs in a single repository became extremely difficult for the developers. so to avoid such challenges Hoover decided to follow the lead of hyper growth companies like Amazon, Netflix, SoundCloud and Twitter and broke down its monolithic framework into multiple code bases to form a micro service architecture. so this is how the new architecture looks like

what your
thing is the new change in the architecture well we could clearly see
the introduction of API gateway which connected all the drivers with the
passengers also from the API gateway all the internal points were connected
such as Basinger management trip management and
driver management and so on so basically anybody who connects to the api gateway
gets automatically connected to all the micro services another change that we
observe in this architecture is the introduction of individual separate
deployable units here this means that we can deploy this unit or this unit or any
other unit without disturbing the others.

let me explain you this point with an example consider yourself as one of the developers of uber so now if you want to change anything in the building micro services then you just have to deploy
only building micro services and do not have to disturb the others also this
kind of architecture helped uber to scale its services individually let me
explain you with an example as we all know the number of people searching for
cabs are comparatively more than the number of people actually booking a cab
and making payments so the number of processes working on the passenger
management micro service are more than the number of processes working on the
payments also it was observed that even if any one feature was done no other
micro service would get affected therefore developers of uber need not
build their applications again again even if one micro service goes down now
that you’ve seen a real-life use cases uber can you think of any best practices
to design micro services well let’s have a look at them initially separate the
data store for each micro service then keep the code at similar level of
maturity now after this separately built each micro service according to its
respective features and then deploy into containers lastly create the servers as stateless for communication.

Have a great day I hope you have enjoyed this article please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest.