Micro-services

Mizanur Rahman
 2

Microservices - also known as the microservice architecture - is an architectural style

that structures an applica6on as a collec6on of services that are

• Highly maintainable and testable

• Loosely coupled
• Independently deployable
• Organized around business capabili6es
• Owned by a small team

The microservice architecture enables the rapid, frequent and reliable delivery of large,
complex applica6ons. It also enables an organiza6on to evolve its technology stack.
3
 Micro-Services Architecture
• Defined as:
functional system decomposition into manageable and
independently deployable components

• “micro” refers to the sizing

– a micro service must be manageable by a single development team (5-9
developers)

• Functional system decomposition means vertical slicing

– in contrast to horizontal slicing through layers
 5

Bad things about microservices

Just because something is trending in the industry, does not necessarily mean it’s a viable solu6on for
each use case. One of the principal disadvantages is all the hype surrounding microservices. There
are other drawbacks, too. Some of the more superficial discomforts with microservices include:

• More complexity, thanks to the exper6se required to maintain a microservice-based applica6on

with all its moving parts.
• If the applica6on doesn’t need to scale or isn’t cloud-based, microservice-based architecture may
not provide any meaningful benefits.
• No greenfield op6ons because microservices need to connect to exis6ng (and possibly monolithic)
systems.
• Smaller units of func6onality communica6ng via APIs necessitate more robust methods of tes6ng
as well as buy-in from the en6re engineering team.
• The need for increased team management and communica6on to ensure everyone, not just certain
engineers, understand each service and the system as a whole.
 6

Ugly things about microservices

Applica6on architecture should be based not just on what’s in vogue at the moment but also on efficacy and fit.
When it comes to it, the truly intrinsic pain points that microservices come hand-in-hand with are…

• Dealing with distributed systems’ development, deployment, and opera6onal management overheads can be
expensive requiring a high ini6al investment to run.
• Choosing a different tech stack for different components leads to non-uniform applica6on design and
architecture.
• Endless documenta6on in the form of updated schemas and interface documents for every individual
component app.
• The costs of maintenance, opera6onal costs, and produc6on monitoring are much higher, and the la^er also
suffers from a dearth of available tools.
• Automa6on tes6ng becomes difficult when each microservice component is running on a different run6me
environment.
• Increased resource and memory consump6on from all the independently running components which need
their own run6me containers with more memory and CPU.
• Microservices, when implemented incorrectly, can make poorly wri^en applica6ons even more dysfunc6onal.
 7

Monolithic architecture
 Problems of Monolithic Architectures
• Code complexity and maintainability
• Deployment becomes the bottleneck
• Fear to change
• Lack of ownership
• Failure dependencies
• One size doesn’t fit all (ex: relational DB)
• Hard to scale out
Monolithic

Micro Services
Quality Characteristics
 Cont…

• Taxi Hailing Company (monolithic architecture)

 Cont…

Taxi Hailing Company (Micro-Services Architecture)

Cont…
 15

Decomposition
• as per uncle bob , we follow the circular journey of

Monolith -> Microservice -> Monolith

•
 16

Decomposition benefits
• focuses on CI/CD and, Simplifies testing and enables components to deployed independently,
• service must be small enough to be developed by a small team and to be easily tested.
• Focusing on SRP (Single Responsibility Principle) & Common Closure Principle (CCP), which states that classes that change for the same reason should be in
the same package

•
 17

Decompose by business capability

 18

Decompose by subdomain
Define services corresponding to Domain-Driven Design
(DDD) subdomains. DDD refers to the applica6on’s
problem space - the business - as the domain. A domain is
consists of mul6ple subdomains. Each subdomain
corresponds to a different part of the business.

Subdomains can be classified as follows:

• Core - key differen6ator for the business and the most

valuable part of the applica6on
• Suppor6ng - related to what the business does but not a
differen6ator. These can be implemented in-house or
outsourced.
• Generic - not specific to the business and are ideally
implemented using off the shelf sojware
 19

Self contained service

Design a service so that it can respond to a synchronous request without

wai6ng for the response from any other service.
 20

Service per team

Each service is owned by a team, which has

sole responsibility for making changes.
Ideally each team has only one service

• Enables each team to be autonomous

and work with minimal coordina6on with
other teams
• Enables the teams to be loosely coupled
• Achieves team autonomy and loose
coupling with the minimum number of
services
• Improves code quality due to long term
code ownership
•
 21

Refactoring to microservices - Strangler Application

 22

Data management - Database per Service

• Private-tables-per-
service – each service
owns a set of tables
that must only be
accessed by that
service

• Schema-per-service –
each service has a
database schema
that’s private to that
service

• Database-server-per-
service – each service
has it’s own database
server.

•
 23

Data management - Shared database

 24

Data management - Saga

A saga is a sequence of local transac6ons
 25

Data management - Choreography-based saga

Choreography - each local transac6on publishes domain events that trigger local transac6ons in other services
 26

Data management - Orchestration-based saga

Orchestra6on - an orchestrator (object) tells the par6cipants what local transac6ons to execute
 27

Data management - API Composition

 28

Data management - Command Query Responsibility Segregation (CQRS)

 29

Data management -Event sourcing

 30

Transactional messaging
 31

Testing

• Service Component Test

• Consumer-driven contract test
• Consumer-side contract test
 32

Deployment patterns

• Mul6ple service instances per host

• Service instance per host
• Service instance per VM
• Service instance per Container
• Serverless deployment
• Service deployment planorm
 33

Deployment patterns
 34

Communication style
Remote Procedure Invocation (RPI)

- REST

- gRPC

- Apache Thrift

Messaging

- Apache Kafka

- RabbitMQ

Domain-specific protocol

- Email protocols such as SMTP and IMAP

- Media streaming protocols such as RTMP, HLS, and HDS

 35

External API - API Gateway

 36

External API - BFF

 37

Service discovery - Client-side discovery

 38

Service discovery - Server-side discovery

 39

Service discovery - Service registry

Other services:

etcd

consul

Apache Zookeeper
 40

Service discovery - Self Registration

 41

Service discovery - Third-Party Registration

 42

Reliability - Circuit Breaker

 43

Security - Access Token

 44

Observability

• Log aggrega6on
• Applica6on metrics
• Audit logging
• Distributed tracing
• Excep6on tracking
• Health check API
• Log deployments and changes
 45

Service Mesh
 46

Proxy design pattern

 47

Docker & Microservices

48
 49

Recommended Read