Introduction

To

Micro-Services Design Patterns

The core concepts and related design patterns

1.History Of Solution Architecture

Architecture in the old approach was focused on :

Monolithic

Mono comes from the single point, which means: The solution is one peace in deployment architecture, so you build the solution, as one unit, even, with reusable components, but you deploy all of them at once, and the shutdown includes the software as all.

SOA: Service oriented architecture

Service means: a facility for public demand.

Service Oriented Architecture is a software architecture pattern, which application components provide services to other components via a communications protocol over a network. The communication can involve either simple data passing or it could involve two or more services coordinating connecting services to each other. Services (such as RESTful Web services) carry out some small functions, such as validating an order, activating account, or providing shopping cart services.

There are 2 main roles in SOA,

A. Service provider

B. Service consumer.

A software agent may play both roles. The Consumer Layer is the point where consumers (human users, other services or third parties) interact with the SOA and Provider Layer consists of all the services defined within the SOA. The following figure shows a quick view of an SOA architecture.

3. Micro-services

Micro means small piece of some thing, then when We talk about Micro-Services, We mean that We have a small pieces of programmable web components, with the following set of characteristics:

There is a team of developers working on the application

New team members must quickly become productive

The application must be easy to understand and modify

You want to practice continuous deployment of the application

You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements

You want to take advantage of emerging technologies (frameworks, programming languages, and more)

Reduce testing effort
Elminate shutdown cost

2.Monolithic VS Micro-services

There are core differences between micro-services architecture and other models, which can be mentions as following:

Granularity

Means the size of the component/service, micro-services are the smallest coherent pieces of the source code, grouped around the domain, which named DDD: Domain driven development.

So, Micro-service can be considered as a web based component, designed according to DDD.

There are different factors that identify the service granularity, driven by the non-functional requirements, mentioned in the opposite video.

Database per service

One of the key aspects of micro-services is to have database for each service, which keeps SRP for each, and also for the team that is responsible for the micro-service.

By another meaning, There are a single responsibility for database communication, which can be formed in schemas, or separate database, according to:

Data Model objects, like orders micro-services
Data models growth rate, like huge logging tables

Independence

Each service is self-managed, independent from others, so it can manage its relationship with others using EDA, which implemented by message queues like KAFKA, RabbitMQ, and Azure message queue.

Different Technology stacks

You can implement micro-services using different technology stack, which facilitate team utilization and reduce the resource availability risk.

Container based

As you may implement services using different technology stacks, and each technology stack has different operating systems, different components, so the container based architecture take the place to enable easier deployment, without the complications of the operating systems requirements, so it keep the development team focus on the production only.

3.Infrastructure Concepts

There are main concepts in the containerization:

Cluster

Group of servers work together to provide high availability for specific solution
Includes all solutions and management tools that support the deployment and monitoring the solution

Node: The smallest computing HW element, which will be the actual configuration that host the environment, with CPU and memory configuration.
POD: High level structure that run containers, which running containers will share the same resources.

It includes the following:

The main container for the application
The sidecar container, that carry the responsibilities for collecting measurements and analytics about the main application container

Container: The deployable artifact/component
SCALING: Increase/decrease number of replicas (PODS) to handle the incoming requests according to traffic

4.Micro-Services Principles

Business domain centric/Single concern: With application of DDD, as We will mention in the next secti
SRP: Design for Single Responsibility : Each micro-service has its own responsibility, with no intersection with other one, which increases modularity, and single point of development and maintenance
API-First Design
API versioning
Use Asynchronous Communication When Possible
9. Use an API Gateway
10. Configuration Management
High cohesion/low coupling
- Remove internal dependencies
- communicate through event driven architecture
Service Autonomy
- Totally standalone component without depending on another micro-service, which decrease the coupling, and increase cohesion
- Totally standalone component without depending on another data model
DB Per Service: So micro-service architect can do the following:
- Select database type (relational/non-relational)
- Database provider: SQL/Oracle
Observability
- Side-Car pattern
- Logs classification model, which defines what to be logged from business and technical perspective.
- Logging tool: like using EFK and ELK

So, database is totally independent, and no one can access it without accessing the micro-service.

In migrating monolithic application to micro-services architecture, teams are familiar with the database structure, and try to reduce the effort by direct access to the database objects, and conduct CRUD operations using triggers, or procedures.

This is violation to the micro-services architecture, as it will block the sunset process for the monolithic solution, in addition, killing the traceability for the micro-services architecture.

Deplorability
Event-Driven

5.Micro-Services and DDD

In order to architect for modular solution, and for sure, micro-services architecture, the core issue is how can you slice your micro-services?

Here what We answer:

It's DDD: Domain drive design.

So what is domain?

Domain is a discrete part of the system that will help to solve specific problems, So you should have the following:

Contexts: The high level parts of the solutions, which may be:
- Domain generic Model: which Serve the generic infrastructure for the model, from both business and technical perspective
- Domain specific model
- Business components: which is the target deliverables of the solution, like User management, Sales, and Purchasing modules
- Technical components as enabler for the solution: which support the overall solution functionality, from technical perspective, like logging, reporting, and locking.
Entities and value : The definition of the expected entity objects, and the related values objects
Aggregator: Which aggregate entities, and values to treat specific unit, it can be used by the aggregator design patterns
Services: The related business and operations, which will be encapsulated in, Services, modules, or detailed controllers and implementation classes
Repositories: the storage, which you should apply database per service approach, and it can be:
- Database level: Which moving forward to containerization approach of the database, to have separate, deployable component from the ecosystem, totally independent to enable standalone deployment
- Schema level: Which schema is complex, that require different tables, and views to handle the business
- Table level: Which represents the simplest data-model form
Events: What to publish, and what to subscribe, which should be applied using publisher subscriber design pattern
Anti-Corruption layer: to ensure that contexts are collaborated and interact without negative impacts or inconsistencies

6.Micro-services Vs MACH Architecture

Micro-services architecture is a key pillar of the MACH architecture, which consists of:

Micro-services: Which is the evolution of monolithic application as we mentioned, components around the domains, with single responsibilities, independent deployable packages.
API first:
- Which you think about your API as a product, All functionalities are exposed, and can serve multiple channels, and considering integration with different stakeholders
- So it's about complete coverage of your system
- So everything you do from the interface, you can do it through the APIs, so, it's greater than the Micro-services architecture, it's business strategy.
- Implementing business logic/business rules on frontend only violates the API first approach, as all frontends and channels should implement the same logic, and this logic can be bypassed by attackers, check the image below.
- Moreover, you are exopsing your logic for the attacjers ti attack and violate your business
Cloud native: let the cloud manage your infrastructure and deployment components and resources
Headless architecture:
- FE consumer is totally decoupled from the Backend, to have more engagement moving forward to Omni-channels.
- Implementing any logic at frontend violates Headless architecture

For more details, visit : Modern Apps Architecture Journey

7.What Is Cloud Design Patterns

Due to the software development journey, a lot of source code issues and problems have arise, with huge effort from developers over the world to take action to solve it.

Due to the best practices of solutions, it moved to be a well known solution for the problems, within specific context, which take the name of : Design pattern.

With the evolution of Cloud architecture, a parallel evolution take place for the cloud, and named with Cloud design patterns.

These design patterns are useful for building reliable, scalable, secure applications in the cloud.

Each pattern describes the problem that the pattern addresses, considerations for applying the pattern, and an example based on Microsoft Azure. Most patterns include code samples or snippets that show how to implement the pattern on Azure. However, most patterns are relevant to any distributed system, whether hosted on Azure or other cloud platforms.

8.Patterns Area

Availability Patterns
Data Management Patterns
Design and Implementation Patterns
Management and Monitoring Patterns
Messaging Patterns
Security Patterns
Performance and Scalability Patterns
Resilience patterns

9.Micro-Services Myths

There are lots of myths about Microservices, which We have discussed in this session:

Microservices enhance performance
Microservices leads to better scalability
Microservices eliminate all Monolithic solution issues
Microservices architecture fits for all solutions
Microservices architecture does not need governance

Dr. Ghoniem Lawaty

Tech Evangelist @TechHuB Egypt

Page updated

Google Sites

Report abuse