MicroServices, yet another architectural style?

Stijn Van den Enden
CTO
stijn.vandenenden@aca-it.be
Tom De Wolf
Technical Lead
tom.dewolf@aca-it.be
www.aca-it.be
Thomas Borghs
Solution Engineer
thomas.borghs@aca-it.be
MICRO SERVICES
Yet another architectural style?

Concepts - What are Micro services?
Patterns - How to solve the challenges?
Technology - Using what?

The microservice architectural style is an approach to developing a single
application as a suite of small services, each running in its own process and
communicating with lightweight mechanisms, often an HTTP resource API. These
services are built around business capabilities and independently deployable by
fully automated deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different programming
languages and use different data storage technologies.
!
Martin Fowler

SERVICE ORIENTED ARCHITECTURE?
Yes, it’s SOA … but different implementation approach:
Classic SOA
integrates different applications as a set of services
Microservices
architect a single application as a set of services

Classic SOA
Microservices
WS* WS* WS* WS* WS*
Enterprise Service Bus
Workflow Engine
Orchestration
Intelligence
WS* WS* WS* WS* WS*

business platform
{ API } { API } { API }
accounting
ordering
service
service contract
{ API } { API }
Microservices
service
prospects
logistics
service
service
capability X
service
capability Y
service
backends external integrations
{ API }
{ API }
{ API } { API }
{ API } { API }

Classic SOA
Typical implementation solution differs!
Heavy-weight
Microservices
Orchestration
Intelligent Communication Layer
ESB
WS*/SOAP
License-driven
Target problem:
Integrate (Legacy) Software
Light-weight
Choreography
HTTP/REST/JSON
Dumb Communication Layer
Target problem:
Intelligent Services
Architect new Business Platform

SOA
WHY - DIFFERENTIATE FROM SOA

Simple to develop Simple to deploy Simple to scale
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
Database
WHY - THE CURSE OF THE MONOLITH

Large Code Intimidates Developers
Hard to understand
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
and modify
Overloaded
web container
Development
slows down
Overloaded IDE

Small Change - Big Impact
Any change requires
full rebuild, test and deploy
Impact analysis
is huge effort and takes long
Obstacle for frequent
changes and deployments
WAR/EAR
UI
Ordering
Inventory
Billing
App Server

Big Risk for Re-Write
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
No hard module boundaries
quality and modularity breaks down over time
this enforces eventual need for re-write
Long term commitment to technology stack
change or try-out new technology implies re-write
Re-write = complete re-write
no partial re-write

Little Resilience to Failure
WAR/EAR
UI Failure in monolith
Ordering
Inventory
Billing
App Server
brings it down

Scaling
can be difficult
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
Mostly Horizontal scaling
many load balanced instances
Hard to scale to data growth
cope with all data
Different components
have different resource needs
Scaling development
implies coordination overhead

Horizontal Scaling
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
(monolith)
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
Database
All data
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
Vertical Scaling
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
(monolith)
Database
All data
WHY - TYPES OF SCALING
Data Scaling
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
Database
segment
WAR/EAR
UI
Ordering
Inventory
Billing
App Server
Database
segment
Database
segment
(monolith)

Ordering
Container
Ordering
Container
Ordering
Container
Database
Ordering
Functional Scaling
(micro-services)
UI
Container
Inventory
Container
Billing
Container
Billing
Container
Database
Inventory Database
Billing
Ordering
WHY - TYPES OF SCALING
Team Scaling
Container
Inventory
Container
Billing
Container
(micro-services)
balances application
and development complexity

• Small and focussed on 1 capability
• easier to understand
• IDE and deployment faster for 1 service
• Independent
• Release and deployment
• Scaling
• Development
• Loosely Coupled
• through lightweight communication
• Fault Isolation vs bring all down.
• Allows try-out of new technologies.
• Re-write can be limited to 1 service
• Impact Analysis stops at boundary
• Provide firm module boundaries with
explicit interface!
• Less risk on re-write
• Harder to violate boundary in development
• Decentralised choreography
• vs central orchestration
• vs central point of failure
• Decentralised data
• polyglot persistence
WHY - ARCHITECTURAL BENEFITS

1 - Key (business) drivers guide architectural decisions
Micro-services are organised around business capabilities
2 - Postpone decisions to Last Responsible Moment
Micro-services allow delay of scaling and technological decisions
3 - Architect and develop for Evolvability
Micro-services support evolution in technology, scaling, and features
WHY - EVOLUTIONARY ARCHITECTURE

Approach - Key to success
Challenges - And ways to overcome them
HOW TO

Functional decomposition of the business domain

Software Design Customer Satisfaction
Separation of Concerns
Low Coupling, High Cohesion
Reduce Impact by
Encapsulating Source of Change
Predictable Cost of Change
Changes are Business Driven
Source of Change = Business
Functional Modularisation

B A
B
A
• Change A impacts all modules = costly
• Change B requires split of module = costly
• Change A only impacts other module if api change
• Change B limited to module

side note: Domain Driven Design
Tackling complexity by abstracting the business domain concepts and logic into a
domain model and using this as a base for software development
“In order to create good software, you have to know what that software is all about.
You cannot create a banking software system unless you have a good understanding
of what banking is all about, one must understand the domain of banking.”
From: Domain Driven Design by Eric Evans.

Bounded contexts
Domain driven design deals with large complex models by dividing them into
different functionally bounded subdomains and the explicitly describing the
interrelations between these subdomains.

Ordering Billing
ONLINE STORE
Inventory Accounting

Ordering Billing
customer
Invoice
balance
order
item
item
stock order
order
item
incoming cash
outgoing cash
stock

Benefits of functional decomposition

Ordering Billing
customer
Invoice
balance
order
item
item
stock order
order
item
incoming cash
outgoing cash
stock
Benefits of functional decomposition

Applying services to bounded contexts
Ordering Service Billing
Service
customer
Inventory Service Accounting
Service
Invoice
balance
order
item
item
stock order
order
item
incoming cash
outgoing cash
stock

Side note: Conway’s Law
Any organization that designs a system (defined broadly) will produce a design
whose structure is a copy of the organization's communication structure.
!
-- Melvyn Conway, 1967

Side note: Conway's Law
Technology-based Team Composition Functional Team Composition
Billing Inventory
Ordering
Accounting
Ordering
Container
Billing
Container
Inventory
Container
Accounting
Container
UI
UI

PITFALL:
Incorrect functional decomposition
Leads to higher coupling between services
most of the microservices architectural benefits are lost
- harder to functionally scale the application
- errors will propagate through multiple services
- graceful degradation will be harder to achieve
- team development overhead
- T-scaling becomes harder
- large communicational overhead between services
- large overhead in releasing/deploying business features
- refactoring to correct decomposition is costly

PITFALL:
Incorrect functional decomposition
Safer to start with a functionally well decomposed monolith
and evolve it to a microservices architecture when the need arises
Refactoring the initial functional decomposition will be easier in a monolith
- rewriting failure scenario’s
- decentralised data
- service contract redesign

Approach - Key to success
Challenges - And ways to overcome them

CHALLENGE #1:
Operational Complexity
Complex Runtime: many moving parts
- Keep Releases and deployments manageable
- high level of automation is needed
- Service monitoring is required
- Configuration management becomes more complex

CHALLENGE #2:
Distributed Development
Services are deployed on multiple instances
- distributed architectural properties to consider:
- decentralised data
- communication between services
- handling failures of components
- testing effort becomes greater

Decentralised data
Each service has its own database - loose coupling
Might even be in another database technology
Data duplication between services might be required to ensure loose coupling
When implementing use cases spanning multiple services:
distributed transactions vs eventual consistency

Distributed Transactions vs Eventual Consistency
DISTRIBUTED TRANSACTIONS
- data is always consistent
!
- reduces system availability
- services are more tightly coupled
- has fallen out of favor in modern stacks (REST, NoSQL)

Distributed Transactions vs Eventual Consistency
EVENT-DRIVEN ASYNCHRONOUS UPDATES
- use a message broker to publish use cases to other services
- decouples producers and consumers (services) of events
- improves availability
- tradeoff between availability and data consistenty
- application needs to be able to handle eventually consistent data

Communication between services
Network properties need to be taken into account
Use cases can span multiple services
What type of communication is best used to implement such a use case?

What type of Communication?
SYNCHRONOUS HTTP-BASED
- easy
- firewall-friendly, works across the internet
!
- doesn’t support publisher-subscriber patterns
- client and server must both be available simultaneously
- client needs to know host and port of server

ASYNCHRONOUS NON-BLOCKING
- Client doesn’t block calling thread
- allows for parallelism
!
- client and server still must both be available simultaneously
- client still needs to know host and port of server

ASYNCHRONOUS MESSAGING
- For example through a Broker
- decouples message producers from consumers
- broker can buffer messages
- supports a variety of communication patterns
!
- broker is another moving part
- adds complexity
- request-reply communication pattern is not a natural fit

Use case: New Order Received
New order Create invoice
Ordering Service Billing Service
Update Stock Update Incoming Cashflow
Inventory Service Accounting Service

Handling Failures
Services can fail at any moment
Design services to handle these kind of failures

Side note: Reactive Programming
Reactive systems are:
Responsive
Resilient
Elastic
Message Driven
!
-- Reactive Manifesto: september 16 2014

Handling Failures
FALLBACK MESSAGE QUEUE
Ordering Service new order received Billing Service
failure
Fallback queue

Handling Failures
PER-SERVICE THREAD POOLS
new order received
Thread pool
10 threads

CHALLENGE #3
Minimising Communicational Overhead
Avoid Chatty Communication
- communication between services is reduced
- when functional decomposition is done right
- when service size isn’t too small
- reduce communication between clients and Services with an API gateway
- executing service calls in parallel reduces impact of communication overhead
- reduce unneeded network usage by using circuit breakers

API GATEWAY
Monolith Micro Services
Ordering
Inventory
Billing
Accounting
Ordering
Container
Inventory
Container
Billing
Container
Accounting
Container
Desktop client
Mobile client
Desktop client
Mobile client

API GATEWAY
Ordering
Container
Inventory
Container
Billing
Container
Accounting
Container
Desktop client
Mobile client
Api gateway

Handling Failures in Communication
CIRCUIT BREAKER
- Wrap a protected function in a circuit breaker
- Monitor protected function for failures
- The circuit breaks when a predefined threshold of fails is reached
- All future calls to the function go to fallback until the circuit is restored

Handling Failures in Communication
CIRCUIT BREAKER
new order received
Circuit breaker
Threshold = 10
Fallback queue

Microservice
Implementation Stack

DROPWIZARD
Make features not WAR

DROPWIZARD
guava
jackson
metrics
Validator
YAML
JDBI
core
migrations
hibernate
jdbi
…

java -jar ./target/profileservice-0.1.0-SNAPSHOT.jar server ./src/
main/resources/userprofileservice.yml

SPRING BOOT
opinionated view of building production-ready Spring applications

• Convention over configuration
approach
• Deployable as a Self-contained
jar or war
•Tackles dependency-hell via
pre-packaging
• Support for monitoring and
metrics (actuator module)

VM’s abstract underlying
hardware, but limit
resource utilisation
MicroService MicroService
JVM
VM1 VM2
JVM
Guest OS
Guest OS
Hypervisor
Host OS
Compute, Storage, Network
Containers have own
isolated resources
MicroService MicroService MicroService
JVM JVM JVM
container2
container3
Host OS
MicroService
JVM
container1
container4

DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE
Static website User DB Web frontend Queue Analytics DB
Developmen
t VM
QA server Public Cloud Contributor’s
laptop
Multiplicity of Stacks
Multiplicity of
hardware
environments
Production
Cluster
Customer Data
Center
Do services and
apps interact
appropriately?
Can I migrate
smoothly and
quickly
…that can be manipulated using
standard operations and run
consistently on virtually any
hardware platform
An engine that enables any
payload to be encapsulated
as a lightweight, portable,
self-sufficient container…

DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE
Static website User DB Web frontend Queue Analytics DB
Developmen
t VM
QA server Public Cloud Contributor’s
laptop
Multiplicity of Stacks
Multiplicity of
hardware
environments
Production
Cluster
Customer Data
Center
Do services and
apps interact
appropriately?
Can I migrate
smoothly and
quickly
Operator: Configure Once, Run
Anything
Developer: Build Once, Run
Anywhere

DOCKER SOLVES THE NXN PROBLEM
Static website
Web frontend
Background workers
User DB
Analytics DB
Queue
Development
VM QA Server Single Prod
Server Onsite Cluster Public Cloud Contributor’s
laptop
Customer
Servers

• Isolation
• namespace
• pid mnt net uts ipc user
• resource usage
• (CPU, memory, disk I/O, etc.)
• Limited impact on Performance - http://ibm.co/V55Otq
• Daemon and CLI
JVM JVM JVM
container2
container3
Host OS
MicroService
JVM
container1
container4

Continuous Integration
Infrastructure
Source
Control System
DockerFile
Container Image Repository
Host OS
pull
daemon
MicroService
JVM
container1
MicroService
JVM
Host OS
Slave Node
push
build
provision
container1

https://github.com/spotify/helios
http://mesos.apache.org/
https://github.com/openshift/geard
…
Private Hybrid Public

JVM
VM1 VM2
JVM
Guest OS
Guest OS
Hypervisor
Host OS
JVM JVM JVM
container2
container3
Host OS
MicroService
JVM
container1
container4
VM’s abstract underlying
hardware, but limit
resource utilisation
Containers have own
isolated resources
Microservice run in their
own isolated classloader
and standbox in the JVM
OSGi Runtime
JVM
MicroService
Host OS

Static
Dynamic
Loadbalancer Loadbalancer
Web Front
End
Web Front
End
MicroService MicroService MicroService MicroService MicroService
Web Front
End
Web Front
End
Web Front
End
A
B
Midtier Service Registry
MicroService
register
renew
get registry

Static
Dynamic
Loadbalancer Loadbalancer
Web Front
End
Web Front
End
Web Front
End
Web Front
End
Web Front
End
A
B
https://github.com/Netflix/ribbon
Midtier Service Registry
MicroService
register
renew
get registry
eureka
ribbon
https://github.com/Netflix/eureka

The Story
* based on Functional Programming the Netflix API - Ben Christensen

Netflix API
Dependency A
Dependency D
Dependency G
Dependency B
Dependency J
Dependency E
Dependency M
Dependency H
Dependency P
Dependency C
Dependency K
Dependency F
Dependency N
Dependency I
Dependency Q
Dependency L
Dependency O
Dependency R

Discovery of Rx began with a re-architecture ...

... that collapsed network traffic into coarse API calls ...

Iterable
pull
Observable
push
T next()
throws Exception
returns;
onNext(T)
onError(Exception)
onCompleted()
!//"Iterable<String>"
!//"that"contains"75"Strings
!getDataFromLocalMemory()
!!.skip(10)
!!.take(5)
!!.map({!s!%>!
!!!return!s!+!"_transformed"})
!!.forEach(
.....{!println!"next!=>!"!+!it})
!//"Observable<String>"
!//"that"emits"75"Strings
!getDataFromNetwork()
!!.skip(10)
!!.take(5)
!!.map({!s!%>!
!!!return!s!+!"_transformed"})
!!.subscribe(
.....{!println!"onNext!=>!"!+!it})

+ =
https://github.com/Netflix/Hystrix

HystrixCommand run()
failure/circuit open
getFallback()
public class GetUserPerferencesCommand extends HystrixCommand<UserPreferences> {!
// ..//!
!
@Override!
protected UserPreferences run() {!
! ! // call the UserPreferencesService !
}!
!
@Override!
protected UserPreferences getFallback() {!
!! return UserPreference.empty();!
}!
}

A MicroService MicroService MicroService MicroService MicroService
Logstash
Log Aggregation
Graphite
Metrics and Monitoring

- Correct Functional decomposition is crucial
Conclusion
- reflect it in a organisational structure (Conway’s law)
- pretty hard to get right from the start
- A modular system can evolve to microservices
- balance the needs (advantages) with the costs (tradeoffs)
Are they here to stay?
who can tell?
but the monolith is dead

MicroServices, yet another architectural style?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MicroServices, yet another architectural style?

Similar to MicroServices, yet another architectural style? (20)

More from ACA IT-Solutions

More from ACA IT-Solutions (20)

Recently uploaded

Recently uploaded (20)

MicroServices, yet another architectural style?