Microservices: Decomposing Applications for Deployability and Scalability (jax jax2014)
102 likes23,810 views
This document discusses the benefits of decomposing monolithic applications into microservices to enhance deployability and scalability while simplifying technology adoption. It covers the challenges posed by monolithic architectures and presents various strategies for service interaction, decentralized data management, and the use of APIs and event sourcing for effective communication within distributed systems. The emphasis is on modular, polyglot applications that enable independent development, deployment, and scaling of services.
: T
def update[T](entityId: Id,
version: EntityVersion, events: Seq[Event]): T
def load[T](entityType: Class[T], entityId: EntityId): T
def subscribe(...) : ...
..
}](https://image.slidesharecdn.com/decomposethatwarjax2014-140517141328-phpapp02/85/Microservices-Decomposing-Applications-for-Deployability-and-Scalability-jax-jax2014-72-320.jpg)
![@crichardson
Customer aggregate
case class Customer(customerId: String, creditLimit: BigDecimal)
extends ValidatingAggregate[Customer, CustomerCommands.CustomerCommand] {
def this() = this(null, null)
override def validate = {
case CreateCustomerCommand(customerId, creditLimit) =>
Seq(CustomerCreatedEvent(customerId, creditLimit))
case UpdateCreditLimitCommand(newLimit) if newLimit >= 0 =>
Seq(CustomerCreditLimitUpdatedEvent(newLimit))
}
override def apply = {
case CustomerCreatedEvent(customerId, creditLimit) =>
copy(customerId=customerId, creditLimit=creditLimit)
case CustomerCreditLimitUpdatedEvent(newLimit) =>
copy(creditLimit=newLimit)
}
}
Command
Events
Event
Updated
state](https://image.slidesharecdn.com/decomposethatwarjax2014-140517141328-phpapp02/85/Microservices-Decomposing-Applications-for-Deployability-and-Scalability-jax-jax2014-74-320.jpg)
Microservices: Decomposing Applications for Deployability and Scalability (jax jax2014)
- 1. @crichardson Microservices: Decomposing Applications for Deployability and Scalability Chris Richardson Author of POJOs in Action Founder of the original CloudFoundry.com @crichardson [email protected] http://plainoldobjects.com
- 2. @crichardson Presentation goal How decomposing applications improves deployability and scalability and simplifies the adoption of new technologies
- 4. @crichardson About Chris Founder of a buzzword compliant (stealthy, social, mobile, big data, machine learning, ...) startup Consultant helping organizations improve how they architect and deploy applications using cloud computing, micro services, polyglot applications, NoSQL, ...
- 5. @crichardson Agenda The (sometimes evil) monolith Decomposing applications into services Client service interaction design Decentralized data management
- 6. @crichardson Let’s imagine you are building an online store
- 7. @crichardson Tomcat Traditional application architecture Browser/ Client WAR/EAR MySQL Database Review Service Product Info Service Recommendation Service StoreFrontUI develop test deploy Simple to Load balancer scale Spring MVC Spring Hibernate Order Service HTML REST/JSON
- 8. @crichardson But large, complex, monolithic applications problems
- 10. @crichardson Obstacle to frequent deployments Need to redeploy everything to change one component Interrupts long running background (e.g. Quartz) jobs Increases risk of failure Fear of change Updates will happen less often - really long QA cycles e.g. Makes A/B testing UI really difficult Eggs in one basket
- 11. @crichardson Overloads your IDE and container Slows down development
- 12. @crichardson Lots of coordination and communication required Obstacle to scaling development I want to update the UI But the backend is not working yet!
- 13. @crichardson Requires long-term commitment to a technology stack
- 14. @crichardson Agenda The (sometimes evil) monolith Decomposing applications into services Client service interaction design Decentralized data management
- 15. @crichardson
- 16. @crichardson The scale cube X axis - horizontal duplication Z axis -data partitioning Y axis - functional decomposition Scale by splitting sim ilar things Scale by splitting different things
- 17. @crichardson Y-axis scaling - application level WAR Storefront UI Product Info Service Recommendation Service Review Service Order Service
- 18. @crichardson Y-axis scaling - application level Storefront UI Product Info Service Recommendation Service Review Service Order Service
- 19. @crichardson Product Info Y-axis scaling - application level Product Info Service Recommendation Service Review Service Order Service Browse Products UI Checkout UI Order management UI Account management UI Apply X-axis and Z-axis scaling to each service independently
- 20. @crichardson Service deployment options VM or Physical Machine Docker/Linux container JVM JAR/WAR/OSGI bundle/... Isolation, manageability Density/efficiency
- 21. @crichardson Partitioning strategies... Partition by noun, e.g. product info service Partition by verb, e.g. Checkout UI Single Responsibility Principle Unix utilities - do one focussed thing well
- 22. @crichardson Partitioning strategies Too few Drawbacks of the monolithic architecture Too many - a.k.a. Nano-service anti-pattern Runtime overhead Potential risk of excessive network hops Potentially difficult to understand system Something of an art
- 23. @crichardson Example micro-service using Spring Boot For more on micro-services see http://microservices.io
- 24. @crichardson But more realistically... Focus on building cohesive services that make development and deployment easier - not just tiny services
- 25. @crichardson Real world examples http://highscalability.com/amazon-architecture http://techblog.netflix.com/ http://www.addsimplicity.com/downloads/ eBaySDForum2006-11-29.pdf http://queue.acm.org/detail.cfm?id=1394128 ~600 services 100-150 services to build a page
- 27. @crichardson Complexity of developing and managing a distributed system Using a PaaS can significantly simplify deployment http://contino.co.uk/blog/2013/03/31/microservices-no-free-lunch.html
- 29. @crichardson Deploying features that span multiple services requires careful coordination
- 30. @crichardson When to use it? In the beginning: •You don’t need it •It will slow you down Later on: •You need it •Refactoring is painful
- 31. @crichardson But there are many benefits
- 32. @crichardson Smaller, simpler apps Easier to understand and develop Reduced startup time - important for GAE Less jar/classpath hell - who needs OSGI?
- 33. @crichardson Scales development: develop, deploy and scale each service independently
- 35. @crichardson Eliminates long-term commitment to a single technology stack Modular, polyglot, multi- framework applications
- 36. @crichardson Two levels of architecture System-level Services Inter-service glue: interfaces and communication mechanisms Slow changing Service-level Internal architecture of each service Each service could use a different technology stack Pick the best tool for the job Rapidly evolving
- 37. @crichardson Easily try other technologies ... and fail safely
- 38. @crichardson Agenda The (sometimes evil) monolith Decomposing applications into services Client service interaction design Decentralized data management
- 39. @crichardson How do clients of the system interact with the services?
- 40. @crichardson Directly connecting the front-end to the backend Model View Controller Product Info service Recommendation Service Review service REST REST AMQP Model View Controller Browser/Native App Traditional server-side web application Chatty API Web unfriendly protocols
- 41. @crichardson Use an API gateway Model View Controller Product Info service Recommendation Service Review service REST REST AMQP API Gateway Model View Controller Browser/Native App Single entry point Client specific APIs Protocol translation Traditional server-side web application
- 43. @crichardson Netflix API Gateway http://techblog.netflix.com/2013/01/optimizing-netflix-api.html Device specific end points
- 44. @crichardson API gateway design challenges Performance and scalability Non-blocking I/O Asynchronous, concurrent code Handling partial failures .... http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html
- 45. @crichardson How does a browser interact with the partitioned web application?
- 46. @crichardson Partitioned web app no longer a single base URL Browse Products UI Checkout UI Order management UI Account management UI /products /checkout /orders /account Browser ?
- 47. @crichardson The solution: single entry point that routes based on URL Browse Products UI Checkout UI Order management UI Account management UI /products /checkout /orders /account Content Router Browser http://acme.com/<service>/... Hidden from browser Single entry point
- 48. @crichardson How do the services communicate?
- 49. @crichardson Inter-service communication options Synchronous HTTP asynchronous AMQP Formats: JSON, XML, Protocol Buffers, Thrift, ... Asynchronous is preferred JSON is fashionable but binary format is more efficient
- 50. Pros and cons of messaging Pros Decouples client from server Message broker buffers messages Supports a variety of communication patterns Cons Additional complexity of message broker Request/reply-style communication is more complex
- 51. Pros and cons of HTTP Pros Simple and familiar Request/reply is easy Firewall friendly No intermediate broker Cons Only supports request/ reply Server must be available Client needs to discover URL(s) of server(s)
- 52. @crichardson Discovery option #1: Internal load balancer Load Balancer Product Info Service Product Info Service Product Info Service Product Info Service Client/ API gateway Services register with load balancer Client talks to load balancer Has a well-known location http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/USVPC_creating_basic_lb.html
- 53. @crichardson Discovery option #2: client-side load balancing REST Client Product Info Service Product Info Service Product Info Service Product Info Service Client Service Registry Services register with registry Client polls registry http://techblog.netflix.com/2013/01/announcing-ribbon-tying-netflix-mid.html http://techblog.netflix.com/2012/09/eureka.html
- 54. @crichardson Lots of moving parts! Product Info Product Info Service Recommendation Service Review Service Order Service Browse Products UI Checkout UI Order management UI Account management UI API Gate way Service registry Content Router HTML Browser REST Client Ext. LB Ext. LB
- 55. @crichardson Agenda The (sometimes evil) monolith Decomposing applications into services Client service interaction design Decentralized data management
- 56. @crichardson Decomposed services decomposed databases Order management Customer management Order Database Customer Database Separate databases less coupling
- 57. @crichardson Decomposed databases polyglot persistence IEEE Software Sept/October 2010 - Debasish Ghosh / Twitter @debasishg
- 58. @crichardson Customer management Untangling orders and customers Order management Order Service placeOrder() Customer Service availableCredit() updateCustomer() Customer creditLimit ... has ordersbelongs toOrder total Invariant: sum(order.total) <= creditLimit available credit= creditLimit - sum(order.total) Trouble!
- 59. @crichardson Problems Reads Service A needs to read data owned by service B Updates Transaction must update data owned by multiple services
- 60. @crichardson Handling reads: requesting credit limit Order management placeOrder() Customer management getCreditLimit()
- 61. @crichardson Pulling data Benefits Simple to implement Ensures data is fresh Drawbacks Reduces availability Increases response time
- 62. @crichardson Customer management Handling reads: replicating the credit limit Order management Order Service placeOrder() Customer creditLimit ... Order total Customer’ creditLimit changeCreditLimit() sum(order.total) <= creditLimit Customer Service updateCustomer() Simplified
- 63. @crichardson Useful idea: Bounded context Different services have a different view of a domain object, e.g. User Management = complex view of user Rest of application: User = PK + ACL + Name Different services can have a different domain model
- 64. @crichardson Replicating data Benefits Improved availability for reads Improves latency Drawbacks Additional complexity of replication mechanism
- 65. @crichardson How to handle updates (including of replicated data)?
- 66. @crichardson Use distributed transactions Benefits Guarantees consistency Drawbacks Complex Reduced availability
- 67. @crichardson Use eventual consistency How Services publish events when data changes Subscribing services update their data Benefits: Simpler Better availability Drawbacks: Application has to handle inconsistencies
- 68. @crichardson How do services publish events?
- 69. @crichardson To maintain consistency the application must atomically publish an event whenever a domain object changes
- 70. @crichardson Change tracking options Database triggers Hibernate event listener Ad hoc event publishing code mixed into business logic Domain events - “formal” modeling of events Event Sourcing
- 71. @crichardson Event sourcing An event-centric approach to designing domain models Aggregates handle commands by generating events Apply events update aggregate state Persist events NOT state Replay events to recreate the current state of an aggregate Event Store ≃ database + message broker
- 72. @crichardson EventStore API trait EventStore { def save[T](entityId: Id, events: Seq[Event]): T def update[T](entityId: Id, version: EntityVersion, events: Seq[Event]): T def load[T](entityType: Class[T], entityId: EntityId): T def subscribe(...) : ... .. }
- 73. @crichardson Using event sourcing Event Store CustomerCreditLimitUpdatedEvent Order management Order total Customer’ creditLimit CustomerCreditLimitUpdatedEvent(...) Customer management Customer creditLimit ... Customer Service updateCustomer() UpdateCreditLimitCommand
- 74. @crichardson Customer aggregate case class Customer(customerId: String, creditLimit: BigDecimal) extends ValidatingAggregate[Customer, CustomerCommands.CustomerCommand] { def this() = this(null, null) override def validate = { case CreateCustomerCommand(customerId, creditLimit) => Seq(CustomerCreatedEvent(customerId, creditLimit)) case UpdateCreditLimitCommand(newLimit) if newLimit >= 0 => Seq(CustomerCreditLimitUpdatedEvent(newLimit)) } override def apply = { case CustomerCreatedEvent(customerId, creditLimit) => copy(customerId=customerId, creditLimit=creditLimit) case CustomerCreditLimitUpdatedEvent(newLimit) => copy(creditLimit=newLimit) } } Command Events Event Updated state
- 75. @crichardson Unfamiliar but it solves many problems Eliminates O/R mapping problem Supports both SQL and NoSQL databases Publishes events reliably Reliable eventual consistency framework ...
- 77. @crichardson Monolithic applications are simple to develop and deploy BUT have significant drawbacks
- 78. @crichardson Apply the scale cube Modular, polyglot, and scalable applications Services developed, deployed and scaled independently
- 79. @crichardson Use a modular, polyglot architecture Model View Controller Product Info service Recommendation Service Review service REST REST AMQP API Gateway Model View Controller Server-side web application Browser/Native application
- 80. @crichardson Start refactoring your monolith Monolith Service Anti-corruption layer Glue code Pristine