Microservices Explained: What They Are, Problems They Solve & When Not To Use

is Monis and today we will talk about  Microservices. At the end of this video   you will be able to clearly understand what  microservices are and why do we need them,   what problems do they solve and when not to use  microservices. So without further ado, let's get

started. If we take an example of any e-commerce website  like Amazon or Ebay or Walmart there is a lot   going on behind the scenes. Applications like  these have a lot of complex features running  

under the hood and maintaining all of that, is no  easy feat. There are different teams for managing   different aspects of the application. For example, a  team to work on the browse and search part of the   application. A team for cart and checkout. A team  for Account Management and a team for maintaining  

the UI and UX of the application. Not so long  ago, these teams usually had a single code base.   Every person from these different teams used  to add their changes to this Central codebase.  Ultimately, all this was packaged in a single heavy  unit and deployed on a set of computers so that  

the public could access it. These kind of one unit  for everything applications are called Monolithic   Applications. Now, although this monolithic approach  works, it comes with its own set of problems. Let's   take the example of changing the color of a  button. The code to do this could probably be  

a single line and if you wanted to change that,  you'd have to repackage the whole codebase   again into a new unit and deploy on the computers.  This process could be quite cumbersome for a small   change. Therefore, a lot of organisations started  clubbing the changes from various modules over a  

period of let's say 2 weeks and deployed multiple  changes all together. This meant that the frequency   of changes was quite low and if something went  wrong in one of the features, the complete set of   changes had to be rolled back fixed and redeployed.  Another problem is scalability. Now a lot of people  

browse and search for products on the e-commerce  websites. They go through a lot of stuff and then   they decide whether to buy something or not. Even  if you intend to buy something you go through a   lot of items to find that one perfect article that  would fit best to your requirements. Now thinking a  

little bit from a technical perspective, the browse  and search part of the application receives a lot   of traffic compared to the checkout part of the  application. Even if a customer goes through an   average of 10 products to just buy 1, we can  simply say that the browse and search receives  

10 times more traffic than the cart and checkout.  And that is assuming everybody buys a product. This number could of course change based on a number  of factors - like the popularity of the website,   percentage of people not buying anything but  just browsing and so on. Now, a food for thought  

is although we need high powered systems to manage  the browse and search requests but we only need 10   to 20% of the Firepower for cart and checkout. And this goes down even further for account management   modules. I mean how often do we really change  our email addresses and these type of things?  

Quite rarely. So if there is an upcoming Christmas  sale which will increase the load on the website   by let's say double, which means we might have to  scale up and add more servers. Now, we do expect the   load of search and checkout to probably be doubled  as well but the chances of account management load  

getting doubled seems quite unlikely. So in this  situation, it is not possible that we scale some   parts and skip the others. This is not optimal  from an architectural perspective nor is it cost   effective. Now, these are not the only problems that  we have. A significant Challenge in a monolithic  

system is handling faults. Imagine a case  where there is an error in account management   module because of which the whole application  cannot function. In this case, it is not possible   to isolate this fault. Although there might be  nothing wrong with with the browse search and  

checkout they cannot be used as long as account  management is not fixed. So as you can see, a large   monolith brings a lot of problems with it and  to solve these problems microservices came into   the picture. Microservices came with the idea of  dividing the whole big application into logically  

separate modules. Each of which owning a single  responsibility. For those who have been in the   software engineering for quite a bit of time, can  consider microservice architecture as a flavour   of service oriented architecture (SOA). Now when we  roughly try to split this e-commerce monolith into  

microservices, we can have the browse and search as  one service which deals with homepage browsing and   searching for products and these kind of things.  And then we can have cart and checkout - which deals   with adding items to the cart and the journey to  place the order including the payments. And then,  

we can also have Account Management - which deals  with the account side of things like change and   view email addresses, passwords and viewing order  history. So each of these modules can have their   own teams which would be responsible only for this  part of the project and can be quite agnostic to  

any other team. Similarly, they all can have their  own databases depending on the requirements. Each   module can have its own database and can choose  the database technology accordingly. For example   cart and checkout teams can decide for something  like Postgres for managing transactions whereas  

browse and search could have a NoSQL database  because of high performance and less need of   concurrent transactions. Each of these modules  can also implement their codebase in different   technologies. For example, the Account Management  team can decide to create their codebase in Java  

while other teams are free to decide on other  programming languages. Now, separating all of   these services is cool but how will these services  be connected with each other? For example, a person   browsing something wants to add an item to  the cart and buy it. In a monolith service, it  

was quite easy because we have the same codebase  which could interact with different modules inside   of it but now that the services are separated, how  will the browse service tell the cart service, "hey   cart !add this jeans to the cart" and once the user  places the order how will this order appear in the  

order history? So, there has to be some sort of  communication between these microservices so that   they can talk to each other and delegate  responsibility when needed. Let's explore   that a little more. The communication between  microservices can happen in a variety of ways.  

A very common way of communication is through  HTTP REST APIs. So each microservice can have a   bunch of computers running behind the scenes  this set of computers or servers is called a "cluster". Each cluster can have an IP address or a URL. Just like we type in a web address to reach a  

website from our browser, these microservices can  also be reached using these IP addresses. Now each   microservice can expose a set of actions that you  can perform on those microservices and can also   specify what data it needs to perform those actions. For example, the cart service can expose a  

REST API which can take some basic data to add an  item to the users's cart so when we click "Add to   Cart" from the browse feature it sends a REST call  to the cart service and the cart service adds two   quantities of this product to this user's cart  and return the success message back. So that we. as  

users, can see that the item has been added to the  cart. Similarly, this service can expose different   endpoints to perform different actions like - remove items from the cart, check out place orders   and so on. Although these HTTP REST APIs are quite  a common communication practice, microservices can  

also communicate in a different way. For example,  when a user places an order we want to do multiple   actions with this order data. For example, updating  the order history so that the users can see the   order in their profile, sending email to the  users like an order confirmation email, sending  

order details to to the warehouse so that they can  ship the products to the user, send order details   to analytics. All of these actions require order  details like the items in the order, total order   amount, shipping address, billing address and so  on. Assuming all of these actions are handled  

by different microservices we can either make  multiple REST calls to different places or we   can publish a message with order details at one  common place from where all microservices can   read this message. There are quite quite a few  technologies which have this messaging system  

and one of such Technologies is called Kafka by  Apache. So when we publish a message using Kafka   to a "topic", these services which are supposed to  read our messages can be provided access to this   topic. So when we send a message the services can  read it and perform their actions accordingly. So,  

this is another way of communication. Now, once  the microservices have been separated and their   communication is correctly established, we can  now talk a little bit about how it solves the   problems that we have discussed before. Remember  the example we took for changing the color of a  

button? Well with microservices we no longer have  to repackage the whole application into a single   unit and do a heavy deployment. We just have to  repackage the smaller chunk of the application   which only deals with the frontend side of  things. Other features like browse, search, cart  

and checkout no longer have to be even touched  for this change to happen. This also enables us   to ship out features much faster. With better  modularity, it now becomes feasible to scale up   certain parts of the application. The browse and  search traffic, cart and checkout traffic, account  

management traffic - all can be scaled separately  and according to the expected traffic. Another   advantage is Fault isolation. This is quite a  decent advantage of microservices. Imagine that   in a monolith, something goes wrong and the whole  application goes down and the user will see this.  

However, in microservices architecture if something  goes down in the account management module, only   that module suffers. The remaining parts of the  application like browse, search and checkout will   still continue to work. Which means that the user  could still place orders. So microservices solve  

a lot of problems that come with monoliths. But  these advantages don't come without a catch. Since   now the services are separated, they no longer  are tightly coupled but this means that they   have an extra communication overhead between the  services. It simply means that since microservices  

communicate to each other over a network, there  is also a problem of network latency which can   make the application relatively slower. Another  pain point with microservices is that it is   quite difficult to manage transactions across  different services. In a monolith, it was quite  

easy to perform transactions as there was a single  codebase in a single technology so you could just   put everything that you want to update in a single  transaction block. However when microservices are   separated, the transactions can span over multiple  microservices and have to be explicitly handled.  

For example, when a user places an order - the  inventory or the stock has to be decreased.  Now, this inventory management could be handled  in a different service altogether and now the   transaction has to be maintained across different  services. This can become quite complex when more  

microservices are involved in a transaction. So, as  you can see there is a lot of baggage that comes   with microservices but that doesn't mean that we  cannot handle this baggage. There are design patterns   which we can use to mitigate these problems. But  that's a topic for another video. So we talked  

a lot about microservices and how they solve  a lot of problems but that doesn't mean that   microservices are a solution to everything. There  are very specific use cases for which monoliths   are actually a really good fit. For example, if  you're working at a startup which is undergoing  

a lot of changes - it might be a wise decision  to go ahead with a monolithic architecture. For   smaller projects, it's actually easier to work  on a single codebase rather than having the   complexity of microservices. So there you have  it! Some fundamentals about microservices. Write  

down in the comments below if you have any  questions, see you in the next video, Bis Dann!