Microservices Architecture is one of the fastest growing software in technology world. Big companies like Amazon, Netflix, Google etc use Microservices based architecture. This course is designed to help you achieve your goals in Microservices field. Software Engineers with Microservices knowledge may get more salary than others with similar qualifications without Microservices knowledge.
In this course, you will learn how to handle interview questions on Microservices technology in Software Design and Development. I will explain you the important concepts of Microservices architecture.
You will also learn the benefits and use cases of Microservices in this course.
What is the biggest benefit of this course to me?
Finally, the biggest benefit of this course is that you will be able to demand higher salary in your next job interview.
It is good to learn Microservices for theoretical benefits. But if you do not know how to handle interview questions on Microservices, you can not convert your Microservices knowledge into higher salary.
What are the topics covered in this course?
We cover a wide range of topics in this course. We have questions on Microservices best practices, Security, Pact, Bulkhead Design Pattern etc.
How will this course help me?
By attending this course, you do not have to spend time searching the Internet for Microservices interview questions. We have already compiled the list of the most popular and the latest Microservices Interview questions.
Are there answers in this course?
Yes, in this course each question is followed by an answer. So you can save time in interview preparation.
What is the best way of viewing this course?
You have to just watch the course from beginning to end. Once you go through all the videos, try to answer the questions in your own words. Also mark the questions that you could not answer by yourself. Then, in second pass go through only the difficult questions. After going through this course 2-3 times, you will be well prepared to face a technical interview in Microservices architecture.
What is the level of questions in this course?
This course contains questions that are good for a Fresher to an Architect level. The difficulty level of question varies in the course from a Fresher to an Experienced professional.
What happens if Microservices technology changes in future?
From time to time, we keep adding more questions to this course. Our aim is to keep you always updated with the latest interview questions on Microservices.
What are the sample questions covered in this course?
Sample questions covered in this course are as follows:
This course contains most popular Microservices interview questions. We have provided answers to these questions in our videos. Some videos contain more than one question.
Steps to be followed to master Microservices interview questions are as follows:
A Microservice is a small and autonomous piece of code that does one thing very well. It is focused on doing well one specific task in a big system.
Microservices provide many benefits. Some of the key benefits are:
Microservices is a newly growing domain, so there is no fixed list of principles of Microservices. Some of the major principles are:
Architects, in Microservices architecture, play the role of Town planners. They decide in broad strokes about the layout of the overall software system.
They help in deciding the zoning of the components. They make sure components are mutually cohesive but not tightly coupled. They need not worry about what is inside each zone.
Since they have to remain up to date with the new developments and problems, they have to code with developers to learn the challenges faced in day-to-day life.
They can make recommendations for certain tools and technologies, but the team developing a micro service is ultimately empowered to create and design the service. Remember, a micro service implementation can change with time.
They have to provide technical governance so that the teams in their technical development follow principles of Microservice. At times they work as custodians of overall Microservices architecture.
Service Oriented Architecture (SOA) is an approach to develop software by creating multiple services. It creates small parts of services and promotes reusability of software. But SOA development can be slow due to use of things like communication protocols SOAP, middleware and lack of principles.
On the other hand, Microservices are agnostic to most of these things. You can use any technology stack, any hardware/middleware, any protocol etc. as long as you follow the principles of Microservices.
Microservices architecture also provides more flexibility, stability and speed of development over SOA architecture.
You can create shared libraries to increase reuse and sharing of features among teams. But there are some downsides to it.
Since shared libraries are implemented in same language, it constrains you from using multiple types of technologies.
It does not help you with scaling the parts of system that need better performance.
Deployment of shared libraries is same as deployment of Monolith application, so it comes with same deployment issues. Shared libraries introduce shared code that can increase coupling in software.
Q. What are the characteristics of a Good Microservice?
Good Microservices have these characteristics:
a. Loose coupling: A Microservice knows little about any other service. It is as much independent as possible. The change made in one Microservice does not require changes in other Microservices.
b. Highly cohesive: Microservices are highly cohesive so that each one of them can provide one set of behavior independently.
c. Bounded Context: A Microservice serves a bounded context in a domain and communicates with rest of the domain by using an interface for that Bounded context.
d. Business Capability: Microservices individually add business capability that is part of big picture in organization.
A bounded context is like a specific responsibility that is developed within a boundary. In a domain there can be multiple bounded contexts that are internally implemented. Eg. A hospital system can have bounded contexts like- Emergency Ward handling, Regular vaccination, Out patient treatment etc. Within each bounded context, each sub-system can be independently designed and implemented.
Sharing a common database between multiple Microservices increases coupling between them. One service can start accessing data tables of another service. This can defeat the purpose of bounded context. So it is not a good idea to share a common database between Microservices.
In Orchestration, we rely on a central system to control and call various Microservices to complete a task. In Choreography, each Microservice works like a State Machine and reacts based on the input from other parts.
Orchestration is a tightly coupled approach for integrating Microservices. But Choreography introduces loose coupling. Also, Choreography based systems are more flexible and easy to change than Orchestration based systems.
Orchestration is often done by synchronous calls. But choreography is done by asynchronous calls. The synchronous calls are much simpler compared to asynchronous communication.
In REST over HTTP, it is difficult to generate a client stub.
Some Web-Servers also do not support all the HTTP verbs like- GET, PUT, POST, DELETE etc.
Due to JSON or plain text in response, performance of REST over HTTP is better than SOAP. But it is not as good as plain binary communication.
There is an overhead of HTTP in each request for communication.
HTTP is not well suited for low-latency communications. There is more work in consumption of payload. There may be overhead of serialization, deserialization in HTTP.
Yes, Microservices are independent entities that serve a specific context. For that context, the Microservice can work as a State Machine. In a State Machine, there are lifecycle events that cause change in the state of the system.
Eg. In a Library service, there is a book that changes state based on different events like- issue a book, return a book, lose a book, late return of a book, add a new book to catalog etc. These events and book can form a state machine for Library Microservice.
Reactive Extensions is a design approach in which we collect results by calling multiple services and then compile a combined response.
These calls can be synchronous or asynchronous, blocking or non-blocking.
It is also known as Rx.
Rx works opposite to legacy flows. It is very popular in distributed systems. You just react to the response received from another Microservice.
DRY stands for Don’t Repeat Yourself. It promotes concept of code reusability. Due to which people develop libraries and share these libraries. This sharing can result in tight coupling. DRY should be a concern within a Microservice implementation. But across 2-3 Microservices, you can ignore the DRY.
Semantic Versioning is a type of software versioning that is easy to understand by the users of that software. In this specification, each software version is specified in the format of Major.Minor.Patch.
Major version increment means that the changes to software are not backward compatible.
Minor version increment means that new functionality is added but changes are still backward compatible.
Patch version increment means that a fix to bug is provided in this version.
It is very well described on site http://semver.org
Semantic Versioning is the recommended versioning scheme for Microservices development and release.
It also helps in managing dependencies across multiple Microservices.
If an organization’s core work is related to the software to be developed then a Microservice should be built. Eg. A hospital management company can build Microservice for Doctor/Patient checkin etc. But it can buy off the shelf software for managing parking lot.
Investment in building and maintaining a Microservice in house is worthwhile, if it becomes an asset over time for the organization.
Continuous Integration (CI) is a software development approach in which developers merge their code into a common repositories several times in a day. To merge the code, every check in should run build and run a set of tests that ensures that common repository is always ready for deployment.
CI provides the benefit of early feedback for any code that is developed and merged into common repository.
There are many tools for CI that help in running build, running tests and providing feedback back to developer checking in code.
Continuous Delivery (CD) is an approach in which we treat every check in to common repository as a release candidate. CD helps us in getting code ready for deployment with every check in.
CD involves compiling code, running unit tests, doing UAT and performance tests so that code is of such a good quality that it can be deployed with confidence.
CD also reduces time between releases, as well as it increases agile nature of overall software development process.
Ubiquitous language (UL) is a term used by Eric Evans for Domain Driven Design. UL is a common language used by developers and users for common specification for the domain that they are working on. It is a rigorous language in which domain can be explained easily.
UL brings all the team members on the same page. UL has to be a crystal clear language so that it can be translated into software that a machine can understand.
When we deploy Single Service on a Host, then we get the benefit of avoiding single point of failure. A failure on one host will only impact one service at a time.
It also makes monitoring and security easier than multiple services on one host.
Single Service per Host is also easier to scale in case we want a specific service to be scaled up.
In Microservices approach there are multiple Microservices, so testing can become quite complex. In such a scenario it is better to divide tests into different levels.
At the bottom level are Technology facing tests like- unit tests and performance tests. Often, these are completely automated.
In the middle level we have tests for exploratory testing like- how to break the system. Running stress tests and usability tests.
At the top level are acceptance tests that are fewer in number. These acceptance tests help stakeholders in understanding and verifying software features. Some of these tests can be manual tests.
Non-Deterministic Tests (NDT) are unreliable tests. Some times they pass and some times they fail. When they fail, you re-run them and then they pass. Therefore, their results are not consistent. There are some suggestions from Martin Fowler to remove non-determinism from tests.
PACT is an open source tool to allow testing interactions between service providers and consumers in isolation against a contract.
It is a tool to implement Consumer Driven Contract in Microservices.
By using PACT you can test the consumer driven contracts between consumer and provider of a Microservice. It is an automated suite to test this interaction that increases the reliability of Microservices integration.
Deployment and Release are two separate events for Microservices. One way of doing this is blue/green deployment. In this case, there are two versions of a Microservice deployed at a time. But only one version is taking real requests. Once the other version is tested well, then we switch the versions.
We can run a smoke test suite to verify that the functionality is running correctly in newly deployed version. Based on results of smoke test, newer version can be released to become the live version.
In this way, we just separated deployment from release.
Canary Releasing is a technique to direct a small set of users to newly deployed version to verify that release is working as expected. Once we are satisfied, then we can gradually increase traffic to new version. Finally the old version is phased out.
In Canary Releasing two versions coexist for a longer period of time than blue/green deployment.
If a release goes bad, we need to repair it. The average time taken to repair a release is Mean time to repair (MTTR). On the other hand, we can choose an approach in which we just discard the new release and replace it with the old release. So there will be a time period in which new release failed. But the old one quickly replaced it. This is known as mean time between failures (MTBF).
In Microservices architecture, instead of spending too much effort in making the service so robust with enormous amount of test cases, we focus on MTBF. i.e. If one version of a service doing well and the newer version fails, then we just replace it with the previous one quickly and later on fix the newer version.
Cross-functional testing is verification of non-functional requirements. These requirements are such characteristics of system that cannot be implemented like a normal feature. Eg. Number of concurrent users supported by system, usability of site etc.
Cross-functional testing is related to cross-functional requirements. Often business users do not specify cross-functional requirements in the beginning. But they expect these when software is complete and deployed to production. It is always a good idea to ask business users about such cross-functional expectations in initial phase of the project itself.
Graphite is an open source database that captures metrics from services in a time series database. By using Graphite we can capture essential metrics of multiple Microservices simultaneously. And we can use a dashboard like- Grafana to monitor these metrics in almost real time.
Graphite is also great at handling large amount of data. It can also show the trends from few hours to few months within a few seconds. Many organizations like- Facebook etc use Graphite for monitoring.
At times after the deployment we want to make sure that complete end to end system is working fine. To achieve this we can create a Synthetic Transaction that is hidden from outside world, but it can test actual functionality of the system.
This synthetic transaction moves across multiple services, and each services processes it. Finally, we get complete end result for this Synthetic Transaction. Based on the end result received after processing of this transaction we can confirm that system is working as expected. This technique of verifying semantic correctness of the system is known as Sematic Monitoring.
In Microservices architecture, if there is a failure in one Microservice, then we may have to go to upstream Microservice to find the source of failure. Or we may have to go to downstream Microservices to find the impact of the failure. Since each Microservice is independent, we need some relation between the error in a service as well as the error in its upstream/downstream services.
To resolve this issue, we can use Correlation IDs. These are unique IDs like GUID that are passed from one service to another service during an API call. By using a GUID and failure associated with it we can find the source of failure as well as the impact of failure.
Authentication is the process of verifying credentials of a user. It checks whether a user is genuine or not by checking identity of a user. Most common way of Authentication is a User/Password check.
Authorization is the process of checking whether a user has access to resources or not. There can be different levels of authorization in a Microservice. Eg. Some users may just have read access. Some user may have write access to certain parts.
The correct mix of Authorization and Authentication is important for implementing security features in a Microservice.
HTTPS is also known as HTTP Secure. This protocol ensures that all communication between Microservices is secure and encrypted. It is used for handling confidential information between Microservices.
In HTTPS, client is assured that the Server it is talking to is a genuine server. To do so, HTTPS uses SSL certificates.
Also encrypting the request and response helps in avoiding eavesdropping. SSL ensures that all communication is encrypted and decrypted in a secure way. The drawback for encryption is that it cannot be used in proxy caching.
Client certificate is another form of security that is implemented at Transport Layer instead of Application layer. Each client installs a X.509 certificate locally. This ensures that server can rely on the validity of client, if it has right certificate.
It is more complex than SSL, since it has to manage certificates at all clients.
Q. Why some big companies use API keys for providing access to public APIs?
Many big companies like- Google, Amazon etc provide public APIs to developers. These APIs come with an API key. This API key is used for various purposes:
I. An API key can authenticate a client
II. An API key can impose limits of number of calls to API
III. An API key can limit the access of a client to certain APIs only
IV. An API key can introduce security in Service call between client and provider
In Microservices world, Confused Deputy is a computer security problem. In this case one service acts as deputy and accepts authenticated requests from other clients to perform an action. Sometimes, one malicious client can hack the system and send a falsely authenticated request. Since the request is authenticated, deputy will do the same action for malicious client. This can breach the security of the system.
Eg. Let say a service depends on barcode to get the price. If a client provides incorrect barcode, the service will provide incorrect price, since it relies on the authenticity of barcode.
Implementing security in Microservices architecture has its own challenges. Since there are multiple Microservices and many interfaces between them it is important to consider following aspects for implementing correct security in Microservices architecture:
I am a Software Architect with expertise in Cloud Computing, Amazon Web Services, Microservices, Data Science, Hadoop, Spark, Machine Learning and Java architecture. Learning, using and sharing Technology is my passion.
I have built systems that are running enterprise software of companies across the world. I have gained a lot of knowledge by working hands-on on these large scale software projects.
With these courses I aim to share my knowledge with the future Software Engineers, Developers, Leaders and Architects .
I am sure the knowledge in these courses can give you extra power to win in life.
All the best!!