If we talk about a job interview in Java technology, knowledge of Microservices is expected from a java developer now-a-days. Even if you don’t mention it in your resume, you will be asked a question ‘Did you get any chance to work in Microservices?’. It happens because Microservices is gaining the importance day by day in developing a Java based Application. Apart from that, microservices is a trending architecture in the industry. Hence, sometime it becomes a ‘Must Know’ skill for a Java developer. Therefore, our topic for discussion is ‘Microservices Interview Questions & Answers’.
Microservices Interview Questions
In this article, we will talk about the most important interview questions on Microservices. If you are looking for detailed tutorials on Microservices, kindly visit our Microservices Tutorial section. Let’s discuss out topic ‘Microservices Interview Questions & Answers’.
What is Microservices?
Microservices is an architectural design that organizes an application as a group of smaller services instead of a single bulky service. Moreover, these smaller services have the following behavior:
♦ Loosely coupled
♦ deployable independently as a single entity
♦ Highly maintainable and testable
Apart from that, these services need smaller team for development and they are perfectly organized around business capabilities. Basically, in microservices based implementation, we divide a big application into smaller modules (services). Although, the implementation of each module happens as a single application. When integration of all services (modules) takes place, the complete application architecture is known as Microservices. In simple words, Microservice is all about distributing or breaking a large application into small pieces (services).
Moreover, instead of sharing a single database schema with other services, each service should have its own database schema. Having a database schema per service becomes essential if you want to take full advantage of microservices, because it also ensures loose coupling.
What are the Benefits of Microservices Architecture?
1) Microservices offers high flexibility for changes in functionality. If we make any change in one service, we don’t need to stop other services. Other services will remain functional.
2) If one Microservices is not working properly then it may not affect all other services. For example, Let’s assume Amazon shopping portal. If payment service is not working then it may not stop other services such as Product Search, Add items to Cart.
3) Modification, Upgrade, Enhancements to new technologies are not so complex as compared to Monolithic architecture because we work on small modules.
4) If the number of Microservices increase, the code will never become complex. It will not be mandatory to make other services down as opposed to Monolithic application.
5) Scaling Service is easy, as Microservice architecture enables each service to be scaled independently. Memory will also be used in an Efficient way.
6) It makes continuous deployment possible for complex applications as Microservice architecture offers each microservice to be deployed independently.
7) It provides a choice of adopting new technologies in between the development instead of making choices at the start of the project.
8) There is always a possibility to replace small parts of the system easily, in case if any part is unreliable or client demands it to replace.
9) Easy to integrate with new systems and external sources via an API.
10) There is no need of a bigger size team in developing the microservices.
What are the Drawbacks of Microservices Architecture?
1) Microservices Architecture includes a complexity, just by the fact that this is the best choice for distributed systems. Complexity arises when we need to implement the inter-process communication mechanism including the additional implementation to handle partial failures.
2) Testing a microservices also becomes much more complex as compared to monolithic. For a similar test for a service you would need to launch that service and other services that it depends upon or at least configure stubs for those services. Sometimes the result of one Microservices may be used as the input of another Microservices.
3) Sometimes a minor change becomes very difficult to implement. Suppose a change impacts multiple services, then you need to plan it carefully and coordinate changes to each of the services.
4) Deployment of a microservices application is also much more complex. Each service may have multiple runtime instances. Therefore, we need to configure, deploy, scale, and monitor each instance separately.
5) Microservices architecture involves multiple tools and technologies to develop. So, architecture becomes very big and it takes a bit more development time as compared to the monolithic architecture.
6) Even Runtime Environment needs very high configuration and tools such as AWS Cloud, Google Cloud, Azure Cloud, PCF Cloud etc.
7) Maintenance is also very Complex and Cost Effective. Multiple Log files, Admin UI (Actuator), Communication chains, Debug Application etc.
What are the different Spring Cloud projects we use to develop a microservices based Java Application?
Below is the list of Spring Cloud projects that we generally use while developing a microservices based Java Application. As the new development is always going on, therefore this list is not fixed. In the future, some projects may go out and some other new projects may come in.
1) Spring Cloud Eureka : One Microservice can find and communicate with other Microservice using the Registration with Eureka only. When it gets published by Eureka Server, other Microservices can discover it for further communication. This concept is combinedly called Service Registry and Discovery. It becomes possible with the help of ‘Registry and Discovery Server’ (R&D Server) i.e. Netflix Eureka.
2) Spring Cloud Open Feign : We make use of Feign Client in microservices intra-communication. Furthermore, if any Microservice incorporates Load Balance Support (multi-instances), then we need to use Load balancer Client (i.e. Feign Client)
3) Spring Cloud Config Server : Common properties having similar values must be kept outside of all Microservices in a separate server using the concept of Config Server. (via GitHub, GitLab etc.)
4) Spring Cloud Gateway : In order to use all tools, we need one entry and exit point i.e. API Gateway. The API gateway is the entry point for clients. Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end. The implementation for this concept is supported by Spring Cloud Gateway API .
5) Spring Cloud Sleuth : Sleuth provides unique ids for the request flow in the set of microservices. Further, the developer uses these ids to find out the flow of execution with the help of tools like Zipkin, ELK etc. In this way, it helps in Logging & Tracing in Microservices.
6) Spring Cloud Zipkin : We use Zipkin in two parts : Zipkin Client and Zipkin Server. Zipkin Client contains Sampler which collects data from microservices with the help of Sleuth and provides it to the Zipkin Server. We use Sleuth & Zipkin together to get the support of Distributed Logging & Tracing in microservices. For complete details & implementation of Sleuth and Zipkin, kindly visit a separate article on ‘Sleuth and Zipkin‘.
Apart from that, we use Resilience4j to support Fault Tolerance mechanism.
Explain the terms Spring Boot & Spring Cloud in the context of Microservices?
Spring Cloud: Spring Cloud is a framework designed to build microservices based applications quickly. It can help developers with service configurations, service discovery, circuit-breaking, load-balancing, distributed tracing & logging, and monitoring etc. Basically, Spring Cloud is the technology/framework which implements Microservices. In simple words, we can develop a Microservices based application with the help of Spring Cloud.
Spring Boot: Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can just run. Every Microservice internally supports all Spring boot concepts and Integrations such as MQs, Batch, Email, Camel etc. It also supports DB operations using Spring Data JPA.
What is Service Registry and Service Discovery in Microservices?
Service Registry is the process of registering a microservice with Eureka Server. In simple words, it acts as a kind of database which stores the details of all microservices involved in the entire application. Although, Eureka Server is itself a microservice. In order to enable the service registry capabilities into it, we apply annotation @EnableEurekaServer on the top of the Application’s main class. Moreover, once we apply Spring Cloud’s annotation @EnableEurekaServer, other microservices can also register here and communicate with each other via service discovery.
Service Discovery is the process of discovering other microservices in the network to make intra-communication happen. However, a microservice first connects with Eureka to discover other microservice in order to communicate with each other. Using Service Discovery concept, one microservice can discover other microservice and connect with the same via Eureka Server.
When do we set the values of two properties to false in application.properties file?
The two properties in application.properties file that we set to false are:
We set this to false when the service is itself a Eureka server. The default value of this property is true. When a service is not a Eureka server(normal microservice), we don’t need to set this property as it is true by default. Basically, this property is used to register a service with the Eureka server. When it is a Eureka Server we must set it to false because Eureka server itself can’t be registered.
If one microservice wants to communicate with another microservice by using Eureka then inside microservice we should add this property (eureka.client.fetch-registry) and set it to true. It also means that the service is discoverable to other services via Eureka server. But, inside Eureka Server we should include this property with the value false. Because, Eureka server will never try to fetch registry as it is itself having a registry.
What is Feign or Open Feign and Where do we use it?
Feign is a declarative REST Client. It makes writing web service consumer easier. Moreover, it internally generates a Proxy class at runtime using Dynamic Proxy Pattern. It actually gets Application name (Service Instance) from Eureka and supports Making HTTP calls. We should use two annotations for this concept, they are:
@EnableFeignClients : To apply at starter class
@FeignClient(name=”ApplicationName”) : To define an interface for a Consumer
In the REST API concept, we work with two systems; where in one system represents a producer and another one as a consumer. Similarly, in microservices also, two Microservices communicate with each other and follow the Producer-Consumer model. Here, in consumer side, we use a concept ‘Feign Client’ as a better option instead of RestTemplate in order to minimize our effort of coding.
Apart from consuming REST services in an easy way, FeignClient/OpenFeign when combined with Eureka also provides us an easy load balancing.
What is Spring Cloud Config Server & Why do we use it?
Spring Cloud Config is a starter project to store common configurations of all the microservices used in the application. It is integrated with Spring Boot and provided by Spring Cloud. When we create a Spring Boot Project and include the dependency of Spring Cloud Config in order to deal with configuration management, it acts as a dedicated Spring Cloud Config Server. In other words, it acts as a central configuration server that provides configurations (properties) to each microservice connected to it.
When we deal with hundreds of services and potentially thousands of configurations in microservices based applications, managing all of them can be a concern. Here Spring Cloud Config Server comes into the picture and makes a developer’s life easy by offering a common place for all common configurations. Apart from that, it provides the ability to refresh the configuration of a microservice without redeploying the configuration changes. We apply @EnableConfigServer annotation at the main class of the Application to recognize that this application will act as a Spring Cloud Config Server.
Moreover, it promotes code reusability and removes code repetition. By using Spring Cloud Config Server, we have a centralized configuration. Therefore, we don’t need to write the same set of properties in multiple microservices. Instead, write them at one place and access from any microservice.
What is Spring Cloud Config Client?
Although, Spring Cloud Config Server is a very common term among microservices developers. On the other hand, we also have Spring Cloud Config Client which utilizes the services provided by Spring Cloud Config Server. Technically, these are microservices or Spring Boot Applications that take immediate advantage of the Spring Cloud Config Server. In order to connect with Config Server, we provide the entry of Config Server in the application.properties file of Config Client.
In simple words, Spring Cloud Config Clients are the microservices who stores their common configurations on Spring Cloud Config Server.
What if same key is present at microservice configuration file and Config Server with different values?
Sometime you may face a situation that by mistake you have some configuration properties with the same keys in both the places: in your microservices’ application.properties file and in Github repository which is connected to your Config server. In that case, Config Server takes the higher priority.
What is Spring Boot Actuator?
In a nutshell, Spring Boot Actuator is a starter project (sub-project) of the Spring Boot Framework. We also use this to monitor & get health checks of a production-ready application. Moreover, it offers various services as part of monitoring such as understanding the traffic, knowing the state of the database, knowing the application environment, gathering of metrices and many more. It uses HTTP endpoints to expose these operational information about any running application.
In order to enable Spring Boot actuator endpoints to our Spring Boot application, we need to add the Spring Boot Starter actuator dependency in our build configuration file i,e pom.xml (Maven Users).
What is RefreshScope?
RefreshScope is a class under Spring Cloud that allows for beans to be refreshed dynamically at runtime (see refresh(String) and refreshAll()). If a bean is refreshed then the next time the bean is accessed (i.e. a method is executed) a new instance is created. Spring Cloud offers @RefreshScope annotation to implement it in the project.
If we talk about implementation, it is nothing but an endpoint (/refresh) of the Spring Boot Actuator which helps to load the configuration properties value from the Config server. It is provided by Spring Cloud. Additionally, we need to add the @RefreshScope annotation to our main class of Spring Boot application.
What is Spring Cloud Gateway?
Spring Cloud Gateway is a starter project provided by Spring Cloud. It provides an API Gateway built on top of the Spring Ecosystem, including: Spring 5.x, Spring Boot 2.x, Spring WebFlux and Project Reactor. Spring Cloud Gateway targets to offer a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.
Spring Cloud Gateway works on the Netty server provided by Spring Boot and Spring Webflux. It does not work in a traditional Servlet Container like Tomcat. Therefore, when we start a Spring Boot Gateway application, it automatically starts with Netty server.
What is an API Gateway?
An API Gateway is a single entry & exit point to multiple microservices for an external application/client. Sometimes it is also called Edge Microservice. Since external clients are restricted to access the microservices directly, it acts as a mediator between external clients & the collection of microservices. In a real world scenario an external client could be: Desktop application, Mobile Application, Any third party app, External services etc.
Why do we need an API Gateway?
In a Microservice based Application, the different services are generally deployed on the different hosts/servers. In this case client needs to remember the host & port of the service for the interaction which is very tedious and also there are chances of security breach. Hence, API Gateway validates the authentication, uses its intelligence & routes the client request to the appropriate service to process accordingly. Apart from the security & routing, it helps in monitoring/metrics, and resiliency.
What are the advantages of an API Gateway?
1) External clients don’t need to pass through the authentication of each & every microservice. External client only needs to pass authentication of only one microservice at the beginning which is the API Gateway. If authentication gets rejected at API Gateway, the request will not proceed further to any other microservice. Therefore, it improves the security of the microservices as we limit the access of external calls to all our services.
2) We don’t need to expose the endpoints of microservices to the external application/client.
3) It provides an abstraction between microservices and the clients. The client does not know about the internal architecture of our microservices system. Client will not be able to determine the location of the microservice instances.
4) Since all client requests route through the API Gateway, we need to implement the cross cutting concerns like authentication, monitoring/metrics, and resiliency only in the API Gateway. In this way, it helps in minimizing development effort.
5) Needless to say, the API Gateway makes client interaction easy because it works as a single entry & exit point for all the requests.
What are the disadvantages of an API Gateway?
1) Since every request goes through API Gateway after a security check, it may slow down the performance.
2) Suppose we implement only one API gateway for the multiple microservices & if API Gateway fails, the request will not be processed further. Hence, we should implement multiple Gateways and manage the traffic via load balancer.
3) Sometimes we need to implement Gateway specific front-end. For example, we have three Different front-end such as Android client, iOS client, Web Client. All three may require some special APIs & configuration to work properly. To overcome this situation, we may require to create multiple types of API Gateways like one for each type of client. Some people call this pattern as ‘Back-end for Front-end’.
What is Fault Tolerance in Microservices?
In a context of Microservices, Fault Tolerance is a technique of tolerating a fault. A Microservice that tolerates the fault is known as Fault Tolerant. Moreover, a Microservice should be a fault tolerant in such a way that the entire application runs smoothly.
Which tool do you use for Fault Tolerance in Microservices?
Resilience4j is the tool to tolerate the faults in microservices. It offers us a variety of modules based on the type of fault we want to tolerate. It supports following modules to tolerate some specific type of faults.
resilience4j-circuitbreaker: Circuit breaking
resilience4j-ratelimiter: Rate limiting
resilience4j-retry: Automatic retrying (sync and async)
resilience4j-cache: Result caching
resilience4j-timelimiter: Timeout handling
What are common challenges in deploying and managing microservices in a production environment?
Some of the common challenges include:
1) Service Discovery: Keeping track of services and their locations.
2) Load Balancing: Distributing traffic uniformly across all the instances.
3) Distributed Tracing: Monitoring and debugging across service limitations.
4) Data Consistency: Ensuring data consistency in distributed databases.
5) Security: Implementing security reliably across all the services.
For various training & certifications, you may visit examlabs.com