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.
REFERENCE HIGH LEVEL ARCHITECTURE
Frontend UI
Internet

Backend for Frontend Routing/Caching

DMZ

API Mediation API Gateway & API Manager

Microservices Orchestration and Choregraphy

System of Records Persistence

Intranet
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?
EXTERNALIZED CONFIGURATION PATTERN
 Allows configuration data to be defined external to the service implementation and deployment d
 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
 SERVICE DISCOVERY
 Service instances of different types register their availability with a discovery component (+ periodic heartbeat)
 Consumer services require connection a 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
SERVICE DISCOVERY
Register availability
 Server side service discovery +
Heartbeat

Service A
Instance 1

Service Discovery
update
Service A
Instance 2

Consumer Service
request
Instance

request Service A
Instance 3
Load Balancer
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
ITERATIVE EVOLUTION
 Usually, initial state=legacy application=monolithic
 Smallest change =
 Rebuild all codebase
 Test
 Deploy to production
 Internal dependencies between modules -> regression risks
 Solution
 Decompose the monolithic application into microservices
DECOMPOSITION STRATEGIES
 Split the monolith
 Strangle the monolith
 Extend the monolith
 SPLIT THE MONOLITH

DECOMPOSITION STRATEGIES A B C D

INITIAL STATE
E

F G H I

 Split the monolith:

 Break down into a set of independent services
 Analize and look for dependencies in both:
 Logic A B C D

ITERATION 1
 Data
 Start with data and how it is used by the application
 Look for Seams/Fissures where there is low degree of dependency – E
candidates for splitting points:
 in logic – e.g. separate backend from frontend
 Functional – areas of functionality with limited relationship between them F G H I

 Example:
 Order management system with functionality:
 Manage customer data
 Create and process orders
 Inventory management A B C D

ITERATION 2
 Catalog
 Shipping
 Each of the above are potential opportunities to split the application E

F G H I
 STRANGLE/SHAVE THE MONOLITH

DECOMPOSITION STRATEGIES
A B C D

INITIAL STATE
E

 Shaving the monolith

 Existing functionality is targeted for extraction from the F G H I

monolith and re-implemented as a separate service

 Identify dependencies in logic and data
 Lucky case: no dependencies -> can be directly decoupled
 Dependencies found -> design an abstraction layer to keep D
new service decoupled
A B C

ITERATION 1
 With each iteration monolith gets smaller and smaller
 Monolith is changed with each iteration E

F G H I

A B C D

ITERATION 2
E

F G H I
 EXTEND THE MONOLITH

DECOMPOSITION STRATEGIES
A B C D

INITIAL STATE
E

 Extending the monolith

 Similar to shaving
F G H I

 Minimizes changes in existing application

 Put monolith is stasis
 Implement new features as independent services
 Example:
A B C D X

 add notification service to order management system

ITERATION 1
 Monolith could have small update to publish order status as
event E

 Further notification service may be managed independently

and may trigger new functionality in other services such as
for example stock replenishment.
F G H I Y

Z A B C D X

ITERATION 2
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
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

Microservice domain / Inner APIs

Request-
Event driven response

Service A Service B Service C

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
COMPOSITION PATTERNS
Orchestration
- Orchestrator service executes prescribed Start process
flow made up of atomic steps:
 Loop Service A
step1 Service B
 branch
 Fork/join step2

- Implementation: step3
 Code it!
 Use integration framework, e.g. Apache Camel step4
Service C Composite Service D
 Use distributed ESB Service
COMPOSITION PATTERNS
Choregraphy
 Flow dictated by sequence of events
 Each step emits one/more events to publish state change
 Downstream services subscribing to events are triggered
Start process
 Advantages: <<sub>>
 Loosely coupled model
 No central definition of the flow Service A
event1 Service B
 Additional participants can be introduced as <<pub>>
publishers/subscribers
 Asynchronous processing <<pub>>
 Scalability – no need to scale up orchestrator but only event2
<<sub>> <<sub>>
participants
 Disadvantages
 Hard to follow interactions event3
 Need to correlate and aggregate logging Service C Service D
<<pub>> Event Broker
DATA DECOUPLING
 Maximum agility and independency 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+flexibilityIndependent 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
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 Application Data Service A Data Service B Data

DATA DECOUPLING
Deployment unit Deployment unit

Check constraint
Service A Service B
 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

...
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 data event
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 events and
update their local copy to be in sync
 Disadvantages
Service A Data Service B Data
 Outdated data
 Dirty reads Service B
Data
 Data redundancy
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 ~ almost good enough, e.g.:
 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
DATA DECOUPLING Modify Query

Deployment unit Deployment unit

 Case for requirements:

 Keep data decoupled Write Read
Service A Service A
 Support transactional updates
 Optimize reads
 Solution: Command Query
Responsibility Segregation
 Independently optimizes read and writes when
unbalanced, e.g. many reads, few writes
 Disadvantages
 Complexity
 Costs
 Synchronization
 Change-data-capture Service A Data synchronization Service A Data
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

DATA DECOUPLING
Reserve Room X Get Reservations

Service Implementation
Command/
Query
Modify

Deployment unit Deployment unit

Confirm X Select room,
availability status from ...
Reservation Command Read
Handler Service A

publish

Event: Room Y reserved

append

Write Model Read Model

______________
Event 5: Room Y reserved
|Room|Status |
______________
|W |Available|
Event 4: Room Z reserved
| X |Reserved |
synchronization | Y |Reserved |
Deliver update | Z |Reserved |
Event 3: Room W cancel To ______________
subscriber
Event 2: Room X reserved

Event 1: Room W reserved

LIFECYCLE
Build

Retire Interface implementation Publish

Lifecycle
(infrequent)

Deprecate Run

Service implementation
Lifecycle
Plan
(frequent)
Deploy

Build