What is Microservice Architecture and Why to Use Them?

Building an application is all about making it efficient and effective. There are various ways to make an application run smoothly. The major reason which makes an application function properly is the invention of microservice architecture. Microservice architecture helps you to break large components into sub-components thus making debugging easier and also helps in the functioning of the website without any hassle. 

Using microservice architecture in your application helps you to build it in a more effective and efficient manner. But there are some challenges you can face if microservice architecture was not used. In this article, you will come across some of the major challenges you could face if microservice architecture was not used while implementation. Let's have a look at those challenges and also know about microservice architecture in depth. 

Brief on Microservice Architecture

Imagine you run an organization called XYZ and let's say you have a requirement right now that you want to create an "Employee and Customer Management System". And let's say you have few people who purchase your services like your clients/customers. So they talk with you about the requirements and all. And in the organization, you have some employees also. So as per the requirements you want to create an application that is going to help you to manage your employees and customers. So we want to build an application that has the following basic functionalities.

• Add employees/customers
• Delete employees/customers
• Update employees/customers

And you started developing the application. So in the beginning, you try to find out the main components. So the main components/modules for this requirement are 

• Employees Module: To manage your employees
• Customers Module: To manage your customers
• Courses Module: In this module, you'll be selling your courses, somebody will purchase your courses, etc.
• Address Module: In this module, we will manage the employees' and customers' different types of addresses like billing addresses or shipping addresses, etc.

After that, you started designing endpoints like 

• /employees, /employees/id
• /customers, /customers/id
• /courses, /courses/id
• /address, /address/id, etc.

Please refer to the below image -

So now you have different modules and imagine you have developed all these endpoints and you have created the Employee Controller, Customer Controller, Course Controller, Address Controller created all these endpoints which are specific to those controllers and you just wrapped it off under this .ZIP file and you put it on a server let's say on a tomcat server or JBoss server and you deployed the war file. 

And you'll have your database as well which is going to be connected and all your employee tables, customer table, course table, and address table will be over here on the database. So this type of architecture, we can say a Monolithic Architecture. Why so? Because we are wrapping all our components modules under a single zip and we are deploying it into the server this is the traditional approach which is pretty much familiar in 2000 but right now the requirements are changing and you're going to be getting a lot of different types of requirements. So this is something that we call Monolithic Architecture.

So now what are the problems and challenges that we basically face on monolithic and why the world is moving towards microservices?

Challenges with Monolithic Architecture or Why Microservice Architecture?

Challenge 1:

Imagine you have a requirement right now, that in the course module, you want to have a new feature implemented. So to implement some new features or fix some bugs. Let's say you want to add this new feature to the course module so that all courses will have this new theme or add a new button. So imagine you have been given some kind of sample requirements and you need to change them in the Course Module in order to add the new features.

So, you have made some changes to your code base in the Course Module and you push it to Git and the code goes to Jenkins and Jenkins picks up the code, creates a build and deploys it into the server and your application went live and you have tested your changes and you have seen the application is working as the client requirements. And the next morning, you got to know from the testing team that you have pushed some changes, and that basically broke the application. And whenever you asked them you got to know that the new feature is working fine but something is broken with the customer module. For example, the customers are not able to log into the application. So you got confused because you make changes in the Course Module but the effect is showing on the Customer module. But why so?  Because the entire application is getting zipped together and getting deployed together on the server. So there are two problems over here

1. Any changes in the code lead you to test the entire application.
2. Developers may not have knowledge of all the modules and that's making it harder to get started with any module and also fix any issues.

So basically the thing is that a developer who is working on one module might not have an idea of other modules. That's why if you are working on a monolithic application in your company it might be very hard to get started with the application.

Challenge 2:

Now talk about another scenario. Let's say the client has given you an offer let's say every new user and customer will get 20% off in all the courses. Now what will happen is a lot of users will come and they are trying to log into the application by signing up and creating a new user account on the website. Now there are lots of loads coming into the Customer Module. In short, the Customer Module code will be mostly utilized. Now what happens is your Spring Boot or any application that cannot basically handle lots and lots of load coming into this module. And your website will be coming slow over here.

So right now what you can do as a solution you can take the same application which is running on server 1, you can put it on server 2, and can put it on server 3. Now same application same code you are putting in many servers and you are basically having your DB connected to all the servers. Right now the same code is running on three different servers. So, now our goal is whenever the request is coming, some request we will send to Server 1, some requests to Server 2, and so on. We also have a Load Balancer implemented and this load balancer will do what whenever the request will come it will route the request into the different servers to handle and balance the load. 

Right now the same code is running in three different servers and this load balancer is basically routing the request to multiple servers in order to balance the load so that there will not be any burden or load into different servers that we have now. But what's the problem here? 

The problem is here you can see in the above image we are having traffic in the Customer Module Only but right now just because the customer module is heavy we are ended up deploying the code into three different servers because the customer module is not independently deployable. So the point is we are only getting the load in the Customer Module but why deploy the Employee Module, Course Module, and Address Module into different servers? This is unnecessary and the cost of the server is not that cheap. It's a complete waste of both money and resource. 

So here comes the Microservice Architecture to solve these major problems.

Have a look at Microservice Architecture – Introduction, Challenges & Best Practices

What is Microservice Architecture?

Look at this architecture below.

You have the Employees Module, Customer Module, Courses Module, and Address Module, but right now we will not tell them as modules rather we will tell them Services, small, small Services. The entire application has divided into four different small services the employee is a separate service, the customer is a separate service, the course is a separate service, and the address is a separate service. 

Now we will create separate applications (for example 4 different Spring Boot applications) for these services. And these applications can talk to each other internally. So right now these are four different applications and they all have separate databases. We can say building out small, small services is called Microservices. So now that particular monolithic architecture changed to this.

We have our Employee Service/Application, the code goes to get Jenkins to build it and it pushed it to the server, this server has a separate database called the Employee database and the same goes for the other 3 modules. So here we have 4 different databases, and 4 different Servers for 4 different services/applications. You have five more modules same as well. So following are the advantages of microservice -

• Independently Deployable
• Each app can be tested separately
• Code changes in one application/service do need an entire application testing
• Dev working on one service shouldn't require the entire application knowledge

Conclusion

Microservice architecture helps you to build an efficient application in a short duration. There are some challenges you might face if microservice architecture is not being used. Now that you have read some of the challenges you would have faced if not implementing the application using a micro-service architecture. It's efficient and effective to use microservice architecture while building an application.