Microservices Interview Questions Part-1
1. Advantages and
disadvantages of micro-services. Why to go for micro services architecture over
monolithic architecture.
The Advantages of Microservices
The advantages of microservices seem strong enough to have convinced some big enterprise players such as Amazon, Netflix, and eBay to adopt the methodology. Compared to more monolithic design structures, microservices:
● Improve fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
● Eliminate vendor or technology lock-in: Microservices provide the flexibility to try out a new technology stack on an individual service as needed. There won’t be as many dependency concerns and rolling back changes becomes much easier. With less code in play, there is more flexibility.
● Ease of Understanding: With added simplicity, developers can better understand the functionality of a service.
The advantages of microservices seem strong enough to have convinced some big enterprise players such as Amazon, Netflix, and eBay to adopt the methodology. Compared to more monolithic design structures, microservices:
● Improve fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
● Eliminate vendor or technology lock-in: Microservices provide the flexibility to try out a new technology stack on an individual service as needed. There won’t be as many dependency concerns and rolling back changes becomes much easier. With less code in play, there is more flexibility.
● Ease of Understanding: With added simplicity, developers can better understand the functionality of a service.
The
Disadvantages of Microservices
Microservices may be a hot trend, but it does not come without its drawbacks.
Here’s a list of some potential pain areas associated with microservices designs:
● Developing distributed systems can be complex. Since everything is now an independent service, you have to carefully handle requests traveling between your modules. In one such scenario, developers may be forced to write extra code to avoid disruption. Over time, complications will arise when remote calls experience latency.
● Multiple databases and transaction management can be painful.
● Testing a microservices-based application can be cumbersome. In a monolithic approach, we would just need to launch our WAR on an application server and ensure its connectivity with the underlying database. With microservices, each dependent service needs to be confirmed before testing can occur.
● Deploying microservices can be complex. They may need coordination among multiple services, which may not be as straightforward as deploying a WAR in a container. Of course, with the right kind of automation and tools, all the above drawbacks can be addressed.
Microservices may be a hot trend, but it does not come without its drawbacks.
Here’s a list of some potential pain areas associated with microservices designs:
● Developing distributed systems can be complex. Since everything is now an independent service, you have to carefully handle requests traveling between your modules. In one such scenario, developers may be forced to write extra code to avoid disruption. Over time, complications will arise when remote calls experience latency.
● Multiple databases and transaction management can be painful.
● Testing a microservices-based application can be cumbersome. In a monolithic approach, we would just need to launch our WAR on an application server and ensure its connectivity with the underlying database. With microservices, each dependent service needs to be confirmed before testing can occur.
● Deploying microservices can be complex. They may need coordination among multiple services, which may not be as straightforward as deploying a WAR in a container. Of course, with the right kind of automation and tools, all the above drawbacks can be addressed.
2. What are Discovery Register in Microservices
Architecture?
In the microservices world, Service Registry and Discovery play an important role because we most likely run multiple instances of services and we need a mechanism to call other services without hardcoding their hostnames or port numbers. In addition to that, in Cloud environments service instances may come up and go down anytime. So we need some automatic service registration and discovery mechanism. Spring Cloud provides Service Registry and Discovery features, as usual, with multiple options. We can use Netflix Eureka or Consul for Service Registry and Discovery.
In the microservices world, Service Registry and Discovery play an important role because we most likely run multiple instances of services and we need a mechanism to call other services without hardcoding their hostnames or port numbers. In addition to that, in Cloud environments service instances may come up and go down anytime. So we need some automatic service registration and discovery mechanism. Spring Cloud provides Service Registry and Discovery features, as usual, with multiple options. We can use Netflix Eureka or Consul for Service Registry and Discovery.
3. What are the Container in microservices?
Containers are packages of your software that includes everything that it needs to run, like code, dependencies, libraries, binaries, and more. Docker is one of the popular choices for building and running containers, but Kubernetes is quickly becoming the standard that is used to orchestrate multiple containers in enterprise environments. Compared to Virtual Machines, containers share the OS kernel instead of having a full copy of it – like making multiple VMs in a single host. Although it is possible to put your microservices in multiple VMs, containers are commonly used in this case since it takes up less space and is faster to boot up.
Containers are packages of your software that includes everything that it needs to run, like code, dependencies, libraries, binaries, and more. Docker is one of the popular choices for building and running containers, but Kubernetes is quickly becoming the standard that is used to orchestrate multiple containers in enterprise environments. Compared to Virtual Machines, containers share the OS kernel instead of having a full copy of it – like making multiple VMs in a single host. Although it is possible to put your microservices in multiple VMs, containers are commonly used in this case since it takes up less space and is faster to boot up.
4. How Communication between Microservices happens.
There are two ways that I know of through which you can communicate with other Microservices
● Rest Template
● Feign Client
There are two ways that I know of through which you can communicate with other Microservices
● Rest Template
● Feign Client
5. Difference Between Rest
Template and Feign Client.
RestTemplate is used for making the synchronous call. When using RestTemplate, the URL parameter is constructed programmatically, and data is sent across to the other service. In more complex scenarios, we will have to get to the details of the HTTP APIs provided by RestTemplate or even to APIs at a much lower level.
Feign is a Spring Cloud Netflix library for providing a higher level of abstraction over REST-based service calls. Spring Cloud Feign works on a declarative principle. When using Feign, we write declarative REST service interfaces at the client and use those interfaces to program the client. The developer need not worry about the implementation.
RestTemplate is used for making the synchronous call. When using RestTemplate, the URL parameter is constructed programmatically, and data is sent across to the other service. In more complex scenarios, we will have to get to the details of the HTTP APIs provided by RestTemplate or even to APIs at a much lower level.
Feign is a Spring Cloud Netflix library for providing a higher level of abstraction over REST-based service calls. Spring Cloud Feign works on a declarative principle. When using Feign, we write declarative REST service interfaces at the client and use those interfaces to program the client. The developer need not worry about the implementation.
6. List the Microservices
design patterns?
1.Aggregator Microservice
In its The simplest form, Aggregator would be a simple webpage that invokes multiple services to achieve the functionality required by the application.
2.Chained Microservice Design Pattern
Chained microservice design pattern produce a single consolidated response to the request. In this case the request from the client received by Service A, which then Communicating with service B, which in turn may be communicating with service C. All are likely using a synchronous HTTP request / response messaging.
3.Branch Microservice Design Pattern
Branch microservice design pattern extends Aggregator design pattern and allows simultaneous response processing from two likely mutually exclusive, chains of microservices. This Pattern can also be used to call different chains, or a single chain based on the business needs.
4.Shared Data Microservice Design Pattern
One of the design principles of microservice is autonomy. That means the service is full-stack and has control of all the components-UI, middleware, persistence, transaction. This allows the service to be polyglot and use the right tool for the right job. For example, if a No Sql data store can be used if that is more appropriate instead of jamming that data in Sql Database.
However, a typical problem, especially when refactoring from an existing monolithic application, is a database normalization such that each microservice has the right amount of data- nothing less and nothing more. Even if only a sql database is used in the monolithic application, deformalizing the database would lead to duplication of data and possibly inconsistency. In a transaction phase some applications may benefit from a shared data microservice design pattern.
In this design pattern, some microservices are likely in a chain, may share caching and database stores. This would only make sense if there is a strong coupling between two services. Some might consider this an anti-pattern but business needs might require in some cases to follow this. This would certainly be an anti-pattern for greenfield applications that are based upon microservices.
5.Asynchronous Messaging Microservice Design pattern
While Rest design pattern is quite prevalent, and well understood, but it has the limitation of being synchronous and thus blocking asynchrony can be achieved but that is done in application specific way. Some microservice architectures may elect to use message queues instead of rest request/response because of that.
6.Proxy Microservice Design Pattern
Proxy microservice design pattern is a variation of aggregator. In this case no aggregation needs to happen on the client but a different microservice may be invoked based on the business needs.
7.Event Sourcing Microservice Design Pattern
The event sourcing design pattern creates events regarding the changes in the application state. Also, these events are stored as a sequence of events to help the developers track which change was made when. So, with the help of this, you can always adjust the application state to cope up with the past changes. You can also query these events, for any data change and simultaneously publish these events from the event store. Once the events are published, you can see the changes of the application state on the presentation layer.
8.Circuit Breaker Pattern
As the name suggests, the Circuit Breaker design pattern is used to stop the process of request and response if a service is not working. So, for example, let’s say a client is sending a request to retrieve data from multiple services. But, due to some issues, one of the services is down. Now, there are mainly two problems you will face: first, since the client will not have any knowledge about a particular service being down, the request will be continuously sent to that service. The second problem is that the network resources will be exhausted with low performance and bad user experience.
9.Command Query Responsibility Segregator (CQRS) Design Pattern
Every microservices design has either the database per service model or the shared database per service. But, in the database per service model, we cannot implement a query as the data access is only limited to one single database. So, in such scenario you can use the CQRS pattern. According to this pattern, the application will be divided into two parts: Command and Query.
10.Decomposition Design Pattern
Microservices are developed with an idea on developers mind to create small services, with each having their own functionality. But, breaking an application into small autonomous units has to be done logically. So, to decompose a small or big application into small services, you can use the Decomposition patterns.
1.Aggregator Microservice
In its The simplest form, Aggregator would be a simple webpage that invokes multiple services to achieve the functionality required by the application.
2.Chained Microservice Design Pattern
Chained microservice design pattern produce a single consolidated response to the request. In this case the request from the client received by Service A, which then Communicating with service B, which in turn may be communicating with service C. All are likely using a synchronous HTTP request / response messaging.
3.Branch Microservice Design Pattern
Branch microservice design pattern extends Aggregator design pattern and allows simultaneous response processing from two likely mutually exclusive, chains of microservices. This Pattern can also be used to call different chains, or a single chain based on the business needs.
4.Shared Data Microservice Design Pattern
One of the design principles of microservice is autonomy. That means the service is full-stack and has control of all the components-UI, middleware, persistence, transaction. This allows the service to be polyglot and use the right tool for the right job. For example, if a No Sql data store can be used if that is more appropriate instead of jamming that data in Sql Database.
However, a typical problem, especially when refactoring from an existing monolithic application, is a database normalization such that each microservice has the right amount of data- nothing less and nothing more. Even if only a sql database is used in the monolithic application, deformalizing the database would lead to duplication of data and possibly inconsistency. In a transaction phase some applications may benefit from a shared data microservice design pattern.
In this design pattern, some microservices are likely in a chain, may share caching and database stores. This would only make sense if there is a strong coupling between two services. Some might consider this an anti-pattern but business needs might require in some cases to follow this. This would certainly be an anti-pattern for greenfield applications that are based upon microservices.
5.Asynchronous Messaging Microservice Design pattern
While Rest design pattern is quite prevalent, and well understood, but it has the limitation of being synchronous and thus blocking asynchrony can be achieved but that is done in application specific way. Some microservice architectures may elect to use message queues instead of rest request/response because of that.
6.Proxy Microservice Design Pattern
Proxy microservice design pattern is a variation of aggregator. In this case no aggregation needs to happen on the client but a different microservice may be invoked based on the business needs.
7.Event Sourcing Microservice Design Pattern
The event sourcing design pattern creates events regarding the changes in the application state. Also, these events are stored as a sequence of events to help the developers track which change was made when. So, with the help of this, you can always adjust the application state to cope up with the past changes. You can also query these events, for any data change and simultaneously publish these events from the event store. Once the events are published, you can see the changes of the application state on the presentation layer.
8.Circuit Breaker Pattern
As the name suggests, the Circuit Breaker design pattern is used to stop the process of request and response if a service is not working. So, for example, let’s say a client is sending a request to retrieve data from multiple services. But, due to some issues, one of the services is down. Now, there are mainly two problems you will face: first, since the client will not have any knowledge about a particular service being down, the request will be continuously sent to that service. The second problem is that the network resources will be exhausted with low performance and bad user experience.
9.Command Query Responsibility Segregator (CQRS) Design Pattern
Every microservices design has either the database per service model or the shared database per service. But, in the database per service model, we cannot implement a query as the data access is only limited to one single database. So, in such scenario you can use the CQRS pattern. According to this pattern, the application will be divided into two parts: Command and Query.
10.Decomposition Design Pattern
Microservices are developed with an idea on developers mind to create small services, with each having their own functionality. But, breaking an application into small autonomous units has to be done logically. So, to decompose a small or big application into small services, you can use the Decomposition patterns.
7. What is Containerization?
Containerization is a lightweight alternative to full machine virtualization that involves encapsulating an application in a container with its own operating environment. This provides many of the benefits of loading an application onto a virtual machine, as the application can be run on any suitable physical machine without any worries about dependencies.
Containerization has gained recent prominence with the open-source Docker. Docker containers are designed to run on everything from physical computers to virtual machines, bare-metal servers, OpenStack cloud clusters, public instances and more.
Containerization is a lightweight alternative to full machine virtualization that involves encapsulating an application in a container with its own operating environment. This provides many of the benefits of loading an application onto a virtual machine, as the application can be run on any suitable physical machine without any worries about dependencies.
Containerization has gained recent prominence with the open-source Docker. Docker containers are designed to run on everything from physical computers to virtual machines, bare-metal servers, OpenStack cloud clusters, public instances and more.
8. What is Docker?
Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package. By doing so, thanks to the container, the developer can rest assured that the application will run on any other Linux machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code.
In a way, Docker is a bit like a virtual machine. But unlike a virtual machine, rather than creating a whole virtual operating system, Docker allows applications to use the same Linux kernel as the system that they're running on and only requires applications be shipped with things not already running on the host computer. This gives a significant performance boost and reduces the size of the application.
Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package. By doing so, thanks to the container, the developer can rest assured that the application will run on any other Linux machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code.
In a way, Docker is a bit like a virtual machine. But unlike a virtual machine, rather than creating a whole virtual operating system, Docker allows applications to use the same Linux kernel as the system that they're running on and only requires applications be shipped with things not already running on the host computer. This gives a significant performance boost and reduces the size of the application.
9. what is container
orchestration?
Container orchestration is all about managing the lifecycles of containers, especially in large, dynamic environments. Software teams use container orchestration to control and automate many tasks:
● Provisioning and deployment of containers
● Redundancy and availability of containers
● Scaling up or removing containers to spread application load evenly across host infrastructure
● Movement of containers from one host to another if there is a shortage of resources in a host, or if a host dies
● Allocation of resources between containers
● External exposure of services running in a container with the outside world
● Load balancing of service discovery between containers
● Health monitoring of containers and hosts
● Configuration of an application in relation to the containers running it
10.Explain the Netflix Components.
Service Discovery Server: Netflix Eureka
Edge Server: Netflix Zuul.
Central configuration server: Spring cloud config server.
Dynamic routing and load balancer: Netflix ribbon.
Oauth 2.0 protected Apis: Spring cloud + spring security OAuth 2
Container orchestration is all about managing the lifecycles of containers, especially in large, dynamic environments. Software teams use container orchestration to control and automate many tasks:
● Provisioning and deployment of containers
● Redundancy and availability of containers
● Scaling up or removing containers to spread application load evenly across host infrastructure
● Movement of containers from one host to another if there is a shortage of resources in a host, or if a host dies
● Allocation of resources between containers
● External exposure of services running in a container with the outside world
● Load balancing of service discovery between containers
● Health monitoring of containers and hosts
● Configuration of an application in relation to the containers running it
10.Explain the Netflix Components.
Service Discovery Server: Netflix Eureka
Edge Server: Netflix Zuul.
Central configuration server: Spring cloud config server.
Dynamic routing and load balancer: Netflix ribbon.
Oauth 2.0 protected Apis: Spring cloud + spring security OAuth 2
Monitoring Netflix Hystrix dashboard and turbine.