More Related Content
Similar to Microservice Architecture (20)
Microservice Architecture
- 2. 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
- 4. 4Copyright © 2014 by FPT Software
WHO IS BIG PLAYER IN THIS GAME!
http://microservices.io/patterns/microservices.html
- 5. 5Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE - CONCEPTS
Concepts
Why?
How?
What?
•Concept
•Technology
- 7. 7Copyright © 2014 by FPT Software
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.
- 8. 8Copyright © 2014 by FPT Software
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
- 9. 9Copyright © 2014 by FPT Software
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
- 10. 10Copyright © 2014 by FPT 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
- 11. 11Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE – WHY?
Concepts
Why?
How?
What?
•Concept
•Technology
- 14. 14Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
Simple to Develop Simple to Deploy Simple to Scale
- 15. 15Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
Hard to understand
and modify
Overloaded IDE
Overloaded
Web Container
• Large Code Intimidates Developers
Development
Slows Down
- 16. 16Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• 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
- 17. 17Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• 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
- 18. 18Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• Little Resilience to Failure
Failure in monolith brings it down
- 19. 19Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• 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
- 22. 22Copyright © 2014 by FPT Software
WHY: TYPES OF SCALING
V1
V2
Re-write a service in 2-3 weeks
- 23. 23Copyright © 2014 by FPT Software
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
- 24. 24Copyright © 2014 by FPT Software
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
- 25. 25Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE - HOW-TO?
Concepts
Why?
How?
What?
•Concept
•Technology
- 26. 26Copyright © 2014 by FPT Software
HOW-TO: PRINCIPLES OF MICROSERVICES
http://12factor.net/
- 28. 28Copyright © 2014 by FPT Software
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
- 29. 29Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
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!
- 30. 30Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
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!
- 31. 31Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
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!
- 32. 32Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
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
- 33. 33Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
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
- 34. 34Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
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
- 35. 35Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
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
- 37. 37Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Communication Between Services
• Use case: New Order Received
- 38. 38Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Handling Failures
• FALLBACK MESSAGE QUEUE
• PER-SERVICE THREAD POOLS
- 39. 39Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Minimising Communicational Overhead
• API GATEWAY
- 40. 40Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Handling Failures in Communication
• CIRCUIT BREAKER
- 41. 41Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE - WHAT?
Concepts
Why?
How?
What?
•Concept
•Technology
- 44. 44Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
Docker - Build, Ship, and Run Any App, Anywhere
- 45. 45Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
Docker - Build, Ship, and Run Any App, Anywhere
- 53. 53Copyright © 2014 by FPT Software
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.
- 54. 54Copyright © 2014 by FPT Software
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.
- 55. 55Copyright © 2014 by FPT Software
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/