What is a Microservice?
Many Large-Scale Software Projects Employ the architectural approach known as a Microservice System. Efficiency, dependability, performance, and scalability are to be increased.
A single application can be developed using the microservice architectural style as a Collection of Small Services, each of which runs in its own process and Communicate with other services using simple tools, frequently an HTTP Resource API. These services were created with business capabilities in mind and can be independently deployed using deployment equipment that is completely automated.
Simple To Deploy: You can upload a single file, such as a WAR file in a Java application, to deploy the complete system. Microservice vs monolithic application
Simple To Use: Just click the run button in your IDE to begin running tests.
Simple To Develop: You can use a text editor or an integrated development environment (IDE) to open the full project.
Figure 1: Architecture differences between traditional monolithic applications and microservices
Image courtesy of BMC.
Difference Between Monolithic Application and Microservices
On the left side we have a Monolithic Application which can be a single Springwood Application with Multiple Controller Class. All the controllers are in one single Springwood application and if you make any change to any of these controllers. We will have to rebuild and Deploy the Entire Application into the server.
In Microservices we have Multiple Smaller Web Services rather than one large monolithic Web service. This Web services are much smaller, and the individual services are responsible for one business capability. These services can also be implemented in different programming languages and can be Hosted on Different Platforms or servers.
For example, User Web Service might be implemented with JavaScript code and spring MVC.
The Address Web Service can also be a JavaScript and spring MVC.
While the Products Web Service can be implemented with Jersey 2, JAX-RS.
Search Web Service can be implemented with PHP.
In one case it is one big web service built as a single monolithic application and in the other case it is a set of small fine grain and independently deployable restful Web services.
Separate micro services can be implemented with different technologies and deployed independently and run on the different server.
Microservices Communicate with each other with the help of HTTP Requests.
A microservice is decomposing a monolithic application into small pieces and each web service is deployed separately.
Let’s assume that you have started building a project on a single monolithic application. In time the functionality of the application will grow up. It will become very large, and the team will decide to split this large monolithic application into smaller micro services.
When the application is spit into multiple Micro services Each micro service will have its Own Database. It is called Database Per Service Design Pattern.
The products information will be in products database and the user information will be in the user database.
Micro services do not have the access to obtain information from the other database.
If needed micro service can be scaled up too. For example, if Load on one micro service increases you can Create Multiple Instances of it on the same server and this will be another micro service design pattern that is Multiple Service Instances For Host.
You can start as many instances as possible of product micro services needed because each instance of product micro service starts up on actual port number and they do not conflict with each other even when they run on the same server.
Application does not need to know the location of all micro services. It only needs to know the address of our API Gateway and API gateway will then Route the HTTP request to the Destination micro services.
The Eureka Discovery Service is like an address book of all currently running micro services and API Gateway will learn the location of destination microservices from the discovery server.
If there are multiple instances of microservices running, then API gateway will Equally Balance HTTP request between this running instances. We can also use Load Balancer applications that can be used with API gateway to equally load HTTP request between running instances of micro service. You can learn more about Load Balancing with this link.
Imagine a scenario where we have a Microservice A that needs to communicate with Multiple other micro services at the same time. The direct request and response communication is no longer convenient in this case. In this kind of situation, we can use Even Driven Architecture. Micro service A that needs to communicate with multiple other micro services will Publish A Message to the message broker. Micro services that are interested in receiving this message will consume this message from Message Broker as soon as it becomes available there.
In Even driven architecture if one of the micro services is down it will still be able to consume the event when it comes online, and this is because an Event message is persisted in the message Broker. When the subscribed micro service comes back online it will consume the message that it has missed.
Automation Of Microservices
A monolithic application’s manual deployment, spinning up a few cloud instances to host it, or installing software on those instances could be manageable pains. To scale that up to 100 deployments or 1,000 instances, however, is pointless. The automation of deployment, provisioning, and configuration management is essential for microservices. Any microservice project must use continuous integration or delivery. On this, Martin Fowler has some really good information.
Conclusion: Congratulations, you now have an understanding on what microservices are and how can they make our life easier. You also know the use of API Gateway and Load Balancer.
Happy Coding!
