Introduction to Monolithic vs. Microservices
Hi guys, welcome to Code Decode. So today we're going to start with some microservices basic brief tutorials and then we can quickly move ahead towards the microservices interview questions so that at least some basics are clear for us. For this particular tutorial, we are going to take a simple example of a very real-time set scenario right now, that is the vaccination centers and the user base.
Now for implementing that particular scenario, what people might have options to do that. So there might be two options: either they create a monolithic application or they create a microservices architecture. So let's first understand how a monolithic application is there in the market and why that was not that good, and that is why microservices came into picture. So let's first understand why monolithic application and what is a monolithic application.
So one of the key applications is nothing but an application built as a whole, sole, single unit, as a single component. So basically such applications usually have three main layers. That is the client layer, which is usually done with Angular or React or JSP servlets. The UI depends upon you. Then you have server-side applications layer. For example, we have Spring Boot, Spring MVC, the whole and soul server-side layer. Then we have a database which is used to have your data. Say for example in our case, we are going to have the data for not only the vaccination centers, but also we are going to have the data for the user base.
So there is one single database connected to a server-side application, which is actually interacting with a client-side interface like Angular to get the data to and from the database. So that's a very basic architecture of a monolithic application. And basically you understand now that a monolithic application is a very large code base and it lacks modularity. So let's see the monolithic application architecture.
A Deep Dive into Monolithic Architecture
So if you are a client, say for example you are trying to register yourself into the CoWIN site and you want to book a slot at the vaccination center, so you are the client. You have a browser in place. This presentation layer is your CoWIN website. So cowin.gov.in is your presentation layer, which internally might have interacted with the controller layer if it would have been a monolith application. We don't know what it is basically, but if it would have been a monolith application, it would have connected with the controller layer which is capable enough to handle all your REST API calls. Like for example, get the vaccination centers, fetch the slot timings, anything, everything. So all the REST APIs are here.
Then you have business logic here. Say for example, open the registrations only for the age greater than 45. So all this business logic goes into the business layer. Then you have your POJOs like User, so when you try to register, your POJO is converted into a row in a table of the user base. That is done with this particular repository layer, which is nothing but an interface between your Java logic and your tables or the database logic. So that's the repository layer for you.
So this is basic monolithic application architecture, and the disadvantage I'll tell you here only is that now if the government says that put only vaccines for age between 45 to 18, what you will do? You will put all your logics here. So as and when government starts increasing your logics, your business layer starts to get thick, thick, and thick. So you not only have to handle all the business logics for the vaccination centers but also for the user base. So this is the disadvantage here. We'll cover disadvantages right now.
Disadvantages of the Monolithic Approach
So basically you understand that the code base gets larger in size with time and hence it's very difficult to manage them. It's very difficult to introduce new technology as it affects the whole application. So if you have a monolithic application in a very old-fashioned technology like JSP Servlets, if you want to make it to Spring Boot, it's very difficult. Now you can't, you have to rewrite your whole application.
If a single bug comes in any module, the whole application is down because it gives you some error, exception, and your whole application is down. So suppose if you have a vaccination center down, even your user module, you won't even be able to register yourself into the CoWIN website. So that's the disadvantage. A single bug in any single module lets down your whole application.
Now it is very difficult to scale a single module because you have to scale the whole application. And continuous deployments are extremely difficult. Why? Because large monolithic applications are usually an obstacle to frequent deployments. If you even have to update one module, suppose the government says, now open the registrations for age 18 to 45, so only the user module, the user table has to be modified. But then, you have to redeploy the whole entire application if you have a monolith application, which even affects your vaccination centers. So that's a difficulty in continuous deployments of even a small module.
Introducing the Microservices Architecture
Now what are microservices? So now we understand why the monolith applications are difficult to handle. So let's see what are microservices first. So while a monolith application works as a whole and sole single component, microservice architecture breaks it down into independent, standalone, small applications, each serving one particular requirement.
Say for example, I have two requirements right now, only two. We are going to take a very simple example and we are going to scale it more and more as far as you require. So in this example, I can have one microservice handling all vaccination centers and one for handling all the user base. So within this microservice architecture, the entire functionality is split into independent, deployable modules. So one module you can say is my user module, one module you can say is my vaccination center module. So these communicate with each other through some ways. So the usual way is the RESTful web services. You can also use messaging to convey or communicate between them.
So let's quickly see the microservice architecture. This is a very high-level microservice architecture. It's not as it looks, but in the theoretical way, you can see this. But I'm going to add many more components to these. So let's see the very high overview. So this is a UI, say suppose it's in Angular. If this is a UI, it interacts with your services, it calls your particular microservice. That particular microservice interacts with each other through RESTful web services, and they might have different databases having their own tables and databases. They might even share a common database. Currently, I am considering that they have different databases.
Apart from that, what we are going to do is we are going to have the API gateway as a layer between it. So UI interacts with the API gateway, the API gateway routes you to a particular web service depending upon the routing functionality you have given in the API gateway, which we are going to see in a few seconds.
Advantages of Using Microservices
We are also going to have the Eureka service for the service discovery. I'll tell you why.
So let's see the advantages of microservice architecture first. So all the services are independent of each other. Therefore, testing and deployment are as easy as compared to the monolith applications because they are independent. You can deploy each of them independently. So suppose I want to have service one deployed, you can have service two and service three in place; you could just deploy service one and you are good to go with them.
If there is one bug in one microservice, it will not impact the whole application. Say for example, if your vaccination center is down, you don't have to wait for your users to register to your application. They can still register because that's a standalone functionality and module. It's not dependent upon the vaccination center at all. They are deployed independently. So one goes down, another is not affected. That's a very big benefit of microservices architecture.
Now with microservice architecture, it's very easy to build your complex applications because understanding and deploying a whole complex application in one single unit is very difficult. But when you divide your whole complex application into small, small applications and modules, it is very easy. And you can actually delegate those small, small applications to one person in a team and you can easily deploy and develop them. It also gives flexibility to choose the technology. So suppose if in the team you have one person with a different technology and one with a different technology and framework, you still can use them to create your different microservice architecture. It's just that they should interact with each other through any medium, RESTful web services or messaging, it doesn't matter. So your technology and framework is no more a hurdle to you. You don't have to develop each and every functionality in only one single framework. For the time being we are going to use Spring Boot only, but you can use anything that you want to.
How to Migrate from a Monolith to Microservices
Now the very first important question any interviewer asks you is, if you have a monolith application, how would you, what will be your approach to convert it into a microservice application?
So the very first thing that you need to start up with is that if you have a monolithic application, you need to identify all possible standalone functionalities and modules. Say for example, if you have vaccination centers and users as a whole application to be created, what you will be doing? You will find out all the standalone functionalities. So I can say my users are independent and my vaccination centers are independent. So I can say I have broadly only two functionalities to be implemented. That is one microservice application for users, one microservice application for vaccination centers.
Now once we have identified that, you need to create standalone projects. Currently, we are going to use Spring Boot because this is the rapid application development technology we have in the market right now. So we are going to use Spring Boot to create these microservices. You can use anything that you want to. It's just that they should interact with each other. Now if you want to interact with them, then there should be some way to do that. So it can be REST APIs or messaging. I am going to use RESTful web services because it's easy for me to. You can use anything that you want to.
But just doing this is not enough. And it's not actually enough to say to your interviewer that, yes, I have defined my functionality, I am good to go with microservice architecture. No. At the end, he will say that they are just two RESTful web services interacting with REST APIs. So this is not a microservice architecture at all.
To make this a proper RESTful web service implemented into your microservices, you need proper load balancers. You need Eureka for service discovery, which is actually useful when you have the load balancing in place, you have cloud deployments. Then these applications are not just interacting with each other, they are actually interacting with Eureka for the service discovery in many more ways. You have API gateways and many more stuff to make sure that your web services are capable enough to interact even at the cloud environment.
So this is not just enough to create a Spring Boot application and interact with the REST APIs. He'll for sure say that no, this is not a microservice architecture, these are RESTful web services that you have created. You need different tools and technologies to make them a successful microservice architecture, which we are going to see in a few seconds. So let's get started.
In the year 2020, LinkedIn filtered out the top 10 startups. And in those top 10 startups, we have five of them, that is, UpGrad, Razorpay, Grant, Urban Company, Yellow Messenger. But cracking these five companies is very tough because you have only two options 'til now. The first one was on-campus, second one was off-campus. But for the on-campus part, they hired only from tier one campuses and colleges, that is IIMs and IITs. In the case of off-campus, for even one single vacancy, they receive lots of resumes. So the chances of your resume getting shortlisted are very rare.
So there is now a third option also for you. That is, Relevel by Unacademy came up with this particular opportunity, that you don't need a strong resume for the same. What you just need to do is to apply for this tournament, clear these two names. So register before the 22nd of June here. You have to face five challenges. As soon as you clear them, you will get something called as a Relevel score. With this particular Relevel score, you will be capable enough to apply for these companies. But to apply and to become a part of it, you need to pay 2,000 rupees. But with the link given below in the description with the code, that is code10, you will be able to get a 10% discount. But register before the 22nd of June. That's where the registration ends.
Tutorial Plan: Spring Boot and Eureka Implementation
Okay, so let's first see what we are going to do. Actually, we are going to do nothing but we are going to actually create three services. The very first is the Vaccination Service Center. This is basically a microservice which is used to handle all your API calls for vaccination centers, so adding a vaccination center, removing, deleting, updating, and all basic operations. Then we have one more microservice that we are going to create as a Spring Boot application, which is a User Service, which is going to handle all your user operations.
There will be something called as Eureka, which is a discovery service. Now what happens when you have created two applications as RESTful web services? But now when you are doing load balancing... so you also know that even in your, if you have worked upon any application which is deployed in production, your one single server is not capable enough to handle all your requests. What will you be doing? You're going to create the replica of each application on different servers, so that even if one server is down, another server is capable enough to handle your request. In that case, you have load balancing done in case of microservices. And if you have load balancing done, now if I am going to give you one simple use case, okay? You are a user, you are registering to a vaccination center. Now we are going to see from the perspective of a vaccination center admin. What a vaccination center admin wants to do is to see what all users are today going to come at your vaccination center, or what users have scheduled or actually reserved a slot at your vaccination center. In that particular case, you need to hit your API with a particular user vaccination center and fetch all the list of users.
In that case, you need localhost:http://, say a port number, 8081/user-service. Then what will happen if that particular 8081 port is not working and you have load balanced to 8082 or 8083? What will happen? Your request will fail. In that case, when it is either load balanced or when it is deployed on the cloud, you have a different IP address when your instance is restarted. Are you going to configure each of those URLs into your vaccination service center? No, you cannot do that.
So in that particular case, Eureka comes into picture. What Eureka does is, you just give me the name of the service that you want to hit, I will give you the URL which is load balanced, which does not have many requests right now to handle, which is free, and which is working. I will give you the URL, then you hit that particular URL. So that is Eureka for you.
It handles your load balancing situations, it handles your dynamic URLs. So whenever you go to the cloud, you deploy, you have dynamic URLs. That particular thing is handled by Eureka for you. So what we will be going to do is we are going to hit a particular URL. I am going to show you how. You are not going to do localhost:8080. It's no more localhost:8080. It's the service name. So I'll say http://vaccination-center/add or find-user. In that case, you are going to hit Eureka first. Eureka is going to see, okay, you need the vaccination center, go here. You need the user service, go here. So that's the Eureka server for you.
Okay, so in the next video, we are going to create all these three services as Spring Boot applications and we will see how these two services, Vaccination Center and User Service, will interact with each other and how they are going to register themselves to Eureka. So let's see in the next video. Thank you.
