Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Micro-service Architecture Style
SMAC ERA…
February 5, 2015
Nguyen Quang Tung
Solution Architect
M: 0127 666 0909
E: tungn...
2Copyright © 2014 by FPT Software
WHO AM I?
Nguyen Quang Tung
•E1: tungnq@fsoft.com.vn
•E2: tungnq@gmail.com
•M: +84127666...
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...
8Copyright © 2014 by FPT Software
Concepts: SERVICE ORENTED ARCHITECTURE (SOA)?
Classic SOA
•Integrates different
applicat...
9Copyright © 2014 by FPT Software
Concepts: CLASSIC SOA vs MICROSERVICE
Classic SOA
• Integrates different applications as...
10Copyright © 2014 by FPT Software
Concepts: CLASSIC SOA vs MICROSERVICE
MICROSERVICE
• Architect a single application as ...
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
Overload...
16Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• Small Change - Big Impact
Any change requires full
re...
17Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• Big Risk for Re-Write
No hard module boundaries
Qual...
18Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• Little Resilience to Failure
Failure in monolith brin...
19Copyright © 2014 by FPT Software
WHY: THE CURSE OF THE MONOLITH
• Scaling can be difficult
Mostly Horizontal scaling ma...
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
•ID...
24Copyright © 2014 by FPT Software
WHY: ARCHITECTURE EVOLUTION
1 - Key (business) drivers guide architectural decisions
• ...
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
Bu...
29Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
1. Modelled Around Business Domain
Principles
Of
...
30Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
2. Culture Of Automation
Principles
Of
Microservi...
31Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
3. Hide Implementation Details
Principles
Of
Micr...
32Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
4. Decentralize All The Things
Principles
Of
Micr...
33Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
5. Deploy Independently
Deployment
One
Service
Pe...
34Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
6. Isolate Failure
Principles
Of
Microservic
es
1...
35Copyright © 2014 by FPT Software
HOW-TO: 7 PRINCIPLES OF MICROSERVICES
7. Highly Observable
Principles
Of
Microservic
es...
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 Re...
38Copyright © 2014 by FPT Software
HOW-TO: MICROSERVICE CHALLENGES
Handling Failures
• FALLBACK MESSAGE QUEUE
• PER-SERVIC...
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 fo...
54Copyright © 2014 by FPT Software
CONCLUSION
Disadvantages of Microservice Architecture
• Microservice architecture bring...
55Copyright © 2014 by FPT Software
REFERENCE
 Microservices - http://martinfowler.com/articles/microservices.html
 Micro...
56Copyright © 2014 by FPT Software
Q&A
57Copyright © 2014 by FPT Software
Prochain SlideShare
Chargement dans…5
×

Microservice Architecture

5 047 vues

Publié le

Microservice - Concept, Why, How, What

Publié dans : Technologie

Microservice Architecture

  1. 1. 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
  2. 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
  3. 3. 3Copyright © 2014 by FPT Software
  4. 4. 4Copyright © 2014 by FPT Software WHO IS BIG PLAYER IN THIS GAME! http://microservices.io/patterns/microservices.html
  5. 5. 5Copyright © 2014 by FPT Software MICROSERVICE ARCHITECTURE - CONCEPTS Concepts Why? How? What? •Concept •Technology
  6. 6. 6Copyright © 2014 by FPT Software SW Architecture in the Context of History
  7. 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. 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. 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. 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. 11. 11Copyright © 2014 by FPT Software MICROSERVICE ARCHITECTURE – WHY? Concepts Why? How? What? •Concept •Technology
  12. 12. 12Copyright © 2014 by FPT Software WHY: EVOLUTION OF SOFTWARE ARCHITECTURE
  13. 13. 13Copyright © 2014 by FPT Software WHY: FROM MONOLITHIC TO CLOUD
  14. 14. 14Copyright © 2014 by FPT Software WHY: THE CURSE OF THE MONOLITH Simple to Develop Simple to Deploy Simple to Scale
  15. 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. 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. 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. 18. 18Copyright © 2014 by FPT Software WHY: THE CURSE OF THE MONOLITH • Little Resilience to Failure Failure in monolith brings it down
  19. 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
  20. 20. 20Copyright © 2014 by FPT Software WHY: TYPES OF SCALING • The Scale Cube
  21. 21. 21Copyright © 2014 by FPT Software WHY: TYPES OF SCALING
  22. 22. 22Copyright © 2014 by FPT Software WHY: TYPES OF SCALING V1 V2 Re-write a service in 2-3 weeks
  23. 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. 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. 25. 25Copyright © 2014 by FPT Software MICROSERVICE ARCHITECTURE - HOW-TO? Concepts Why? How? What? •Concept •Technology
  26. 26. 26Copyright © 2014 by FPT Software HOW-TO: PRINCIPLES OF MICROSERVICES http://12factor.net/
  27. 27. 27Copyright © 2014 by FPT Software HOW-TO: Big Picture!
  28. 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. 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. 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. 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. 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. 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. 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. 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
  36. 36. 36Copyright © 2014 by FPT Software HOW-TO: MICROSERVICE CHALLENGES
  37. 37. 37Copyright © 2014 by FPT Software HOW-TO: MICROSERVICE CHALLENGES Communication Between Services • Use case: New Order Received
  38. 38. 38Copyright © 2014 by FPT Software HOW-TO: MICROSERVICE CHALLENGES Handling Failures • FALLBACK MESSAGE QUEUE • PER-SERVICE THREAD POOLS
  39. 39. 39Copyright © 2014 by FPT Software HOW-TO: MICROSERVICE CHALLENGES Minimising Communicational Overhead • API GATEWAY
  40. 40. 40Copyright © 2014 by FPT Software HOW-TO: MICROSERVICE CHALLENGES Handling Failures in Communication • CIRCUIT BREAKER
  41. 41. 41Copyright © 2014 by FPT Software MICROSERVICE ARCHITECTURE - WHAT? Concepts Why? How? What? •Concept •Technology
  42. 42. 42Copyright © 2014 by FPT Software WHAT: TECHNOLOGY Microservice Implementation Stack
  43. 43. 43Copyright © 2014 by FPT Software WHAT: DEPLOYMENT Deployment Options
  44. 44. 44Copyright © 2014 by FPT Software WHAT: DEPLOYMENT Docker - Build, Ship, and Run Any App, Anywhere
  45. 45. 45Copyright © 2014 by FPT Software WHAT: DEPLOYMENT Docker - Build, Ship, and Run Any App, Anywhere
  46. 46. 46Copyright © 2014 by FPT Software WHAT: DEPLOYMENT DOCKER SOLVES THE NxN PROBLEM
  47. 47. 47Copyright © 2014 by FPT Software WHAT: DEPLOYMENT
  48. 48. 48Copyright © 2014 by FPT Software WHAT: DEPLOYMENT CI - Continuous Integration
  49. 49. 49Copyright © 2014 by FPT Software WHAT: DEPLOYMENT Deployment Options
  50. 50. 50Copyright © 2014 by FPT Software WHAT: BALANCING LOAD
  51. 51. 51Copyright © 2014 by FPT Software WHAT: METRIC & MONITORING
  52. 52. 52Copyright © 2014 by FPT Software WHAT: METRIC & MONITORING
  53. 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. 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. 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/
  56. 56. 56Copyright © 2014 by FPT Software Q&A
  57. 57. 57Copyright © 2014 by FPT Software

×