Post on 12-Feb-2018
Micro-service Architecture StyleSMAC ERA…
February 5, 2015
Nguyen Quang TungSolution 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
3Copyright © 2014 by FPT Software
4Copyright © 2014 by FPT Software
WHO IS BIG PLAYER IN THIS GAME!
http://microservices.io/patterns/microservices.html
5Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE - CONCEPTS
Concepts
Why?
How?
What?
•Concept
•Technology
6Copyright © 2014 by FPT Software
SW Architecture in the Context of History
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.
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
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
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
11Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE – WHY?
Concepts
Why?
How?
What?
•Concept
•Technology
12Copyright © 2014 by FPT Software
WHY: EVOLUTION OF SOFTWARE ARCHITECTURE
13Copyright © 2014 by FPT Software
WHY: FROM MONOLITHIC TO CLOUD
14Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
Simple to Develop Simple to Deploy Simple to Scale
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
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
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
18Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• Little Resilience to Failure
Failure in monolith brings it down
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
20Copyright © 2014 by FPT Software
WHY: TYPES OF SCALING
• The Scale Cube
21Copyright © 2014 by FPT Software
WHY: TYPES OF SCALING
22Copyright © 2014 by FPT Software
WHY: TYPES OF SCALING
V1
V2
Re-write a service in 2-3 weeks
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
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
25Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE - HOW-TO?
Concepts
Why?
How?
What?
•Concept
•Technology
26Copyright © 2014 by FPT Software
HOW-TO: PRINCIPLES OF MICROSERVICES
http://12factor.net/
27Copyright © 2014 by FPT Software
HOW-TO: Big Picture!
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. DecentraliseAll The Things
5. Deploy Independently
6. Isolate Failure
7. Highly Observable
29Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
1. Modelled Around Business Domain
Principles Of
Microservices
1. Modelled Around Business Domain
2. Culture Of Automation
3. Hide Implementatio
n Details
4. DecentraliseAll 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!
30Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
2. Culture Of Automation
Principles Of
Microservices
1. Modelled Around Business Domain
2. Culture Of Automation
3. Hide Implementatio
n Details
4. DecentraliseAll The Things
5. Deploy Independently
6. Isolate Failure
7. Highly Observable
Infrastructure Automation
Automated Testing
Continuous Delivery!
31Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
3. Hide Implementation Details
Principles Of
Microservices
1. Modelled Around Business Domain
2. Culture Of Automation
3. Hide Implementatio
n Details
4. DecentraliseAll The Things
5. Deploy Independently
6. Isolate Failure
7. Highly Observable
DatabasesBusiness Partner
Vehicle Service
Business Partner Service
Transport Service
DatabasesVehicle Databases
Transport
DatabasesVehicle
Business PartnerTransport
Vehicle App
Business Partner App
Transport App
Vehicle ContextTransport Context
Business Partner Context
Hide Your Database!
32Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
4. Decentralize All The Things
Principles Of
Microservices
1. Modelled Around Business Domain
2. Culture Of Automation
3. Hide Implementatio
n Details
4. DecentraliseAll The Things
5. Deploy Independently
6. Isolate Failure
7. Highly Observable
What is autonomy?
Giving people as much freedomas possible to do the job at hand
Autonomy!
Self Service
Share Governance
Owner Operator
Internal Open
Source
Dumb-Pipes, Smart
Endpoint
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
Microservices
1. Modelled Around Business Domain
2. Culture Of Automation
3. Hide Implementatio
n Details
4. DecentraliseAll The Things
5. Deploy Independently
6. Isolate Failure
7. Highly Observable
34Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
6. Isolate Failure
Principles Of
Microservices
1. Modelled Around Business Domain
2. Culture Of Automation
3. Hide Implementatio
n Details
4. DecentraliseAll The Things
5. Deploy Independently
6. Isolate Failure
7. Highly Observable
35Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
7. Highly Observable
Principles Of
Microservices
1. Modelled Around Business Domain
2. Culture Of Automation
3. Hide Implementatio
n Details
4. DecentraliseAll The Things
5. Deploy Independently
6. Isolate Failure
7. Highly Observable
Correlation IDs
Aggregation
36Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
37Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Communication Between Services
• Use case: New Order Received
38Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Handling Failures
• FALLBACK MESSAGE QUEUE
• PER-SERVICE THREAD POOLS
39Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Minimising Communicational Overhead
• API GATEWAY
40Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Handling Failures in Communication
• CIRCUIT BREAKER
41Copyright © 2014 by FPT Software
MICROSERVICE ARCHITECTURE - WHAT?
Concepts
Why?
How?
What?
•Concept
•Technology
42Copyright © 2014 by FPT Software
WHAT: TECHNOLOGY
Microservice Implementation Stack
43Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
Deployment Options
44Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
Docker - Build, Ship, and Run Any App, Anywhere
45Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
Docker - Build, Ship, and Run Any App, Anywhere
46Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
DOCKER SOLVES THE NxN PROBLEM
47Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
48Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
CI - Continuous Integration
49Copyright © 2014 by FPT Software
WHAT: DEPLOYMENT
Deployment Options
50Copyright © 2014 by FPT Software
WHAT: BALANCING LOAD
51Copyright © 2014 by FPT Software
WHAT: METRIC & MONITORING
52Copyright © 2014 by FPT Software
WHAT: METRIC & MONITORING
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.
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.
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/
56Copyright © 2014 by FPT Software
Q&A
57Copyright © 2014 by FPT Software