MicroServices, yet another architectural style?
79 likes10,961 views
The document discusses microservices as a modern architectural style for developing applications, emphasizing their independence, scalability, and the shift from traditional monolithic systems. It presents the advantages and challenges of microservices, including complex operational needs, the importance of functional decomposition, and communication strategies. The document also highlights technologies like Docker for containerization, outlining the need for automation and monitoring in microservices architecture.
MicroServices, yet another architectural style?
- 1. Stijn Van den Enden CTO stijn.vandenenden@aca-it.be Tom De Wolf Technical Lead tom.dewolf@aca-it.be www.aca-it.be Thomas Borghs Solution Engineer thomas.borghs@aca-it.be MICRO SERVICES Yet another architectural style?
- 2. Concepts - What are Micro services? Patterns - How to solve the challenges? Technology - Using what?
- 3. The microservice 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. ! 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 different applications as a set of services Microservices WS* WS* WS* WS* WS* Enterprise Service Bus Workflow Engine Orchestration Intelligence WS* WS* WS* WS* WS*
- 6. business platform { API } { API } { API } accounting ordering service service contract { API } { API } Microservices service architect a single application as a set of services prospects logistics service service capability X service capability Y service backends external integrations { API } { API } { API } { API } { API } { API }
- 7. Classic SOA Typical implementation solution differs! integrates different applications as a set of services Heavy-weight Microservices Orchestration Intelligent Communication Layer architect a single application as a set of services ESB WS*/SOAP License-driven Target problem: Integrate (Legacy) Software Light-weight Choreography HTTP/REST/JSON Dumb Communication Layer Target problem: Intelligent Services Architect new Business Platform
- 8. WHY
- 9. SOA WHY - DIFFERENTIATE FROM SOA
- 10. Simple to develop Simple to deploy Simple to scale WAR/EAR UI Ordering Inventory Billing App Server Database WHY - THE CURSE OF THE MONOLITH
- 11. Large Code Intimidates Developers Hard to understand WAR/EAR UI Ordering Inventory Billing App Server and modify Overloaded web container Development slows down Overloaded IDE WHY - THE CURSE OF THE MONOLITH
- 12. 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 WAR/EAR UI Ordering Inventory Billing App Server WHY - THE CURSE OF THE MONOLITH
- 13. Big Risk for Re-Write WAR/EAR UI Ordering Inventory Billing App Server 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 WHY - THE CURSE OF THE MONOLITH
- 14. Little Resilience to Failure WAR/EAR UI Failure in monolith Ordering Inventory Billing App Server brings it down WHY - THE CURSE OF THE MONOLITH
- 15. Scaling can be difficult WAR/EAR UI Ordering Inventory Billing App Server 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 WHY - THE CURSE OF THE MONOLITH
- 16. Horizontal Scaling WAR/EAR UI Ordering Inventory Billing App Server (monolith) WAR/EAR UI Ordering Inventory Billing App Server Database All data WAR/EAR UI Ordering Inventory Billing App Server Vertical Scaling WAR/EAR UI Ordering Inventory Billing App Server WAR/EAR UI Ordering Inventory Billing App Server (monolith) Database All data WHY - TYPES OF SCALING Data Scaling WAR/EAR UI Ordering Inventory Billing App Server WAR/EAR UI Ordering Inventory Billing App Server Database segment WAR/EAR UI Ordering Inventory Billing App Server Database segment Database segment (monolith)
- 17. Ordering Container Ordering Container Ordering Container Database Ordering Functional Scaling (micro-services) UI Container Inventory Container Billing Container Billing Container Database Inventory Database Billing Ordering WHY - TYPES OF SCALING Team Scaling Container Inventory Container Billing Container (micro-services) balances application and development complexity
- 18. • Small and focussed 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. 1 - Key (business) drivers guide architectural decisions Micro-services are organised 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 WHY - EVOLUTIONARY ARCHITECTURE
- 20. HOW TO
- 21. Approach - Key to success Challenges - And ways to overcome them HOW TO
- 22. Functional decomposition of the business domain
- 23. Functional decomposition of the 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. Functional decomposition of the business domain B A B A • 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: Domain Driven Design Tackling complexity by abstracting the business domain concepts and logic into a domain model and using this as a base for software development “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.
- 26. Bounded contexts Domain driven design deals with large complex models by dividing them into different functionally bounded subdomains and the explicitly describing the interrelations between these subdomains.
- 27. Functional decomposition of the business domain Ordering Billing ONLINE STORE Inventory Accounting
- 28. Functional decomposition of the business domain Ordering Billing customer Inventory Accounting Invoice balance order item item stock order order item incoming cash outgoing cash stock
- 29. Benefits of functional decomposition
- 30. Ordering Billing customer Inventory Accounting Invoice balance order item item stock order order item incoming cash outgoing cash stock Benefits of functional decomposition
- 31. Applying services to bounded contexts Ordering Service Billing Service customer Inventory Service Accounting Service Invoice balance order item item stock order order item incoming cash outgoing cash stock
- 32. Side note: Conway’s Law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. ! -- Melvyn Conway, 1967
- 33. Side note: Conway's Law Technology-based Team Composition Functional Team Composition Billing Inventory Ordering Accounting Ordering Container Billing Container Inventory Container Accounting Container UI UI
- 34. PITFALL: Incorrect functional decomposition Leads to higher coupling between services most of the microservices architectural benefits are lost - 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
- 35. PITFALL: Incorrect functional decomposition Safer to start with a functionally well decomposed monolith and evolve it to a microservices architecture when the need arises Refactoring the initial functional decomposition will be easier in a monolith - rewriting failure scenario’s - decentralised data - service contract redesign
- 36. Approach - Key to success Challenges - And ways to overcome them
- 37. CHALLENGE #1: Operational Complexity Complex Runtime: many moving parts - Keep Releases and deployments manageable - high level of automation is needed - Service monitoring is required - Configuration management becomes more complex
- 38. CHALLENGE #2: Distributed Development Services are deployed on multiple instances - distributed architectural properties to consider: - decentralised data - communication between services - handling failures of components - testing effort becomes greater
- 39. Decentralised data Each service has 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 vs Eventual 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 vs Eventual 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 Network properties need to be taken into account Use cases can span multiple services What type of communication is best used to implement such a use case?
- 43. What type of Communication? 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 of Communication? 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 of Communication? 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 of Communication? Use case: New Order Received New order Create invoice Ordering Service Billing Service Update Stock Update Incoming Cashflow Inventory Service Accounting Service
- 47. Handling Failures Services can fail at any moment Design services to handle these kind of failures
- 48. Side note: Reactive Programming Reactive systems are: Responsive Resilient Elastic Message Driven ! -- Reactive Manifesto: september 16 2014
- 49. Handling Failures FALLBACK MESSAGE QUEUE Ordering Service new order received Billing Service failure Fallback queue
- 50. Handling Failures PER-SERVICE THREAD POOLS Ordering Service Billing Service new order received Thread pool 10 threads
- 51. CHALLENGE #3 Minimising Communicational Overhead Avoid Chatty Communication - communication between services 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
- 52. Minimising Communicational Overhead API GATEWAY Monolith Micro Services Ordering Inventory Billing Accounting Ordering Container Inventory Container Billing Container Accounting Container Desktop client Mobile client Desktop client Mobile client
- 53. Minimising Communicational Overhead API GATEWAY Ordering Container Inventory Container Billing Container Accounting Container Desktop client Mobile client Api gateway
- 54. Handling Failures in Communication 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 in Communication CIRCUIT BREAKER Ordering Service Billing Service new order received Circuit breaker Threshold = 10 Fallback queue
- 56. TECHNOLOGY
- 58. DROPWIZARD Make features not WAR
- 59. DROPWIZARD guava jackson metrics Validator YAML JDBI core migrations hibernate jdbi …
- 60. java -jar ./target/profileservice-0.1.0-SNAPSHOT.jar server ./src/ main/resources/userprofileservice.yml
- 61. SPRING BOOT opinionated view of building production-ready Spring applications
- 62. • Convention over configuration approach • Deployable as a Self-contained jar or war •Tackles dependency-hell via pre-packaging • Support for monitoring and metrics (actuator module)
- 63. Deployment
- 64. VM’s abstract underlying hardware, but limit resource utilisation MicroService MicroService JVM VM1 VM2 JVM Guest OS Guest OS Hypervisor Host OS Compute, Storage, Network Containers have own isolated resources MicroService MicroService MicroService JVM JVM JVM container2 container3 Host OS MicroService JVM container1 container4 Compute, Storage, Network
- 66. DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE Static website User DB Web frontend Queue Analytics DB Developmen t VM QA server Public Cloud Contributor’s laptop Multiplicity of Stacks Multiplicity of hardware environments Production Cluster Customer Data Center Do services and apps interact appropriately? Can I migrate smoothly and 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. DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE Static website User DB Web frontend Queue Analytics DB Developmen t VM QA server Public Cloud Contributor’s laptop Multiplicity of Stacks Multiplicity of hardware environments Production Cluster Customer Data Center Do services and apps interact appropriately? Can I migrate smoothly and quickly Operator: Configure Once, Run Anything Developer: Build Once, Run Anywhere
- 68. DOCKER SOLVES THE NXN PROBLEM Static website Web frontend Background workers User DB Analytics DB Queue Development VM QA Server Single Prod Server Onsite Cluster Public Cloud Contributor’s laptop Customer Servers
- 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 MicroService MicroService MicroService JVM JVM JVM container2 container3 Host OS MicroService JVM container1 container4 Compute, Storage, Network
- 70. Continuous Integration Infrastructure Source Control System DockerFile Container Image Repository Host OS pull daemon MicroService JVM container1 Compute, Storage, Network MicroService JVM Host OS Slave Node push build provision container1
- 71. https://github.com/spotify/helios http://mesos.apache.org/ https://github.com/openshift/geard … Private Hybrid Public
- 72. MicroService MicroService JVM VM1 VM2 JVM Guest OS Guest OS Hypervisor Host OS Compute, Storage, Network MicroService MicroService MicroService JVM JVM JVM container2 container3 Host OS MicroService JVM container1 container4 Compute, Storage, Network VM’s abstract underlying hardware, but limit resource utilisation Containers have own isolated resources Microservice run in their own isolated classloader and standbox in the JVM OSGi Runtime MicroService MicroService JVM MicroService Host OS Compute, Storage, Network
- 73. Balancing Load
- 74. Static Dynamic Loadbalancer Loadbalancer Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService 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 Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService Web Front End Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService A B https://github.com/Netflix/ribbon Midtier Service Registry MicroService register renew get registry eureka ribbon https://github.com/Netflix/eureka
- 78. The Story * based on Functional Programming the Netflix API - Ben Christensen
- 79. Netflix API Dependency A Dependency D Dependency G Dependency B Dependency J Dependency E Dependency M Dependency H Dependency P Dependency C Dependency K Dependency F Dependency N Dependency I Dependency Q Dependency L Dependency O Dependency R * based on Functional Programming the Netflix API - Ben Christensen
- 80. Discovery of Rx began with a re-architecture ... * based on Functional Programming the Netflix API - Ben Christensen
- 81. ... that collapsed network 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 on Functional Programming the Netflix API - Ben Christensen
- 84. * based on Functional Programming the Netflix API - Ben Christensen
- 86. HystrixCommand run() failure/circuit open getFallback() public class GetUserPerferencesCommand extends HystrixCommand<UserPreferences> {! // ..//! ! @Override! protected UserPreferences run() {! ! ! // call the UserPreferencesService ! }! ! @Override! protected UserPreferences getFallback() {! !! return UserPreference.empty();! }! }
- 88. Monitoring
- 89. A MicroService MicroService MicroService MicroService MicroService Logstash Log Aggregation Graphite Metrics and Monitoring
- 91. - Correct Functional decomposition is crucial Conclusion - 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) Are they here to stay? who can tell? but the monolith is dead