Microservices Interview Questions- Part 3

Answer:

1. Idempotence means a task that has been performed repeatedly, but the end result remains the same. It is mostly used as a remote service or a data source so that when it receives instruction multiple times, it only processes the instruction once.
2.  Idempotence is a scenario where you perform a task again & again, but the result always remains constant. It is mostly used as a remote service or a data source in a way that when it receives more than one instruction, it processes instruction only once.

Answer:

1. Here are a few tools for managing the Microservices Architecture:
   1. MongoDB: Being an open-source document-based distributed database, it stores data in the JSON format having a different structure for different documents. It also supports various programming languages like C#, C++, PHP, C, PERL, Java, Python, Scala, Ruby, etc.
   2. Elasticsearch: It refers to a full-text search engine.
   3. KAFKA: It is an event queue system that processes all transactions & avoids the web-like random interactions amongst different services. Kafka offers a clean & robust Microservice Architecture.
   4. JENKINS: It is an automation tool that allows CI/CD (Continuous Integration & Continuous Development). It supports an array of plugins & easily integrates with every tool.
   5. DOCKER: Application development & deployment environment varies in several aspects. It gives rise to deployment issues. Docker provides a static background for all the applications to run, thus avoid such deployment issues.
   6. KUBERNETES: With thousands of services running in an application, Kubernetes manages or orchestrates the entire process as an engine.
   7. JAEGER: It is an end-to-end, open-source distributed tracing tool that monitors distributed transactions. It also helps in performance optimization & finds dependencies between the services. Besides, it provides the root cause analysis.
   8. FLUENT: In a multiservice architecture, all different systems are managed through different databases, programming languages, and operating systems, so it becomes difficult to logging & keeping track of it. Fluent offers a single logging layer & streamlines this issue. Logs can also be collected & aggregated into a data source.
   9. PROMETHEUS: It is a monitoring tool that enables you to check if all services are working fine after an app deployment. It is a time-series data store that collects metrics from an application & displays it in a graphical format.
   10. Grafana: Grafana provides analytics & monitoring into different visualization formats such as charts, graphs, tables, etc.
2. • Docker is a tool that streamlines the process of creating, deploying, and running applications using containers. Containers enable developers to package an application with all essential parts like libraries & other dependencies & deploy them in one package.
   • Kubernetes refers to an open-source container orchestration system to automate app deployment, management, & scaling.
   • OpenShift PaaS platformis a combination of Docker & Kubernetes clusters. OpenShift’s architecture was designed in a way that it can manage & support Docker containers hosted on top of layers using Kubernetes.
   • Istio reduces the complexity of handling Microservices deployments by providing a uniform way to connect, secure, & monitor them.

Answer:

1. Each Microservice has its database that can be deployed independently. It allows the creation of State Machines to specify different events & states for a particular Microservice. The state transitions are defined as a result of different events.
2. As each Microservice owns a separate database, it is an independently deployable program unit, that allows us to create a State Machine. Thus, we can specify different states & events for a specific Microservice.

Answer:

1. • Failure to outline main challenges.
   • Rewriting already existing programs.
   • Vague definitions of timelines, responsibilities, and boundaries.
   • Failure to identify & implement automation.
2. Some of the common transitioning mistakes are:
   • Developers fail to outline the current challenges.
   • Rewrite programs that already exist.
   • Not defining timelines, responsibilities, and boundaries properly.
   • Failing to implement & finding the scope of automation from the beginning.

Answer:

1. WebMvcTest Annotation is used to conduct unit testing of Spring MVC Applications, where the test mainly focuses on Spring MVC Components.
2. WebMvcTest annotation is used for unit testing Spring MVC Applications, where the test central objective is to focus on the Spring MVC Components.

Answer:

1. • It requires heavy investment: Microservices demands a lot of collaboration as your teams work independently; they should synchronize well all the time.
   • Heavy architecture set up: The system is distributed, so the architecture is involved heavily.
   • Excessive planning for managing operations overhead: You should be ready for operations overhead if you plan to use Microservices.
   • Autonomous staff selection: Skilled professionals are required who can support Microservices distributed heterogeneously.
2. • Requires heavy investment– It needs a lot of cooperation. Your teams should be efficient enough to update well at times as they operate independently.
   • Heavy architecture set up- The whole system is usually spread & the architectural style is strong.
   • Excessive planning needed to handle operations overhead– If you intend to utilize Microservices, you should be prepared for the overhead operations.
   • Autonomous staff selection– Qualified experts & professionals are needed to provide support for heterogeneous Microservices.

Answer:

1. Here are some challenges faced for testing Microservices:
   • The tester should have an in-depth understanding of all outbound & inbound processes, writing test cases for integration.
   • When independent teams work on different functionalities, collaboration can be quite a difficult task. So, it can be difficult to find an idle time window to perform complete regression testing.
   • With an increasing no. of Microservices, the complexity of the system also increases.
   • During the transition from monolithic architecture, testers must ensure that there is no disruption between the internal communication among the components.
2. • Testers should have an extensive understanding of all the inbound-outbound processes before starting writing test cases for the integration testing.
   • When independent teams work on different functionalities, collaboration can prove to be a struggling task. It can be difficult to find an idle time window to perform a complete round of regression testing.
   • With an increasing no. of Microservices, the system complexity also increases.
   • Testers must ensure there is no disruption between the internal communications amongst the components during the transition from the monolithic architecture.

Answer:

1. The following are the fundamentals to a successful Microservice design:
   • Define the scope of functionality;
   • Combine loose coupling with the high cohesion;
   • Create a unique service that can act as an identifying source, like a unique key in the database table;
   • Create correct API during integration;
   • Restrict access to data & limit it till the required level;
   • Maintain a smooth flow between the response & requests;
   • Automate most processes to minimize time complexity;
   • Keep the no. of tables to a minimum level to reduce space complexity;
   • Monitor architecture constantly & fix a flaw when detected;
   • Datastores should be separated for each Microservices;
   • There should be an isolated build for each Microservices;
   • Deploy Microservices into containers;
   • Servers must be treated as stateless.
2. Use the following key Microservices design principles to build applications:
   1. Ensure low coupling & high cohesion: Cohesion & coupling are two different terms often used interchangeably when describing Microservices. The former denotes the degree of interdependence between multiple modules of an application, while the latter denotes the degree of interdependencies. You should design Microservices in such a way that cohesion is high & the coupling is low. It creates scalable Microservices adaptable to change & can be extended over time.
   2. Define the scope properly- You must define Microservices’ functionality, describing what it will do. The scope of Microservices corresponds to the requisites of an independent business module. Therefore, it is essential to set a scope for each Microservice to rationalize its size & define its boundaries.
   3. Adhere to a Single Responsibility Principle- The Single Responsibility Principle implies that a class must never have more than one reason for the change. This principle is essential to design a Microservices-based application, as there must not be multiple responsibilities in a single Microservice.
   4. Design for the failure- One central objective of Microservice Architecture is to create resilient & fault-tolerant systems. Performance issues or failure in service should not affect the other services. An issue like a memory leak or database connectivity problem in a Microservice should not bring down the entire application. Since services in a Microservices-based application are independent & autonomous, they can leverage the circuit breaker pattern, which is the means to cut off communication with one or more services experiencing errors or that are down.
   5. Build around the business capabilities- Each Microservice must be designed to solve a business problem. A developer can avail an appropriate technology stack for each business problem in each Microservice. Thus, unlike a monolithic application, you’re not restricted to use only one best-fit homogenous technology stack for the entire architecture. This principle lets developers choose the best & readily available technology stack for every application’s component.
   6. Decentralize data- Unlike, in monolithic apps, each Microservices Architecture maintains a copy of data or has its own database. You should not set multiple services to share or access the same database, as it defeats the purpose of autonomous Microservice operation.
   7. Gear up process automation- A Microservices design can be deployed in several units, which an application team should manage. One can automate the deployment process for the Microservices-based components by using smart iterative release tooling, like a CI/CD pipeline coupled with a DevOps culture.
   8. Enable interservice communication- When you migrate to Microservices from a monolithic application, you must break all the interrelated components. The services require a way to communicate. Microservices apps enable diverse approaches & programming languages, so an app can have services built with different technologies communicating to each other & APIs can make it all work.
   9. Monitor constantly- Microservices in production are interrelated & distributed. It is a daunting task to manually discover the errors. So, there is a need for an automated monitoring system that can constantly track performance. As a part of the Microservices design & deployment process, set or select a tool that analyzes & captures data on services’ performance & generates useful metrics.
   10. Manage traffic- Traffic to a Microservices application differs from one to the other. A service might have huge traffic while another may be low-demand on the network. In each traffic scenario, performance is yet another important factor. You can avail circuit breaker patterns & autoscaling to maximize performance.

Answer:

1. Bounded context refers to a central pattern usually seen in the domain-driven design (DDD). It is the main focus of the DDD’s strategic design section. DDD works with huge models by disintegrating them into multiple bounded contexts. While doing so, it explicitly explains the relationship between them.
2. Bounded Context is the central pattern in (DDD) Domain-Driven Design. DDD’s strategic design section mainly deals with large teams & models by dividing them into different Bounded Contexts & by being explicit about their inter-relationships.

Answer:

1. Microservices Architecture is an architectural approach to build cloud applications. Each app is built as a set of services, & each service runs in its processes & communicates through APIs. The services structure concept is older than containers & dates before the modern web application era.
2. Microservices refer to a set of services that act together to operate the entire application. Microservices architecture deploys APIs to transfer information like data stream or user queries from one service to another. How the Microservices Architecture works, or on which hardware it gets built, depends solely on the development team. It makes communication between teams & upgrading services dynamic & reactive, enabling a software team or company to be more resilient in development.

Answer:

1. Ubiquitous Language or UL is a common language that developers & users to easily explain a specific domain. This language needs to be crystal clear to bring all team members on the same page. It should also translate in such a manner that the machine can understand it.
2. Ubiquitous language, abbreviated as UL, is a common language used by developers & users for a common specification of the domain. It is a rigorous language in which the domain can be easily explained. UL brings all team members to the same page. It has a crystal-clear language translated into software that a machine can understand.

Answer:

1. REST or RESTful stands for Representational State Transfer web services. It is an architectural style to help computer systems communicate via the internet. It makes Microservices easier to implement & understand. Microservices can be implemented with or without REST/RESTful APIs, but it is always easier to build loosely coupled Microservices using the RESTful API.
2. Representational State Transfer or REST is a software architecture style. Based on the web open networking principles, RESTful APIs provide a logical model for building interfaces between various Microservices components.

Answer:

1. When developing distributed Microservices with Spring Boot, one can face several issues that Spring Cloud solves, such as:
   • Complexity with the distributed systems includes security issues, Bandwidth issues, network issues, & Latency overhead.
   • Handles service discovery that allows services & processes in a cluster to communicate & find each other.
   • Redundancy issues often occur in the distributed systems.
   • Load balancing improves the workload distribution across multiple computing resources, like a computer cluster, central processing units, & network links.
   • Reduces performance issues due to several operational overheads.
2. • Load Balancing- When there are numerous instances of the same Microservice, you want to distribute the load between them. For that purpose, Spring Boot provides an option of Ribbon, a client-side load balancing framework.
   • Visibility & Monitoring- In Microservices Architecture, you need to have complete visibility of what is happening in your Microservice. Thus, to trace a request, you need to assign a unique identifier & Spring Cloud Sleuth can help in assigning the identifier to every request. You can utilize a distributed tracing solution like Zipkin to trace requests across multiple components.
   • API Gateway- All Microservices share a few common features such as logging, analytics, security, etc. The best place to implement the common Microservices features is an API Gateway like Netflix Zuul, which provides a great solution to any such challenge.
   • Fault Tolerance- In cases of system failure or when a Microservice shuts down, how do the other Microservices respond to it? Hystrix can help in improving the fault tolerance of your Microservice.

Answer:

1. DRY is an abbreviation for Don’t Repeat Yourself. It promotes the concept of reusing code. Thus, results in sharing & developing libraries which further results in tight coupling.
2.  DRY or Don’t Repeat Yourself is a concept that promotes code reusability. In the DRY pattern, developers shares & build libraries- such sharing results in tight coupling. DRY can be a concern within a Microservice implementation. However, across 2 or 3 Microservices, one can ignore DRY. The basic design principle behind the DRY pattern is that we should not reinvent the wheel & should not share the same wheel for different purposes.

Answer:

1. Cross-functional testing refers to a verification of non-functional requirements which cannot be implemented like a normal feature.
2. Cross-functional testing means the verification of non-functional requirements. Such requirements are those characteristics of a system that cannot be implemented like a normal feature. Often businesses don’t specify the cross-functional requirements in the beginning. However, they expect it by the end when the software is complete & deployed. So, it is better to know about any such cross-functional testing expectation in the initial stage of project development.

Answer:

1. An architect plays a crucial role in Microservices Architecture such as:
   • An architect decides broad strokes about the entire software system’s layout.
   • Helps in deciding the components zoning to ensure components are not tightly coupled but mutually cohesive.
   • He codes with developers & learns day-to-day challenges.
   • Recommends certain tools & technologies to the Microservices development team.
   • Architecture technically governs the teams, so they follow the principles of Microservices, during technical development.
2. Architects are just like town planners in the Microservices architecture. They decide in broad strokes about the overall software system’s layout. Architects help in deciding the zoning of components & ensures the components are mutually cohesive & not coupled tightly to avoid inside zoning. As architects remain updated with the new developments & problems, they code with developers to learn their day-to-day challenges in life.
   Architects also make recommendations for technologies & tools, but the development team of a Microservice is ultimately responsible for creating & designing the service. Architects need to provide technical governance so the teams in their technical development Microservice principles. Sometimes, architects also work as custodians of the overall Microservices architecture.

Answer:

1. • Smart endpoints refer to the actual business rules & other validations that happen behind those endpoints not visible to anyone. The consumers of endpoints believe it as a place where the actual magic happens.
   • Dumb pipes imply any communication where no further actions or validations take place. It just carries data across a particular channel & may be replaceable if needed. Its infrastructure is typically dumb (acts as a message router only). Thus, dumb pipes only perform the routing function.
2. Both smart endpoints & dumb pipes are design principles in Microservices that favor time-tested, basic & asynchronous communication mechanisms. Applications built with smart endpoints & dumb pipes aim to be as cohesive & decoupled as possible.

Answer:

1. • In the Blue/Green Deployment, you have two complete environments; wherein one is the Blue environment which is running & the other is the Green environment which you want to upgrade. When you swap the environment from blue to green, the traffic gets directed to the new green environment. You can save or delete your old blue environment for backup till the green environment is stable.
   • In the Rolling Deployment, you only have one complete environment. The code is deployed in a subset of instances of the same environment & moves to the other subset after completion.
2. • A rolling deployment spreads out a new software update deployment across multiple phases. It often uses several servers that perform different functions in the server cluster. Rolling deployment is effective for complex applications running on multiple servers that make up a server cluster & whose server node receives traffic via a load balancer.
   • Blue/Green deployment refers to an application release model that gradually transfers the user traffic from an application or Microservice’s previous version to a nearly identical new release, both running in production. The old version is known as the blue environment, while the new version is known as the green environment. Once the production traffic is transferred from blue to a green environment, blue can stay if pulled or rollback from production & updated to become the template on which the next update is made.

Answer:

1. Clients do not invoke Microservices directly, so they go through a Gateway. The Gateway, in turn, calls the Microservices & returns the response to the client. The Gateway can decouple the Microservices from the clients. It provides the functions like load balancing, logging, authentication, etc.
2. Customers don’t call on Microservices directly; they go via Gateway. The Gateway calls the Microservices & returns answers to the customer. It separates the customers & Microservices & also offers several functions like logging, load balancing, authentication, etc.

Answer:

1. Microservices will be automated starting from development till deployment to production with the following tools:
   • GIT will be mainly used for version control.
   • Jenkins used for CI or Continuous Integration.
   • Testing tools like Selenium, Junit will be used for automating testing.
   • Container technologies like Docker are used along with release management tools like Puppet or Chef for infrastructure management automation.
   • Deployment automation is done through tools such as Kubernetes or Spring Cloud.
2. Microservice development tools mostly divided into the following categories:
   • Team building (Jira, Slack)
   • Containerization (Docker and Kubernetes)
   • Message queuing (RabbitMQ, Amazon SQS, Apache Kafka)
   • Build & assembly (maven, ant, Gradle)
   • Programming Language (Spring Boot, Elixir)
   • Architectural Frameworks (Kong, goa)
   • Cloud deployment (AWS Lambda, AWS elastic beanstalk)
   • Application monitoring (Logstash, Graylog)
   • API Testing & management (API Fortress, Postman, TYk)