DESIGN PRINCIPLES FOR MICROSERVICES

Microservices

Microservices ?Architecture provides us the facility to handle different functions of the application individually. In the Monotholic approach, we can’t scale any particular functionality, If we need to scale any particular functionality, then we would have to scale the complete application, Hence Microservices architecture is more useful for us if we have multiple functionalities in our application and we wanted to manage them in the right manner.

??????????????BENEFITS OF MICROSRVICES

?????

• Microservices are independently deployable and allow for more team autonomy
• Microservices are independently deployable and allow for more team autonomy
• Microservices reduce downtime through fault isolation.
• The smaller codebase enables teams to more easily understand the code, making it simpler to maintain.

?

?

?

?DESIGN PRINCIPLES FOR MICROSERVICES

• Ensure high cohesion and low coupling

Cohesion?and?coupling?are two terms often used interchangeably when describing a microservices architecture. The former relates to the degree of intradependence that exists between the modules of an application, and the latter is used for the degree of interdependencies.

You should design microservices so that cohesion is high and coupling is low. This plan creates microservices that are adaptable to changes, scalable and can be extended over time.

• Define the scope properly

You should define the functionality of a microservice, describing what it is intended to do. The scope of a microservice corresponds to the requirement of an independent business module. It's important to set a proper scope for each microservice in order to rationalize its size and define its boundaries.

• Adhere to the Single Responsibility Principle

The?Single Responsibility Principle?states that a class should never have more than one reason for change. This principle is essential to designing a microservices-based application, because there should not be multiple responsibilities in a single microservice.

• Design for failure

One of the objectives of microservice architecture is to create fault-tolerant and resilient software systems.?Failure or performance issues?in one service should not affect other services. A memory leak, database connectivity problems or other issues in one microservice should not bring the entire application down.

• Build around business capabilities

Each microservice should be designed to?solve a business problem. The developer can use the appropriate technology stack for each business problem in each microservice. Unlike a monolithic application, you are not constrained to use a single best-fit homogenous technology stack for the whole architecture. This microservices design principle means developers should choose what's best and readily available for use in every component of the application.

• Decentralize data

Unlike in monolithic applications, microservices each maintain their?own copy of the data. In other words, each microservice has its own database. You should not set up multiple services to access or share the same database, since it defeats the purpose of autonomous microservice operation.

• Manage traffic

Traffic to microservices in an application differs from one to the next. One service might have huge traffic while another is low-demand on the network. In each kind of traffic scenario, performance is an important factor. Take advantage of autoscaling and circuit breaker patterns?to maximize performance.

?

??????????????????????????????Design Patterns for Microservices:-

1. Database per Microservice Pattern

Database design is rapidly evolving, and there are numerous hurdles to overcome while developing a microservices-based solution. Database architecture is one of the most important aspects of microservices.?

What is the best way to store data and where should it be stored?

There should are two main options for organizing the databases when using the microservice architecture.?

• ?Database per service
• ?Shared database

2. Event Sourcing Pattern

The event sourcing is responsible for giving a new ordered sequence of events. The application state can be reconstructed using querying the data and in order to do this, we need to reimage every change to the state of the application.?Event Sourcing?is based on the idea that any change in an entity's state should be captured by the system.?

The persistence of a business item is accomplished by storing a series of state-changing events. A new event is added to the sequence of events every time an object's state changes. It's essentially atomic because it's one action. By replaying the occurrences of an entity, its current state can be reconstructed.

An event store is used to keep track of all of your events. The event store serves as a message broker as well as a database of events. It gives services the ability to subscribe to events via an API. The event store sends all interested subscribers information about each event that is saved in the database. In an event-driven microservices architecture, the event store is the foundation.

This pattern can be used in the following scenarios,

• It's important to keep the existing data storage.
• There should be no changes to the existing data layer codebase.
• Transactions are critical to the application's success.

So as from the above discussion, it is clearly indicated that the event sourcing addresses a challenge of implementing an event-driven architecture. Microservices with shared databases can't easily scale.?The database will also be a single point of failure. Changes to the database could have an influence on a number of services.

?

3. Command Query Segmentation (CQRS)?Pattern

In the above, we have discussed what is event sourcing. In this topic, we are going to discuss what is CQRS? We can divide the topic into two parts with commands and queries.?Commands - Change the state of the object or entity.

?Queries -?Return the state of the entity and will not change anything.

?

In traditional data management systems, there are some issues,

??1. Risk of data contention

??2. Managing performance and security is complex as objects are exposed to both reading and writing applications.

So in order to solve these problems, the CQRS comes to the big picture. The CQRS is responsible for either change the state of the entity or return the result.?

?

4. Backend For Frontend (BFF)

This pattern is used to identify how the data is fetched between the server and clients. Ideally, the frontend team will be responsible for managing the BFF.A single BFF is responsible for handling the single UI and it will help us to keep the frontend simple and see a unified view data through the backend.

?

5. API Gateway

This microservice architecture pattern is really good for large applications with multiple client apps and it is responsible for giving a single entry point for a certain group of microservices.?API gateway sits between the client apps and the microservices and it serves as a reverse proxy, forwarding client requests to services.?Authentication, SSL termination, and caching are some of the other cross-cutting services it can provide.

Why do we consider the API Gateway architecture instead of using direct client-to-microservice communication? We will discuss this with the following examples,??

1. Security issues?-?All microservices must be exposed to the "external world" without a gateway, increasing the attack surface compared to hiding internal microservices that aren't directly accessed by client apps.

2. Cross-cutting concerns?- Authorization and SSL must be handled by each publicly published microservice. Those problems might be addressed in a single tier in many cases, reducing the number of internal microservices.

3. Coupling?-?Client apps are tied to internal microservices without the API Gateway pattern. Client apps must understand how microservices decompose the application's various sections.

Last but not least, the microservices API gateway must be capable of handling partial failures. The failure of a single unresponsive microservice should not result in the failure of the entire request.

A microservices API gateway can deal with partial failures in a variety of ways, including:

• Use data from a previous request that has been cached.
• For time-sensitive data that is the request's major focus, return an error code.
• Provide an empty value
• Rely on hardware top 10 value.

?

6. Strangler

The strangler design pattern is a popular design pattern to incrementally transform your monolithic application to microservices by replacing old functionality with a new service.?Once the new component is ready, the old component is strangled and a new one is put to use.

The facade interface, which serves as the primary interface between the legacy system and the other apps and systems that call it, is one of the most important components of the strangler pattern.

?

7. Circuit Breaker Pattern

The circuit breaker is the solution for the failure of remote calls or the hang without a response until some timeout limit is reached. You can run out of critical resources if you having many callers with an unresponsive supplier and this will lead to failure across the multiple systems in the applications.

So here comes the circuit breaker pattern which is wrapping up a protected function call in a circuit breaker object which monitors for failure. When the number of failures reaches a specific level, the circuit breaker trips, and all subsequent calls to the circuit breaker result in an error or a different service or default message, rather than the protected call being made at all.

Different states in the circuit break pattern

Closed?- When everything works well according to the normal way, the circuit breaker remains in this closed state.

Open?-?When the number of failures in the system exceeds the maximum threshold, this will lead to open up the open state. This will give the error for calls without executing the function.

Open?-Half - After having run the system several times, the circuit breaker will go on to the half-open state in order to check the underlying problems are still exist.?

?

8. Externalized Configuration

Often services need to be run in different environments.?Environment-specific configuration is required, such as secret keys, database credentials, and so on. Changing the service for each environment has a number of drawbacks. So how we can enable a service to run in multiple environments without modification?Here comes the Externalized configuration pattern as this enables the externalization of all application configurations including the database credentials and network location.

?

?

Best Languages for Microservices

Here is a list of the best language for microservices are:

1. Java:?Java microservices framework is a popular programming language amongst developers because it is reliable and readable. Using Java to develop microservices architecture is more advantageous. Developing Java microservices is a simple matter of understanding the solution. Its simple annotation syntax makes creating microservices architecture a breeze. Furthermore, Java is an excellent choice because it includes a user interface, connectivity to back-end resources, and model components.
2. Golang:?Go was first introduced by Google in 2009. Golang is the term given to this language because of the domain name. In a microservices architecture, the Golang microservices framework is well-known for its API support and concurrent capabilities. Its simultaneous capability also boosts the productivity of multiple devices. Further, one can build microservices easily since its feature facilitates the entire?Golang Development.
3. Python:?Microservices framework python is a high-level programming language that aggressively encourages technology integration. In contrast to other programming languages and frameworks, the python microservices framework allows for quick and easy prototyping. This means that it is the best option for developers. Python is entirely compatible with existing languages like PHP and ASP.
4. Node JS:?Node JS has become the go-to platform for organisations and businesses looking to implement microservices over the years. Because Node JS is based on the V8 runtime, microservices are possible. Also, it has progressed greatly through time. Node.js is a popular microservices framework used by developers all around the world.?Web App Development?with Node JS is also easy. Businesses depend on microservices Node.js for high performance, cheaper costs, increased productivity, and pleased developers.
5. .Net: For Microservices:?.NET is an excellent cross-platform solution. It enables you to work with a dependable and well-established language that is supported and maintained by Microsoft. Its built-in Docker containers aid in developing microservices. .NET microservices may be readily integrated with applications developed in Node.JS, Java, or any other language. This facilitates the transition to.NET core technologies.

Alongside large corporations, numerous small and medium-sized businesses and enterprises are shifting towards developing complex applications, intending to migrate from monolithic systems to a single independent Microservice architecture. Choosing the right technology and languages for your microservices is difficult. After all, the tool you choose to create distinct app pieces determines the technology you use. Furthermore, the knowledge of your employees is crucial. If you’ve decided to go the microservices route, you’ll need to find a trustworthy partner to help you accomplish your project.

Things we should keep in our Mind Before Adopting Microservices Architecture

1. Inter-Service Communication:?To execute the operation in a microservices architecture, services connect concurrently or sequentially. An inter-service communications platform orchestrates this communication.
2. Data Consistency:?Since each microservice has its own personal database, it can be difficult to ensure data consistency throughout transactions that traverse many services.
3. Security:?Both at rest or in transit, encryption technologies, as well as strong authentication and authorization systems, are available to assure data security. Furthermore, APIs must be protected by an API Gateway to prevent unauthorized users from utilizing a token to get access.
4. Monitoring:?The application’s efficiency is ensured by employing distributed transaction tracking and health check APIs to monitor the system. Teams may generate visualizations for key indicators, acquire past data for performance patterns, and receive notifications when issues develop with the correct surveillance and monitoring.
5. Quality Assurance:?Microservices manage queries by transferring messages between services, which ensures quality. With an escalation in services, automated testing is essential to verify that all exchanges and communications, especially unit tests, integration tests, contract tests component tests, are thoroughly verified.

THANK YOU FOR READING!!!!!!!!!!!!!!!