Downloaded 98 times
![Better: Futures with callbacks
val f : Future[Int] = Future { ... }
f onSuccess {
case x : Int => println(x)
}
f onFailure {
case e : Exception => println("exception thrown")
}
Guava ListenableFutures,
Java 8 CompletableFuture, Scala Futures
@crichardson](https://image.slidesharecdn.com/decomposethatwarjmaghreb2013-131118110928-phpapp02/75/Decompose-That-WAR-Architecting-for-Adaptability-Scalability-and-Deployability-jmaghreb-jmaghreb2013-56-2048.jpg)
Uploaded byChris Richardson
Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability (jmaghreb, jmaghreb2013)
This document summarizes a presentation about decomposing monolithic applications into microservices. The presentation discusses how monolithic architectures can be difficult to deploy, scale, and update. It then introduces strategies for decomposing a monolith into independent services, such as extracting new functionality or splitting the frontend from the backend. The presentation also covers best practices for service communication, including using an API gateway and futures to handle asynchronous requests. Overall, the document advocates for a modular, polyglot architecture using independent, interoperable services to improve deployability, scalability, and adaptability compared to a monolithic application.
More Related Content
Similar to Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability (jmaghreb, jmaghreb2013)
Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability (jmaghreb, jmaghreb2013)
- 1. Decompose That WAR! Architectingfor Adaptability, Scalability, and Deployability Chris Richardson Author of POJOs in Action Founder of the original CloudFoundry.com @crichardson chris@chrisrichardson.net http://plainoldobjects.com @crichardson
- 2. Presentation goal How decomposingapplications improves deployability and scalability and simplifies the adoption of new technologies @crichardson
- 3.
- 4.
- 5.
- 6.
- 7. Agenda The (sometimes evil)monolith Decomposing applications into services API gateway design Refactoring the monolith @crichardson
- 8. Let’s imagine youare building an online store @crichardson
- 9. Traditional application architecture WAR/EAR StoreFrontUI Browser Apache/ Load balancer Spring MVC ProductInfo Service Recommendation Service Spring Hibernate MySQL Database Review Service Simple to develop test deploy scale Order Service Tomcat @crichardson
- 10. But there areproblems with a monolithic architecture @crichardson
- 11. Users expect arich, dynamic and interactive experience @crichardson
- 12. Presentation layer evolution.... WAR Browser Old HTML/ HTTPre tu e tyl s Ia U h ug o StoreFrontUI en d oo ’t g Controller isn View c ite rch Model @crichardson
- 13. ...Presentation layer evolution Browser- desktop and mobile View Web application Controller Model Static content JSON-REST HTML 5 - JavaScript Native mobile client IoS or Android Events RESTful Endpoints Event publisher No elaborate, server-side web framework required @crichardson
- 14.
- 15. Obstacle to frequent deployments Needto redeploy everything to change one component Interrupts long running background (e.g. Quartz) jobs Increases risk of failure Eggs in one basket Fear of change Updates will happen less often - really long QA cycles e.g. Makes A/B testing UI really difficult @crichardson
- 16. Overloads your IDEand container Slows down development @crichardson
- 17.
- 18. Obstacle to scaling development WAR UIteam StoreFrontUI Product Info team Product Info service Recommendations team Recommendation service Reviews team Review service Orders team Order service @crichardson
- 19. Obstacle to scaling development Iwant to update the UI But the backend is not working yet! Lots of coordination and communication required @crichardson
- 20. Requires long-term commitment toa technology stack @crichardson
- 21. Agenda The (sometimes evil)monolith Decomposing applications into services API gateway design Refactoring the monolith @crichardson
- 22.
- 23. The scale cube Xaxis - horizontal duplication Sc Z ax is Scale by splitting different things ale - d by ata sp pa th litt rtit in in ion gs g sim ing ila r Y axis functional decomposition @crichardson
- 24. Y-axis scaling -application level WAR StoreFrontUI Product Info Service Recommendation Service Review Service Order Service @crichardson
- 25. Y-axis scaling -application level product info application Product Info Service recommendations application Store front application StoreFrontUI Recommendation Service reviews application Review Service orders application Order Service Apply X axis cloning and/or Z axis partitioning to each service @crichardson
- 26. Partitioning strategies... Partition bynoun, e.g. product info service Partition by verb, e.g. shipping service Single Responsibility Principle Unix utilities - do one focussed thing well @crichardson
- 27. Partitioning strategies Too few Drawbacksof 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 @crichardson
- 28. Inter-service communication options Synchronous HTTP asynchronousAMQP Formats: JSON, XML, Protocol Buffers, Thrift, ... Asynchronous is preferred but REST is popular too JSON is fashionable but binary format is more efficient @crichardson
- 29. Example micro-service class RegistrationSmsServletextends RegistrationSmsScalatraStack { } post("/") { val phoneNumber = request.getParameter("From") val registrationUrl = System.getenv("REGISTRATION_URL") + "?phoneNumber=" + encodeForUrl(phoneNumber) <Response> <Sms>To complete registration please go to {registrationUrl} </Sms> </Response> } For more on micro-services see http:/ /oredev.org/2012/sessions/microservice-architecture @crichardson
- 30.
- 31.
- 32. Complexity See Steve Yegge’sGoogle Platforms Rant re Amazon.com @crichardson
- 33.
- 34. Implementing features that spanmultiple services @crichardson
- 35. When to useit? In the beginning: •You don’t need it •It will slow you down Later on: •You need it •Refactoring is painful @crichardson
- 36. But there aremany benefits @crichardson
- 37. Smaller, simpler apps Easierto understand and develop Reduced startup time - important for GAE Less jar/classpath hell Who needs OSGI? @crichardson
- 38. Scales development: develop, deployand scale each service independently @crichardson
- 39.
- 40. Eliminates long-term commitment toa single technology stack Modular, polyglot, multiframework applications @crichardson
- 41. Two levels ofarchitecture 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 @crichardson
- 42. Easily try othertechnologies ... and fail safely @crichardson
- 43. The human bodyas a system @crichardson
- 44. 50 to 70billion of your cells die each day @crichardson
- 45. Yet you (thesystem) remain you @crichardson
- 46. Can we buildsoftware systems with these characteristics? http://dreamsongs.com/Files/ DesignBeyondHumanAbilitiesSimp.pdf http://dreamsongs.com/Files/WhitherSoftware.pdf @crichardson
- 47. Agenda The (sometimes evil)monolith Decomposing applications into services API gateway design Refactoring the monolith @crichardson
- 48. Directly connecting thefront-end to the backend Chatty API View REST Product Info service REST Recommendation Service AMQP Controller Review service Model Traditional web application View Controller Model Browser/Native App Web unfriendly protocols @crichardson
- 49. Use an APIgateway Single entry point View REST Product Info service REST Recommendation Service AMQP Controller Review service Model Traditional web application View API Gateway Controller Model Browser/Native App Client specific APIs Protocol translation @crichardson
- 50.
- 51. Netflix API Gateway Devicespecific end points http://techblog.netflix.com/2013/01/optimizing-netflix-api.html @crichardson
- 52. Developing an APIgateway Java EE web technologies Netty-based technology stack Non-Java options: e.g. Node.JS @crichardson
- 53. API gateway designissues @crichardson
- 54. The need forparallelism Product Info getProductDetails() get Product Details Product Details API getRecomendations() Recommendations Call in parallel getReviews() Reviews @crichardson
- 55. Futures are agreat concurrency abstraction An object that will contain the result of a concurrent computation http://en.wikipedia.org/wiki/Futures_and_promises Future<Integer> result = executorService.submit(new Callable<Integer>() {... }); Java has basic futures. We can do much better.... @crichardson
- 56. Better: Futures withcallbacks val f : Future[Int] = Future { ... } f onSuccess { case x : Int => println(x) } f onFailure { case e : Exception => println("exception thrown") } Guava ListenableFutures, Java 8 CompletableFuture, Scala Futures @crichardson
- 57. Even better: ComposableFutures val f1 = Future { val f2 = Future { ... ; 1 } ... ; 2 } Transforms Future val f4 = f2.map(_ * 2) assertEquals(4, Await.result(f4, 1 second)) Combines two futures val fzip = f1 zip f2 assertEquals((1, 2), Await.result(fzip, 1 second)) def asyncOp(x : Int) = Future { x * x} val f = Future.sequence((1 to 5).map { x => asyncOp(x) }) assertEquals(List(1, 4, 9, 16, 25), Await.result(f, 1 second)) Transforms list of futures to a future containing a list Scala Futures @crichardson
- 58. Composing concurrent requests usingScala Futures class ProductDetailsService @Autowired()(....) { def getProductDetails(productId: Long) = { val productInfoFuture = productInfoService.getProductInfo(productId) val recommendationsFuture = recommendationService.getRecommendations(productId) val reviewsFuture = reviewService.getReviews(productId) for (((productInfo, recommendations), reviews) <productInfoFuture zip recommendationsFuture zip reviewsFuture) yield ProductDetails(productInfo, recommendations, reviews) } } Asynchronously creates a Future containing result @crichardson
- 59. Handling partial failures ProductInfo getProductDetails() get Product Details Product Details Controller getRecomendations() getReviews() X Recommendations Reviews @crichardson
- 60. About Netflix > 1BAPI calls/day 1 API call average 6 service calls Fault tolerance is essential http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html @crichardson
- 61. How to runout of threads Thread 1 X HTTP Request Thread 2 X X Thread 3 API Gateway Code X Recommendation Service Thread n X Execute thread pool Tomcat Eventually all threads will be blocked If service is down then thread will be blocked @crichardson
- 62. Their approach Network timeouts Invokeremote services via a bounded thread pool Use the Circuit Breaker pattern On failure: return default/cached data return error to caller https://github.com/Netflix/Hystrix @crichardson
- 63. Agenda The (sometimes evil)monolith Decomposing applications into services API gateway design Refactoring the monolith @crichardson
- 64. How do youdecompose your big, scary monolithic application? @crichardson
- 65. Strategy #1: Stopdigging @crichardson
- 66. New functionality =service Pristine Monolith Anti-corruption layer Service Glue code @crichardson
- 67. Sounds simple but... Dependenciesbetween monolith and service e.g. Common entities Building the anti-corruption layer can be challenging Must replicate data between systems ... @crichardson
- 68. Strategy #2: Splitfront-end & backend @crichardson
- 69. Split front-end &backend Independently deployable Monolith Presentation layer Front-end Backend Backend @crichardson
- 70.
- 71.
- 72. Issues and challenges Server-sideSession state: Need to use a separate session state server ... @crichardson
- 73. Strategy #4: extractservices @crichardson
- 74.
- 75.
- 76. What to extract? Havethe ideal partitioned architecture in mind: Partitioned by verb or noun Start with troublesome modules: Frequently updated Stateful components that prevent clustering Conflicting resource requirements @crichardson
- 77. Untangling dependencies Monolith Service API A APIC API B Trouble! Domain model 1 X Domain model 2 C A Y B Z @crichardson
- 78. Useful idea: Boundedcontext 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 Services exchange messages to synchronize data @crichardson
- 79. Untangling orders andcustomers Customer Service Order Service availableCredit() updateCustomer() placeOrder() Order management Order Customer management belongs to has orders creditLimit ... total Invariant: sum(order.total) <= creditLimit Customer Trouble! available credit= creditLimit sum(order.total) @crichardson
- 80. Replicating the creditlimit Order Service sum(order.total) <= creditLimit placeOrder() Order management updateCustomer() Customer management Customer Order Simplified Customer Service creditLimit ... total CreditLimitChangedEvent Customer’ creditLimit @crichardson
- 81. Maintaining the openOrderTotal CustomerService Order Service placeOrder() = creditLimit - openOrderTotal Order management availableCredit() Customer management Customer Order creditLimit openOrderTotal ... customerId total OpenOrderTotalUpdated @crichardson
- 82. Refactoring a monolithis not easy BUT the alternative is far worse @crichardson
- 83.
- 84. Monolithic applications are simpleto develop and deploy BUT have significant drawbacks @crichardson
- 85. Apply the scalecube Modular, polyglot, and scalable applications Services developed, deployed and scaled independently @crichardson
- 86. Use a modular,polyglot architecture View REST Controller Product Info service REST Recommendation Service AMQP Review service Model Traditional web application View Controller API Gateway Model @crichardson
- 87.