Downloaded 11 times
Microservicessai 141024145932-conversion-gate01 (1)
- 1. Tom De Wolf TechnicalLead tom.dewolf@aca-it.be Stijn Van den Enden CTO stijn.vandenenden@aca-it.be www.aca-it.be Thomas Borghs Solution Engineer thomas.borghs@aca-it.be MICRO SERVICES Yet another architectural style?
- 2. Concepts - Whatare Micro services? Patterns - How to solve the challenges? Technology - Using what?
- 3. The microservice architecturalstyle 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. ! Martin Fowler
- 4. SERVICE ORIENTED ARCHITECTURE? Yes,it’s SOA … but different implementation approach: Classic SOA integrates different applications as a set of services Microservices architect a single application as a set of services
- 5. Classic SOA integrates differentapplications as a set of services Enterprise Service Bus WS* WS* WS* WS* WS* WS* WS* WS* WS* WS* Workflow Engine Intelligence Orchestration
- 6. business platform Microservices architect asingle application as a set of services accounting service contract service ordering service logistics service prospects service capability X service capability Y service external integrationsbackends { API } { API }{ API } { API } { API } { API } { API } { API } { API } { API } { API }
- 7. Classic SOA integrates differentapplications as a set of services Microservices architect a single application as a set of services Typical implementation solution differs! Heavy-weight ESB WS*/SOAP Orchestration License-driven Target problem: Integrate (Legacy) Software Intelligent Communication Layer Light-weight HTTP/REST/JSON Choreography Target problem: Architect new Business Platform Dumb Communication Layer Intelligent Services
- 8.
- 9. SOA WHY - DIFFERENTIATEFROM SOA
- 10. App Server WAR/EAR Ordering Inventory Billing UI WHY -THE CURSE OF THE MONOLITH Database Simple to scaleSimple to develop Simple to deploy
- 11. WHY - THECURSE OF THE MONOLITH App Server WAR/EAR Ordering Inventory Billing UI Large Code Intimidates Developers Hard to understand and modify Development slows down Overloaded IDE Overloaded web container
- 12. WHY - THECURSE 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 App Server WAR/EAR Ordering Inventory Billing UI
- 13. WHY - THECURSE OF THE MONOLITH Big Risk for Re-Write App Server WAR/EAR Ordering Inventory Billing UI No hard module boundaries quality and modularity breaks down over time this enforces eventual need for re-write Re-write = complete re-write no partial re-write Long term commitment to technology stack change or try-out new technology implies re-write
- 14. WHY - THECURSE OF THE MONOLITH App Server WAR/EAR Ordering Inventory Billing UI Failure in monolith brings it down Little Resilience to Failure
- 15. WHY - THECURSE OF THE MONOLITH App Server WAR/EAR Ordering Inventory Billing UI Mostly Horizontal scaling many load balanced instances Scaling can be difficult Hard to scale to data growth cope with all data Different components have different resource needs Scaling development implies coordination overhead
- 16. WHY - TYPESOF SCALING App Server WAR/EAR Ordering Inventory Billing UI Database All data App Server WAR/EAR Ordering Inventory Billing UI App Server WAR/EAR Ordering Inventory Billing UI Horizontal Scaling (monolith) Vertical Scaling App Server WAR/EAR Ordering Inventory Billing UI App Server WAR/EAR Ordering Inventory Billing UI Database All data (monolith) Data Scaling App Server WAR/EAR Ordering Inventory Billing UI Database segment App Server WAR/EAR Ordering Inventory Billing UI App Server WAR/EAR Ordering Inventory Billing UI Database segment Database segment (monolith)
- 17. WHY - TYPESOF SCALING Database Ordering Container UI Functional Scaling Container Ordering Container Inventory Container Billing Container Ordering Container Ordering Container Billing Database Inventory Database Billing (micro-services) Team Scaling Container Ordering Container Inventory Container Billing (micro-services) balances application and development complexity
- 18. • Small andfocussed 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 • Decentralised choreography • vs central orchestration • vs central point of failure • Decentralised data • polyglot persistence WHY - ARCHITECTURAL BENEFITS
- 19. WHY - EVOLUTIONARYARCHITECTURE 1 - Key (business) drivers guide architectural decisions 2 - Postpone decisions to Last Responsible Moment 3 - Architect and develop for Evolvability Micro-services are organised around business capabilities Micro-services allow delay of scaling and technological decisions Micro-services support evolution in technology, scaling, and features
- 20.
- 21. HOW TO Approach -Key to success Challenges - And ways to overcome them
- 22. Functional decomposition ofthe business domain
- 23. Functional decomposition ofthe business domain Software Design Customer Satisfaction Separation of Concerns Low Coupling, High Cohesion Reduce Impact by Encapsulating Source of Change Predictable Cost of Change Changes are Business Driven Source of Change = Business Functional Modularisation
- 24. B A B A Functional decompositionof the business domain • Change A impacts all modules = costly • Change B requires split of module = costly • Change A only impacts other module if api change • Change B limited to module
- 25. side note: DomainDriven Design “In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.” From: Domain Driven Design by Eric Evans. Tackling complexity by abstracting the business domain concepts and logic into a domain model and using this as a base for software development
- 26. Domain driven designdeals with large complex models by dividing them into different functionally bounded subdomains and the explicitly describing the interrelations between these subdomains. Bounded contexts
- 27. Functional decomposition ofthe business domain ONLINE STORE Ordering Billing Inventory Accounting
- 28. Functional decomposition ofthe business domain AccountingInventory BillingOrdering customer Invoice balance order item item stock order order item incoming cash outgoing cash stock
- 29. Benefits of functionaldecomposition
- 30. AccountingInventory BillingOrdering customer Invoice balance order item item stock order order item incoming cash outgoingcash stock Benefits of functional decomposition
- 31. Applying services tobounded contexts Accounting ServiceInventory Service Billing ServiceOrdering Service customer Invoice balance order item item stock order order item incoming cash outgoing cash stock AccountingInventory BillingOrdering customer Invoice balance order item item stock order order item incoming cash outgoing cash stock
- 32. Any organization thatdesigns a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. ! -- Melvyn Conway, 1967 Side note: Conway’s Law
- 33. Side note: Conway'sLaw Technology-based Team Composition Functional Team Composition Ordering InventoryBilling Accounting Container Ordering Container Billing Container Inventory Container Accounting UI UI
- 34. Leads to highercoupling between services PITFALL: Incorrect functional decomposition - harder to functionally scale the application - errors will propagate through multiple services - graceful degradation will be harder to achieve - team development overhead - T-scaling becomes harder - large communicational overhead between services - large overhead in releasing/deploying business features - refactoring to correct decomposition is costly most of the microservices architectural benefits are lost
- 35. PITFALL: Incorrect functional decomposition Saferto start with a functionally well decomposed monolith and evolve it to a microservices architecture when the need arises - rewriting failure scenario’s - decentralised data - service contract redesign Refactoring the initial functional decomposition will be easier in a monolith
- 36. Approach - Keyto success Challenges - And ways to overcome them
- 37. - Keep Releasesand deployments manageable - high level of automation is needed - Service monitoring is required - Configuration management becomes more complex CHALLENGE #1: Operational Complexity Complex Runtime: many moving parts
- 38. - distributed architecturalproperties to consider: - decentralised data - communication between services - handling failures of components - testing effort becomes greater CHALLENGE #2: Distributed Development Services are deployed on multiple instances
- 39. Decentralised data Each servicehas its own database - loose coupling Might even be in another database technology Data duplication between services might be required to ensure loose coupling When implementing use cases spanning multiple services: distributed transactions vs eventual consistency
- 40. Distributed Transactions vsEventual Consistency DISTRIBUTED TRANSACTIONS - data is always consistent ! - reduces system availability - services are more tightly coupled - has fallen out of favor in modern stacks (REST, NoSQL)
- 41. Distributed Transactions vsEventual Consistency EVENT-DRIVEN ASYNCHRONOUS UPDATES - use a message broker to publish use cases to other services - decouples producers and consumers (services) of events - improves availability - tradeoff between availability and data consistenty - application needs to be able to handle eventually consistent data
- 42. Communication between services Usecases can span multiple services What type of communication is best used to implement such a use case? Network properties need to be taken into account
- 43. What type ofCommunication? SYNCHRONOUS HTTP-BASED - easy - firewall-friendly, works across the internet ! - doesn’t support publisher-subscriber patterns - client and server must both be available simultaneously - client needs to know host and port of server
- 44. What type ofCommunication? ASYNCHRONOUS NON-BLOCKING - Client doesn’t block calling thread - allows for parallelism ! - client and server still must both be available simultaneously - client still needs to know host and port of server
- 45. What type ofCommunication? ASYNCHRONOUS MESSAGING - For example through a Broker - decouples message producers from consumers - broker can buffer messages - supports a variety of communication patterns ! - broker is another moving part - adds complexity - request-reply communication pattern is not a natural fit
- 46. What type ofCommunication? Accounting ServiceInventory Service Billing ServiceOrdering Service Use case: New Order Received New order Create invoice Update Incoming CashflowUpdate Stock
- 47. Handling Failures Services canfail at any moment Design services to handle these kind of failures
- 48. Reactive systems are: Responsive Resilient Elastic MessageDriven ! -- Reactive Manifesto: september 16 2014 Side note: Reactive Programming
- 49. Handling Failures FALLBACK MESSAGEQUEUE Ordering Service Billing Service new order received failure Fallback queue
- 50. Handling Failures PER-SERVICE THREADPOOLS Ordering Service Billing Service new order received Thread pool 10 threads
- 51. - communication betweenservices is reduced - when functional decomposition is done right - when service size isn’t too small - reduce communication between clients and Services with an API gateway - executing service calls in parallel reduces impact of communication overhead - reduce unneeded network usage by using circuit breakers CHALLENGE #3 Minimising Communicational Overhead Avoid Chatty Communication
- 52. Minimising Communicational Overhead APIGATEWAY Ordering Inventory Billing Accounting Monolith Micro Services Container Ordering Container Inventory Container Billing Container Accounting Desktop client Mobile client Desktop client Mobile client
- 53. Minimising Communicational Overhead APIGATEWAY Container Ordering Container Inventory Container Billing Container Accounting Desktop client Mobile client Api gateway
- 54. Handling Failures inCommunication CIRCUIT BREAKER - Wrap a protected function in a circuit breaker - Monitor protected function for failures - The circuit breaks when a predefined threshold of fails is reached - All future calls to the function go to fallback until the circuit is restored
- 55. Handling Failures inCommunication CIRCUIT BREAKER Ordering Service Billing Service new order received Circuit breaker Threshold = 10 Fallback queue
- 56.
- 57.
- 58.
- 59.
- 60. java -jar ./target/profileservice-0.1.0-SNAPSHOT.jarserver ./src/ main/resources/userprofileservice.yml
- 61. SPRING BOOT opinionated viewof building production-ready Spring applications
- 62. •Convention over configuration approach •Deployableas a Self-contained jar or war •Tackles dependency-hell via pre-packaging •Support for monitoring and metrics (actuator module)
- 63.
- 64. Compute, Storage, Network HostOS Hypervisor VM1 VM2 MicroService MicroService Guest OS JVM Guest OS JVM VM’s abstract underlying hardware, but limit resource utilisation Compute, Storage, Network Host OS container1 container2 container3 container4 JVM JVM JVM MicroService MicroService MicroService JVM MicroService Containers have own isolated resources
- 66. Static website WebfrontendUser DB Queue Analytics DB Developmen t VM QA server Public Cloud Contributor’s laptop DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODEMultiplicityofStacks Multiplicityof hardware environments Production Cluster Customer Data Center Doservicesand appsinteract appropriately? CanImigrate smoothlyand quickly …that can be manipulated using standard operations and run consistently on virtually any hardware platform An engine that enables any payload to be encapsulated as a lightweight, portable, self-sufficient container…
- 67. Static website WebfrontendUser DB Queue Analytics DB Developmen t VM QA server Public Cloud Contributor’s laptop DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODEMultiplicityofStacks Multiplicityof hardware environments Production Cluster Customer Data Center Doservicesand appsinteract appropriately? CanImigrate smoothlyand quickly Operator: Configure Once, Run Anything Developer: Build Once, Run Anywhere
- 68. Static website Web frontend Backgroundworkers User DB Analytics DB Queue Development VM QA Server Single Prod Server Onsite Cluster Public Cloud Contributor’s laptop Customer Servers DOCKER SOLVES THE NXN PROBLEM
- 69. • Isolation • namespace •pid mnt net uts ipc user • resource usage • (CPU, memory, disk I/O, etc.) • Limited impact on Performance - http://ibm.co/V55Otq • Daemon and CLI Compute, Storage, Network Host OS container1 container2 container3 container4 JVM JVM JVM MicroService MicroService MicroService JVM MicroService
- 70. Source Control System DockerFile Continuous Integration Infrastructure ContainerImage Repository Compute, Storage, Network Host OS daemon container1 JVM MicroService pull Slave Node Host OS push build provision container1 JVM MicroService
- 71.
- 72. Compute, Storage, Network HostOS Hypervisor VM1 VM2 MicroService MicroService Guest OS JVM Guest OS JVM Compute, Storage, Network Host OS container1 container2 container3 container4 JVM JVM JVM MicroService MicroService MicroService JVM MicroService VM’s abstract underlying hardware, but limit resource utilisation Containers have own isolated resources OSGi Runtime JVM MicroService Compute, Storage, Network Host OS MicroService MicroService Microservice run in their own isolated classloader and standbox in the JVM
- 73.
- 74. Static Dynamic Loadbalancer Loadbalancer MicroService MicroServiceMicroService MicroService MicroService Web Front End Web Front End Web Front End Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService A B Midtier Service Registry MicroService register renew get registry
- 75. Static Dynamic Loadbalancer Loadbalancer MicroService MicroServiceMicroService MicroService MicroService Web Front End Web Front End Web Front End Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService A B Midtier Service Registry MicroService register renew get registry eureka ribbon https://github.com/Netflix/eureka https://github.com/Netflix/ribbon
- 78. The Story * basedon Functional Programming the Netflix API - Ben Christensen
- 79. Netflix API Dependency A DependencyD Dependency G Dependency J Dependency M Dependency P Dependency B Dependency E Dependency H Dependency K Dependency N Dependency Q Dependency C Dependency F Dependency I Dependency L Dependency O Dependency R * based on Functional Programming the Netflix API - Ben Christensen
- 80. Discovery of Rxbegan with a re-architecture ... * based on Functional Programming the Netflix API - Ben Christensen
- 81. ... that collapsednetwork traffic into coarse API calls ... * based on Functional Programming the Netflix API - Ben Christensen
- 82. Iterable pull Observable push T next() throws Exception returns; onNext(T) onError(Exception) onCompleted() !//"Iterable<String>" !//"that"contains"75"Strings !getDataFromLocalMemory() !!.skip(10) !!.take(5) !!.map({!s!%>! !!!return!s!+!"_transformed"}) !!.forEach( .....{!println!"next!=>!"!+!it}) !//"Observable<String>" !//"that"emits"75"Strings !getDataFromNetwork() !!.skip(10) !!.take(5) !!.map({!s!%>! !!!return!s!+!"_transformed"}) !!.subscribe( .....{!println!"onNext!=>!"!+!it}) *based on Functional Programming the Netflix API - Ben Christensen
- 83. * based onFunctional Programming the Netflix API - Ben Christensen
- 84. * based onFunctional Programming the Netflix API - Ben Christensen
- 85.
- 86. HystrixCommand run() getFallback() run() failure/circuit open publicclass GetUserPerferencesCommand extends HystrixCommand<UserPreferences> {! // ..//! ! @Override! protected UserPreferences run() {! ! ! // call the UserPreferencesService ! }! ! @Override! protected UserPreferences getFallback() {! !! return UserPreference.empty();! }! }
- 88.
- 89. MicroService MicroService MicroServiceMicroService MicroServiceA Logstash Log Aggregation Graphite Metrics and Monitoring
- 91. - Correct Functionaldecomposition is crucial - reflect it in a organisational structure (Conway’s law) - pretty hard to get right from the start - A modular system can evolve to microservices - balance the needs (advantages) with the costs (tradeoffs) Conclusion Are they here to stay? who can tell? but the monolith is dead