MICROSERVICES

ARCHITECTURE
INTRODUCTION
Strategic objective in modern organizations
 Infrastructure – private cloud/virtualized medium
 Compute
 Storage
 Network
 Everything as a service
 PasS
 Standardized Application Development
 Application Store
 Zero production intervention

How to achieve this ? How to develop new applications ?

MICROSERVICES
"In short, the microservice architectural style is an approach to
developing a single a single application as a suite of small services,
each running in its own process and communicating with lightweight
mechanism, often an HTTP resource API" - James Lewis, Martin Fowler
Characteristics:
 Small size: The service design is focused on small services, bounded
by contexts and decentralized.
 Strict Standards on communication protocols: lightweight
protocols – REST + JSON, message queues
 Loose standards on technology: programming language,
databases and environment depend on what fits best.
 Interchangeability: All individual microservices are easy to replace.
Often paired with concepts and technologies such as: DevOps, Docker,
Kubernetes etc.
REFERENC
E HIGH Frontend UI
Internet

LEVEL
ARCHITEC
Backend for Frontend Routing/Caching
DMZ

TURE API Mediation API Gateway & API Manager

Microservices Orchestration and Choregraphy

System of Records Persistence

Intranet
MICROSERVICE DESIGN
– HOW TO ?
• A guidance framework for successfully design a
microservice architecture
• Define how dependencies between services will be managed
• Identify services by applying patterns for:
• Decoupling functionality
• Decomposing functionality
• Maximize loose coupling of services through the designs of their
interfaces:
• Decoupled from implementations
• Decoupled from data
• Implement a lifecycle management strategy for services
MICROSERVICE DESIGN –
HOW TO ?
Prework • Define application domain
covered for
example by
Kubernetes/Open
Dependen • Distributed configuration to
shift
cy decouple services from the
Managem environment
• Service discovery –
ent decouple services from
each other
Strategies
Services • Iterate
• Decomposition strategies Partially
Identificat • Decouple using anti- covered by API
ion corruption layers
Management

• Interfaces for loosely coupled

consumption
Services • Loosely coupled service
composition
Design • Decoupled data ownership,
persistence, access and
reporting

Service
Lifecycle • Versioning
Managem • Service dependencies
tracking
ent
MICROSERVICES
DESIGN - PREWORK
• For the organization:
• Adapt internal processes for microservices :
• high degree of process maturity:
• development
• operational
• High degree of automation
• Organize people and build skills for microservices
• Development teams: small autonomous teams accountable for all aspects of
the service they manage, coding -> operations
• Define the technology platform for microservices:
• The platform should help managing the complexity, e.g. operational
complexity

• For the problem to be solved:

• validate that MSA is appropriate for the problem
• understand application domain
DEPENDENCY
MANAGEMENT STRATEGIES
 Ideal state - microservices share nothing, entirely decoupled:
 Design
 Development
 Deployment
 Platform/technology
 Operations
 Reality – dependencies:
 On other services (functionality or data)
 On the operating environment
 How to overcome:
 Loose coupling
 Late-bind dependencies
 More concrete:
 How to manage configuration data outside the service?
 How will services reference each other, assuming there are many service types and
more instances of each type?
DEPENDENCY MANAGEMENT
STRATEGIES
- EXTERNALIZED CONFIGURATION
PATTERN
 Allows configuration data to be defined external to the service
implementation and deployment
 Decouple services from the environment
 Improves portability, automation
 Implementation – on startup, the service reads configuration from
an external source:
 Environment variables
 Dedicated component, e.g. Spring Cloud Config server
 Configuration data and operations must be subject to a
configuration management process
DEPENDENCY MANAGEMENT
STRATEGIES
- SERVICE DISCOVERY
 Service instances of different types register their availability with a discovery component (+
periodic heartbeat)
 Consumer services require connection an endpoint of given service type
 Discovery provides an instance that is designated to handle the request
 Implementations:
 DNS
 Web API
 Environment variables
 Forms:
 part of the development platform
 Standalone tool that needs to be managed/deployed
 Examples:
 Eureka
 etcd (used by Kubernetes)
 consul
 Apache Zookeeper
SERVICE
DISCOVER
Y Register availability
+
Heartbeat

Service A
 Server side service Instance 1

discovery
 Example LBs:
 AWS Elastic Load Service Discovery
Balancer update
Service A
Instance 2
 Nginix
 Service discovery
component generates Consumer Service
request
nginix.conf file and runs Instance
command for nginix to request Service A
reload configuration Instance 3
Load Balancer
 Openshift/Kubernetes
Services
SERVICE DISCOVERY
Register availability
 Client side service discovery +
Heartbeat

Service A
Instance 1

Service Discovery
Service A
1. Lookup
Instance 2
DNS/REST

Consumer Service
Instance
2. request
Service A
Instance 3
SERVICES IDENTIFICATION

ITERATIVE EVOLUTION DECOMPOSITION DECOUPLING USING

STRATEGIES FOR ANTI-CORRUPTION
MONOLITHIC LAYERS
APPLICATIONS
SERVICE IDENTIFICATION
- ITERATIVE EVOLUTION
 Usually, initial state=legacy application=monolithic
 Smallest change =
 Rebuild all codebase
 Test
 Deploy to production
 Internal dependencies between modules -> regression risks
 Initial state=new application
 Not all microservices can be identified from the first sight (analogy: when designing a
database some initial tables are identified but there is an iterative design process to
reach a polished state that will go through FN1, FN2, FN3 etc.)
 Therefore the design is started from a more or less monolithical approach even if an
initial set of microservices is identified -> decomposition still needs to be applied (split)
 Solution
 Decompose the monolithic application into microservices or
 Decompose less granular microservices into finer grained microservices
 Usually cannot be done one-off -> iterative process
SERVICES Split Split the monolith
IDENTIFIC
ATION
- Strangl
e/ Strangle/shave the monolith
DECOMPO Shave

SITION
STRATEGI Extend Extend the monolith

ES
 SPLIT THE MONOLITH

DECOMPOSITION A B C D

INITIAL STATE
STRATEGIES – SPLIT E

THE MONOLITH
 Split the monolith: F G H I

 Break down into a set of independent services

 Analyze and look for dependencies in both:
 Logic
 Data
A B C D
 Start with data and how it is used by the application

ITERATION 1
 Look for Seams/Fissures where there is low degree of
dependency – candidates for splitting points:
E
 architectural/deployment pattern – e.g. separate by
layer/tier, backend from frontend or presentation,
business logic and data access
F G H I
 logic – areas of functionality with limited relationship
between them
 data – areas of application dealing with data entities with
limited relationship between them
 Example:
A B C D
 Online banking application:

ITERATION 2
 Accounts
 Transactions list E

 Payments
 Investments
F G H I
 User profile management
 STRANGLE/SHAVE THE MONOLITH

DECOMPOSITION A B C D

INITIAL STATE
STRATEGIES – SHAVE
THE MONOLITH
E

F G H I

 Shaving the monolith

 Existing functionality is targeted for
extraction from the monolith and re-
implemented as a separate service A B C D

ITERATION 1
 Identify dependencies in logic and data
 Lucky case: no dependencies -> can be E

directly decoupled
 Dependencies found -> design an
abstraction layer to keep new service F G H I

decoupled
 With each iteration monolith gets smaller
and smaller
 Monolith is changed with each iteration A B C D

ITERATION 2
E

F G H I
 EXTEND THE MONOLITH

DECOMPOSITION A B C D

STRATEGIES –

INITIAL STATE
EXTEND THE
E

MONOLITH F G H I

 Extending the monolith

 Similar to shaving
 Minimizes changes in existing application
A B C D X
 Put monolith is stasis

ITERATION 1
 Implement new features as independent
services E

 Example:
 add notification service to order F G H I Y

management system
 Monolith could have small update to
publish order status as event
 Further notification service may be Z A B C D X

ITERATION 2
managed independently and may trigger
new functionality in other services such
as for example stock replenishment. E

T F G H I Y
DECOUPLING USING ANTI-
CORRUPTION LAYERS
 Goal:
 Hide internal domain models of legacy application and prevent them from corrupting the design of the new service
 Allows system components to use optimal domain models internally and to interact with components using other models, e.g.
legacy models
 Decouples old and new environments
 Microservice interacting with monolithic application:
 Shared repository
 The new service does not have its own model
 ACL must provide interfaces that implement repository that is backed by the legacy application
 Synchronized repository
 The new service has its own specific persistence implementation
 ACL implements synchronization between service domain and legacy domain
 Synchronization must ensure data consistency:
 Data-driven, e.g. batch reconciliation
 Event-driven
 ACL
 Abstraction layer
 implementation:
 Mediator
 Façade
 Gateway
DECOUPLING USING ANTI-
CORRUPTION LAYERS
Shared repository

ACL

A B C

Mediator X

E Data
Monolith
Domain
translation
C<->X
H<->Y
F G H
Y

Legacy domain model Decoupling layer New domain models

DECOUPLING USING ANTI-
CORRUPTION LAYERS
Synchronized repository – data driven

ACL

A B C
Async
Coordinator updates X

E
Monolith
Domain Async
translation updates
C<->X
H<->Y
F G H
Y

Legacy domain model Decoupling layer New domain models

DECOUPLING USING ANTI-
CORRUPTION LAYERS
Synchronized repository – data driven

ACL
events
A B C

Coordinator X

E events
Monolith
Domain
translation
C<->X
events
H<->Y
F G H
Y

Legacy domain model Decoupling layer New domain models

DESIGN OF LOOSELY
COUPLED SERVICES
 Considerations to address
 Communication interfaces
 Service composition
 Data persistence
SERVICES DESIGN
- COMMUNICATION
INTERFACES
 Microservices communicate with consumer applications and other microservices
 Decouple service implementations from underlying technologies by using open, cross-
platform protocols
 Communication patterns:
 Request-response
 Event-driven
 API Mediation Pattern:
 decouples API consumption from service provider
 Outer API
 interfaces published to applications outside control or outside the domain covered by developed microservices
 Managed by API Gateway
 Inner API
 Interfaces exposed by the microservices themselves
 Interface contracts define bonds with other services
 Open API specification/Swagger
 RAML
COMMUNICATION
INTERFACES
Other application domains

Service
App Process

Boundary

Outer API

API Mediation

Call from XYZ domain to ABC domain

Microservice ABC domain / Inner APIs Microservice XYZ domain / Inner APIs

Request-
Event driven response

Service A Service B Service C Service X Service Y Service Z

API MEDIATION
API Gateway
 ensures that only registered users or applications with a valid API
subscription (API Key) can make requests on a service
 acts as a reverse-proxy to route requests to published resources
under well-known public URLs to internal and protected URLs
without exposing the actual physical network location of the
underlying Provider
API Manager
 provides API discovery and management functions for consumers
and providers
 Provider/Publisher
 Publishes APIs
 Consumer/Subscriber
 Registers to use APIs
SERVICES DESIGN
- COMPOSITION PATTERNS
Orchestration
- Orchestrator service executes Start process
prescribed flow made up of atomic
steps: Service A

 Loop step1 Service B

 branch
step2
 Fork/join
step3
- Implementation:
 Code it! step4

 Use integration framework, e.g. Apache Service C Composite Service D

Service
Camel
SERVICES DESIGN
- COMPOSITION PATTERNS
Choreography
 Flow dictated by sequence of events
 Each step emits one/more events to publish state
change
 Downstream services subscribing to events are Start process
triggered <<sub>>

 Advantages:
Service A
 Loosely coupled model event1 Service B
 No central definition of the flow <<pub>>
 Additional participants can be introduced as
publishers/subscribers <<pub>>
event2
 Asynchronous processing <<sub>> <<sub>>
 Scalability – no need to scale up orchestrator but
only participants
event3
 Disadvantages
Service C Service D
 Hard to follow interactions <<pub>> Event Broker
 Need to correlate and aggregate logging
SERVICES DESIGN
- DATA DECOUPLING
 Maximum agility and independence between services principles:
 Data owned by a microservice can only be accessed through the interface provided
by the microservice
 No database enforced relationship (e.g. referential integrity) between data owned
by a microservice and data owned by another
 Advantages
 Agility+flexibility+Independence decision on about data persistence per service
 Implementations
 existing database and decoupled data table per service
 Schema per service
 Database per service
 Disadvantages
 Service must manage:
 Consistency
 Data relationships
SERVICES DESIGN
- DATA DECOUPLING
Monolith
– independent services – decoupled services
– coupled services
– coupled data - decoupled data
– coupled data

Deployment unit Deployment unit Deployment unit Deployment unit Deployment unit

Service A Service B Service A Service B Service A Service B

Application Data Store Application Data Store Service A Data Store Service B Data Store

Higher decoupling
Lower decoupling
SERVICES Deployment unit Deployment unit
DESIGN
- DATA Service A
Check constraint
Service B

DECOUPLING
 Example:
 Foreign key constraint
check
 Service B exposes an
interface towards Service
A where constraints can
be checked Service A Data Service B Data

A B
1
PK id PK id
*
... FK a_id

...
SERVICES DESIGN
- DATA DECOUPLING /a/{id}/b

Deployment unit Deployment unit

B update
 Joining data: event
Service A Event Broker Service B
 on-demand at the time of join B update
 Consumer service calls each event
data owning services to get
data
 Disadvantage: orchestration
effort
 Duplicate data:
 Data owner service use event
driven model to publish data
changes
 Consumer services that depend
on the data subscribe to these Service A Data Service B Data
events and update their local
copy to be in sync Service B
Data
 Disadvantages
 Outdated data
 Dirty reads
 Data redundancy
SERVICES DESIGN
- DATA DECOUPLING
 Transactional updates:
 Within the scope of a service
 Classical ACID(atomic, consistent, isolated, durable)
 Distributed transactions across multiple transactional resources (e.g. XA protocol)
 Across services
 Eventual consistency ~ optimistic replication, in a finite timespan all replicas converge to the actual
status
 Example:
 Send multiple messages to multiple queues -> all or none are delivered
 But for processing, if it fails for one destination, then retries must be handled
 Service Consumer

Make transfer

SERVICES DESIGN
- DATA DECOUPLING
Service Implementation
POST
Query
/transfers

Deployment unit Deployment unit

 Event store: Transfers Process

Accounts Core Service
Service
 Golden source for entity state
change event

J:TRANSFER_COMPLETED

D: ACCOUNT_DEBITED H: ACCOUNT_CREDITED
A: TRANSFER_NEW F: DEBIT_ACK B: TRANSFER_NEW
G: DEBIT_ACK
E: ACCOUNT_DEBITED I: ACCOUNT_CREDITED

Event Store
Transfer Event Queue Account Event Queue

Timestamp,state,from,to,amount timestamp, state, account, balance

T4, TRANSFER_COMPLETED,10101,20202,400 T3, ACCOUNT_CREDITED, 20202, 1400
T2, DEBIT_ACK, 10101,20202,400 T1,ACCOUNT_DEBITED,10101,600
T0,TRANSFER_NEW,10101,20202,400 T-x, ACCOUNT_OPENED,10101,1000
T-z,ACCOUNT_OPENED,20201,1000
SERVICES DESIGN
- DATA DECOUPLING Modify Query

Deployment unit Deployment unit

 Case for requirements:

 Keep data decoupled Write Read
 Support transactional updates Service A Service A

 Optimize reads
 Solution: Command Query
Responsibility Segregation
 Independently optimizes read and writes
when unbalanced, e.g. many reads, few
writes
 Disadvantages
 Complexity
 Costs
 Synchronization synchronization
Service A Data Service A Data
 Change-data-capture Write Model Read Model
 Data pump to pull updates
 Event sourcing: write svc keeps event
log as persistence model and read
service subscribes
 Service Consumer

Get account
Update Account
balance

SERVICES DESIGN
Service Implementation

- DATA DECOUPLING
Command/
Query
Modify

Deployment unit Deployment unit

Accounts Command Read

Handler Service A

publish

Event: Account Y debited

append

Write Model Read Model

Event 5: Account Y ______________

debited |Accnt|Balance |
______________
Event 4: Account Z |W |2000 |
credited | X |15478 |
synchronization | Y |9820 |
Event 3: Account W Deliver change | Z |125000 |
debited To ______________
subscriber
Event 2: Account X
credited

Event 1: Account W
opened
LIFECYCLE
Build

Retire Interface implementation Publish

Lifecycle
(infrequent)

Deprecate Run

Service implementation
Lifecycle
Plan
(frequent)
Deploy

Build