Microservices

Last Updated on July 9, 2023 by KnownSense

1. What are Microservices?
Microservices is an architectural style which structures and application as a collection of loosely coupled, independently maintainable, testable and deployable services which are organized around business capabilities. 
If you have a business focus and you want to solve a use case or a problem efficiently without the boundaries of technology, want to scale an independent service infinitely, highly available stateless services which are easy to maintainable and managed as well as independently testable then we would go ahead and implement Microservices architecture.

2. What are the features of Microservices architecture?

1. Decoupling – Services within a system are largely decoupled. So the application as a whole can be easily built, altered, and scaled
2. Componentization – Microservices are treated as independent components that can be easily replaced and upgraded
3. Business Capabilities – Microservices are very simple and focus on a single capability
4. Autonomy – Developers and teams can work independently of each other, thus increasing speed
5. Continous Delivery – Allows frequent releases of software, through systematic automation of software creation, testing, and approval
6. Responsibility – Microservices do not focus on applications as projects. Instead, they treat applications as products for which they are responsible
7. Decentralized Governance – The focus is on using the right tool for the right job. That means there is no standardized pattern or any technology pattern. Developers have the freedom to choose the best useful tools to solve their problems
8. Agility – Microservices support agile development. Any new feature can be quickly developed and discarded again

3. What are the characteristics of Microservices?

a) Organized on business capabilities: Since you have individual microservices, it means that you have an application that works on its own. You also have a database that corresponds to individual microservices, which means if you have 10 microservices, you will have 10 individual databases that are corresponding or answering only to that particular microservice.
This gives you a complete decentralized structure, and this also means better organization because every microservices is very clear what it is supposed to do. It has all the resources in that single container, i.e. this is to be done and this is what we are focused on. That is how this organization or better management comes into the picture.

b) Products and not projects: Suppose you have 10 microservices, you’ll be having small clusters of the team that would build up this application and also maintains it. What Amazon thinks is you should have a two-pizzas team. This means you should have such a small team that can survive on two pizzas, and you should also be able to maintain the software.
Every responsibility as far as software and application are concerned is given to that size of a team that can survive on two pizzas. This ensures modularity. When you talk about microservices, basically you’re talking about a product. When you talk about a team focused on a particular functionality, that functionality is not a project for them, it is more of a product for them.

c) Smart endpoints and dumb pipes: This means that you have different applications and they’re quite decentralized and there has to be a way of communication. You should have smart endpoints and good ways to integrate your applications with each other.

d) Decentralized governance: Discussed earlier.

e) Decentralized data management: This means you are free to have an individual approach where you have your own database and your single database in your microservices treated as an individual entity or a container.

f) Infrastructure automation: Since we already have so many microservices, it is important that there is proper automation. This ensures speedy development and also maintenance.

g) Design for failure: Applications are built such that they do not hamper the progress of any applications, even when they fail. Despite that, you need to have a mechanism that takes care of failure as well. There is the need to have real-time monitoring and analysis, which ensures that if an application goes down, the fastest possible action is taken so that the application runs again and does not hamper the working of any other applications

4. When should Microservices architecture be considered?

• If you already have a monolith application and it grows to an extent where there are problems in scaling or we are not able to reutilize the components/modules/services across different projects/platforms and there is a need to do so. As well as at the same time implementing new features is painful and more error-prone and it is difficult to scale further.
• For new applications where implementation has not started yet started, we can think of a business case to be efficiently implemented, which can be easily maintainable, testable and scalable in the future and might be used across other projects/products/platforms at the same time.

5. What is Domain Driven Designing (DDD) concept?
This is an approach that actually helps you collaborate with all the teams together, and to a great extent, makes the development of complex applications easier.
The three main pillars of DDD principles are:

• Focus on the core domain and domain logic.
• Trace the complex design of the business domain’s models.
• Resolve business domain problems, make the application domain better by having regular consultations with the business domain experts.

At times, you let go of what is right for you. Rather, you focus only on the business domain. This means that the focus should be on what the business domain needs, and this is what we would include in this architecture. This kind of approach is called domain-driven design. DDD tries to bring again everything on the same page through the use of a ubiquitous language, which helps you achieve this domain-driven design approach. A ubiquitous language should be designed in such a way that it focuses around a particular domain, and the architecture that is developed out of it is referred to as a domain-driven architecture.

6. Why is there a need of DDD?

• Mapping to a domain: We are mapping our architecture to a particular domain.
• Testability: Testing the application becomes easier.
• Maintainability: Maintaining the application also becomes easier because everybody is on the same page.
• Knowledge-rich design: These applications are very heavy on knowledge.
• It brings business and service together.
• Context focused: Very much focused on a particular domain.
• Uses ubiquitous focussed.
• Reduced complexity.

7. What is ubiquitous language?
Suppose we have a ticket reservation system for a flight. The ubiquitous language will be all the terminologies that would be related to airplanes, flight attendants, customers, etc. The manager should be able to comprehend the architecture. He should be able to understand the terminologies that are being used, and the same applies to the developers, too. This means that we are bringing every team on the same page, and a language that does that is referred to as a ubiquitous language.

8. Explain the advantages and disadvantages of Microservices Architecture?

Pros of Microservice Architecture	Cons of Microservice Architecture
Freedom to use different technologies	Increases troubleshooting challenges
Each microservices focuses on single capability	Increases delay due to remote calls
Supports individual deployable units	Increased efforts for configuration and other operations
Allow frequent software releases	Difficult to maintain transaction safety
Ensures security of each service	Tough to track data across various boundaries
Mulitple services are parallelly developed and deployed	Difficult to code between services

9. Explain difference between Service Oriented Architecture (SOA), Monolithic and Microservices architecture?

• Monolithic Architecture is similar to a big container wherein all the software components of an application are assembled together and tightly packaged.
• A Service-Oriented Architecture is a collection of services which communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.
• Microservice Architecture is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

10. What are the challenges implementing Microservices?
Developing a number of smaller microservices sounds easy, but the challenges often faced while developing them are as follows.

• Automate the Components: Difficult to automate because there are a number of smaller components. So for each component, we have to follow the stages of  Build, Deploy and, Monitor.
• Perceptibility: Maintaining a large number of components together becomes difficult to deploy, maintain, monitor and identify problems. It requires great perceptibility around all the components.
• Configuration Management: Maintaining the configurations for the components across the various environments becomes tough sometimes.
• Debugging: Difficult to find out each and every service for an error. It is essential to maintain centralized logging and dashboards to debug problems