Microservice Architecture

Micro-service Architecture Style
SMAC ERA…
February 5, 2015
Nguyen Quang Tung
Solution Architect
M: 0127 666 0909
E: tungnq@fsoft.com.vn
tungnq@gmail.com

2Copyright © 2014 by FPT Software
WHO AM I?
Nguyen Quang Tung
•E1: tungnq@fsoft.com.vn
•E2: tungnq@gmail.com
•M: +841276660909
Professional:
• Cán Bộ Công Nghệ FPT Lvl3 –
System Architect
•7+ Solution Architect
•6+ Project Manager
•11+ Java/J2EE Development
Domain:
•Multi-media/Video Broadcasting
•Stock Market
•CMS & DMS
•Real Property Market.
•eGovernment
Bachelor of Science Master of Science Mini – MBA

WHO IS BIG PLAYER IN THIS GAME!
http://microservices.io/patterns/microservices.html

MICROSERVICE ARCHITECTURE - CONCEPTS
Concepts
Why?
How?
What?
•Concept
•Technology

SW Architecture in the Context of History

Concepts: WHAT ARE MICRO-SERVICERS?
The Micro-Service 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.

Concepts: SERVICE ORENTED ARCHITECTURE (SOA)?
Classic SOA
•Integrates different
applications as a set
of services
Microservices
•Architect a single
application as a set
of services
Yes, it’s SOA … but different implementation approach

Concepts: CLASSIC SOA vs MICROSERVICE
Classic SOA
• Integrates different applications as a
set of services
Typical implementation solution
• Heavy-weight
• Orchestration
• ESB
• WS*/SOAP
• License-driven
• Intelligent Communication Layer
Target Problem
• Integrate (Legacy) Software

Concepts: CLASSIC SOA vs MICROSERVICE
MICROSERVICE
• Architect a single application as a set
of services
Typical implementation solution
• Light-weight
• Choreography
• HTTP/REST/JSON
• Intelligent Services
• Dumb Communication Layer
Target Problem
• Architect new Business Platform

MICROSERVICE ARCHITECTURE – WHY?
Concepts
Why?
How?
What?
•Concept
•Technology

WHY: EVOLUTION OF SOFTWARE ARCHITECTURE

WHY: FROM MONOLITHIC TO CLOUD

WHY: THE CURSE OF THE MONOLITH
Simple to Develop Simple to Deploy Simple to Scale

Hard to understand
and modify
Overloaded IDE
Overloaded
Web Container
• Large Code Intimidates Developers
Development
Slows Down

• 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

• Big Risk for Re-Write
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
Failure in monolith brings it down

• Scaling can be difficult
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

WHY: TYPES OF SCALING
• The Scale Cube

V1
V2
Re-write a service in 2-3 weeks

WHY: ARCHITECTURAL BENEFITS
Small and focused 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
Decentralized
choreography
•vs central orchestration
•vs central point of failure
Decentralized data
•Polyglot persistence

WHY: ARCHITECTURE EVOLUTION
1 - Key (business) drivers guide architectural decisions
• Micro-services are organized 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

MICROSERVICE ARCHITECTURE - HOW-TO?
Concepts
Why?
How?
What?
•Concept
•Technology

HOW-TO: PRINCIPLES OF MICROSERVICES
http://12factor.net/

HOW-TO: Big Picture!

HOW-TO: 7 PRINCIPLES OF MICROSERVICES
Principles Of
Microservices
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementation
Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate Failure
7. Highly
Observable

1. Modelled Around Business Domain
Principles
Of
Microservic
es
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementatio
n Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate
Failure
7. Highly
Observable
Benefits
 Domain modules can migrate
independently to next version!
 Database schema is internal to
the domain bundle, i.e. NOT
part of the API!
 Persistence and/or database
technology can differ between
modules in one system!

2. Culture Of Automation
Principles
Of
Microservic
es
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementatio
n Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate
Failure
7. Highly
Observable
Infrastructure Automation
Automated Testing
Continuous Delivery!

3. Hide Implementation Details
Principles
Of
Microservic
es
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementatio
n Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate
Failure
7. Highly
Observable
Databases
Business Partner
Vehicle Service
Business Partner Service
Transport Service
Databases
Vehicle Databases
Transport
Databases
Vehicle
Business Partner
Transport
Vehicle App
Business Partner App
Transport App
Vehicle Context
Transport Context
Business
Partner
Context
Hide Your Database!

4. Decentralize All The Things
Principles
Of
Microservic
es
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementatio
n Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate
Failure
7. Highly
Observable
What is autonomy?
 Giving people as much freedom
as possible to do the job at hand
Autonomy!
Self Service
Share
Governance
Owner
Operator
Internal
Open
Source
Dumb-
Pipes,
Smart
Endpoint

5. Deploy Independently
Deployment
One
Service
Per-Host
Consumer-
Driven
Contracts
Co-Exist
Point
Principles
Of
Microservic
es
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementatio
n Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate
Failure
7. Highly
Observable

6. Isolate Failure
Principles
Of
Microservic
es
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementatio
n Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate
Failure
7. Highly
Observable

7. Highly Observable
Principles
Of
Microservic
es
1. Modelled
Around
Business
Domain
2. Culture Of
Automation
3. Hide
Implementatio
n Details
4. Decentralise
All The Things
5. Deploy
Independently
6. Isolate
Failure
7. Highly
Observable
Correlation IDs
Aggregation

HOW-TO: MICROSERVICE CHALLENGES

Communication Between Services
• Use case: New Order Received

Handling Failures
• FALLBACK MESSAGE QUEUE
• PER-SERVICE THREAD POOLS

Minimising Communicational Overhead
• API GATEWAY

Handling Failures in Communication
• CIRCUIT BREAKER

MICROSERVICE ARCHITECTURE - WHAT?
Concepts
Why?
How?
What?
•Concept
•Technology

WHAT: TECHNOLOGY
Microservice Implementation Stack

WHAT: DEPLOYMENT
Deployment Options

WHAT: DEPLOYMENT
Docker - Build, Ship, and Run Any App, Anywhere

WHAT: DEPLOYMENT
DOCKER SOLVES THE NxN PROBLEM

WHAT: DEPLOYMENT

WHAT: DEPLOYMENT
CI - Continuous Integration

WHAT: DEPLOYMENT
Deployment Options

WHAT: BALANCING LOAD

WHAT: METRIC & MONITORING

CONCLUSION
Advantages of Microservice Architecture
• Each micro service is small and focused on a specific feature / business requirement.
• Microservice can be developed independently by small team of developers (normally 2 to 5 developers).
• Microservice is loosely coupled, means services are independent, in terms of development and deployment both.
• Microservice can be developed using different programming language (Personally I don't suggest to do it).
• Microservice allows easy and flexible way to integrate automatic deployment with Continuous Integration tools (for
e.g: Jenkins, Hudson, bamboo etc..).
• The productivity of a new team member will be quick enough.
• Microservice is easy to understand, modify and maintain for a developer because separation of code,small team and
focused work.
• Microservice allows you to take advantage of emerging and latest technologies (framework, programming language ,
programming practice, etc.).
• Microservice has code for business logic only, No mixup with HTML,CSS or other UI component.
• Microservice is easy to scale based on demand.
• Microservice can deploy on commodity hardware or low / medium configuration servers.
• Easy to integrate 3rd party service.
• Every microservice has it's own storage capability but it depends on the project’s requirement, you can have common
database like MySQL or Oracle for all services.

CONCLUSION
Disadvantages of Microservice Architecture
• Microservice architecture brings a lot of operations overhead.
• DevOps Skill required (http://en.wikipedia.org/wiki/DevOps).
• Duplication of Effort.
• Distributed System is complicated to manage .
• Default to trace problem because of distributed deployment.
• Complicated to manage whole products when number of services increases.

REFERENCE
 Microservices - http://martinfowler.com/articles/microservices.html
 Microservice architecture patterns and best practices - http://microservices.io/
 InfoQ eMag: Microservices - http://www.infoq.com/minibooks/emag-microservices
 Micro Services: Java, the Unix Way - http://www.infoq.com/presentations/Micro-Services
 Microservices: Decomposing Applications for Deployability and Scalability -
http://www.infoq.com/articles/microservices-intro
 Microservice Architecture: A Quick Guide- http://java.dzone.com/articles/microservice-architecture
 Making Architecture Work in Microservice Organizations -
http://tech.gilt.com/post/102628539834/making-architecture-work-in-microservice
 Life Preservation for Adaptable Software - https://github.com/russmiles/life-preserver-introductory-
article-developer-magazine
 The Art of Scalability - http://theartofscalability.com/

Q&A

Microservice Architecture

More Related Content

What's hot (20)

Similar to Microservice Architecture (20)

Recently uploaded (20)

Microservice Architecture