Q1. What is a monolithic Application and what are its advantages and disadvantages?
Monolithic applications:
If all the functionalities of a project exist in a single codebase, then that application is known as a monolithic application. We all must have designed a monolithic application in our lives in which we were given a problem statement and were asked to design a system with various functionalities. We design our application in various layers like presentation, service, and persistence and then deploy that codebase as a single jar/war file. This is nothing but a monolithic application where “mono” represents the single codebase containing all the required functionalities.
Advantages of monolithic applications:
- Simple to develop relative to microservices where skilled developers are required in order to identify and develop the services.
- Easier to deploy as only a single jar/war file is deployed.
- Relatively easier and simple to develop in comparison to microservices architecture.
- The problems of network latency and security are relatively less in comparison to microservices architecture.
Disadvantages of Monolithic applications:
- It becomes too large in size with time and hence, difficult to manage.
- We need to redeploy the whole application even for a small change.
- As the size of the application increases, its start-up and deployment time also increases.
- For any new developer joining the project, it is very difficult to understand the logic of a large Monolithic application even if his responsibility is related to a single functionality.
- Even if a single part of the application is facing a large load/traffic, we need to deploy the instances of the whole application on multiple servers. It is very inefficient and takes up more resources unnecessarily. Hence, horizontal scaling is not feasible in monolithic applications.
- It is very difficult to adopt any new technology which is well suited for a particular functionality as it affects the whole application, both in terms of time and cost.
- It is not very reliable as a single bug in any module can bring down the whole monolithic application.
Q2. What is a Microservice application and what are its advantages and disadvantages?
Microservices:
It is an architectural development style in which the application is made up of smaller services communicating with each other directly using lightweight protocols like HTTP. According to Sam Newman, “Microservices are the small services that work together. The Microservice architecture has a significant impact on the relationship between the application and the database. Instead of sharing a single database with other microservices, each microservice has its own database. It often results in duplication of some data but having a database per microservice is essential if you want to benefit from this architecture as it ensures loose coupling. Another advantage of having a separate database per microservice is that each microservice can use the type of database best suited for its needs.
Advantages of microservices:
- It is easy to manage as it is relatively smaller in size.
- If there’s any update in one of the microservices, then we need to redeploy only that microservice.
- Microservices are self-contained and hence, deployed independently. Their start-up and deployment times are relatively less.
- It is very easy for a new developer to onboard the project as he needs to understand only a particular microservice providing the functionality he will be working on and not the whole system.
- If a particular microservice is facing a large load because of the users using that functionality in excess then we need to scale out that microservice only. Hence, the microservices architecture supports horizontal scaling.
- Each microservice can use different technology based on the business requirements.
- If a particular microservice goes down due to some bug, then it doesn’t affect other microservices and the whole system remains intact, continues providing other functionalities to the users.
Disadvantages of microservices:
- Being a distributed system, it is much more complex than monolithic applications. Its complexity increases with the increase in the number of microservices.
- Skilled developers are required to work with microservices architecture which can identify the microservices and manage their inter-communications.
- Independent deployment of microservices is complicated.
- Microservices are costly in terms of network usage as they need to interact with each other and all these remote calls result in network latency.
- Microservices are less secure relative to monolithic applications due to the inter-services communication over the network.
- Debugging is difficult as the control flows over many microservices and pointing out why and where exactly the error occurred is a difficult task.
Q3. How do Microservices Communicate with each other?
There are three possible ways that can help to communicate microservices with each other.
- HTTP communication:
The outright leader when choosing how services will communicate with each other tends to be HTTP. In fact, we could make a case that all communication channels derive from this one. But, setting that aside, HTTP calls between services is a viable option for service-to-service communication. It might look something like this if we have two services in our architecture. ServiceA might process a request and call ServiceB to get another piece of information. With this approach, we keep the services isolated from one another, and the coupling is loose. The downside is that it creates extra HTTP requests on the second service; it is now going to be polled from the outside until the request is completed. This introduces complexity to the client as well since it now must check the progress of the request. But asynchronous communication allows the services to remain loosely coupled from one another.
- Message communication:
Another communication pattern we can leverage in a microservice architecture is message-based communication. Unlike HTTP communication, the services involved do not directly communicate with each other. Instead, the services push messages to a message broker that other services subscribe to. This eliminates a lot of complexity associated with HTTP communication. It doesn’t require services to know how to talk to one another; it removes the need for services to call each other directly. Instead, all services know of a message broker, and they push messages to that broker. Other services can choose to subscribe to the messages in the broker that they care about.
- Event-driven communication:
The final communication pattern we will visit in this post is the event-driven pattern. This is another asynchronous approach, and it looks to remove the coupling between services altogether. Unlike the messaging pattern where the services must know of a common message structure, an event-driven approach doesn’t need this. Communication between services takes place via events that individual services produce. A message broker is still needed here since individual services will write their events to it. But, unlike the message approach, the consuming services don’t need to know the details of the event; they react to the occurrence of the event, not the message the event may or may not deliver. In formal terms, this is often referred to as “event only-driven communication.” Our code is like our messaging approach, but the event we push to SNS(Simple Notification Service) is generic.
Q4. What is API Gateway in microservice architecture?
The API Gateway is a server. It is a single entry point into a system. API Gateway encapsulates the internal system architecture. It provides an API that is tailored to each client. It also has other responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling. API Gateway is also responsible for request routing, composition, and protocol translation. All the requests made by the client go through the API Gateway. After that, the API Gateway routes requests to the appropriate microservice.
Q5. What is load balancing and how it works in microservices?
In Java EE architecture, we deploy our war/ear files into multiple application servers, then we create a pool of servers and put a load balancer (Netscaler) in front of it, which has a public IP. The client makes a request using that public IP, and Netscaler decides in which internal application server it forwards the request by round-robin or sticky session algorithm. We call it server-side load balancing.
But in the case of microservices architecture, we use client-side load balancing because we can change the balancing algorithm programmatically.
To understand client-side load balancing, let's recap microservices architecture. We generally create a service discovery like Eureka or Consul, where each service instance registers when bootstrapped. Eureka server maintains a service registry; it maintains all the instances of the service as a key/value map, where the {service id} of your microservice serves as the key and instances serve as the value. Now, if one microservice wants to communicate with another microservice, it generally looks up the service registry using DiscoveryClient, and the Eureka server returns all the instances of the calling microservice to the caller service. Then it was a caller service headache which instance it calls. Here, client-side load balancing stepped in. Client-side load balancing maintains an algorithm like round-robin or zone-specific, by which it can invoke instances of calling services. The advantage is s service registry always updates itself; if one instance goes down, it removes it from its registry, so when the client-side load balancer talks to the Eureka server, it always updates itself, so there is no manual intervention- unlike server-side load balancing- to remove an instance. We can use @RibbonClient(name="EmployeeSearch") of Netflix Ribbon dependency. By doing this, we instruct Spring Boot to communicate with the Eureka server and get the list of instances for service id EmployeeSearch. Please note that this is the {service-id} for the EmployeeSearch application.
Q6. What is stateful and stateless load balancing in microservices?
