Microservice Architecture

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. 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

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

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

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

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

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

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/

Microservice Architecture

You are reading a preview.

Check these out next

Microservice Architecture

More Related Content

Slideshows for you (20)

Similar to Microservice Architecture (20)

Recently uploaded (20)

Microservice Architecture