Ratpack and Grails 3 (and Spring Boot) SpringOne 2GX 2014
Download as PPTX, PDF10 likes1,949 views
The document discusses Ratpack and Grails 3 frameworks for building asynchronous and modular applications. Ratpack and Grails 3 both use non-blocking architectures that are more efficient than traditional threading models. They also support building modular applications through loose coupling and high cohesion, enabling microservice architectures. The frameworks allow building monolithic or modular applications that can later be broken into independent microservices if needed.
Ratpack and Grails 3 (and Spring Boot) SpringOne 2GX 2014
- 1. Ratpack and Grails 3 by Lari Hotari @lhotari © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
- 2. Ratpack and Spring Boot by Lari Hotari @lhotari © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
- 3. Agenda • Grails 3 and Ratpack - Why • Why async? • Modularity and micro service architectures 3
- 4. Grails 3 • Build on Spring Boot • Embrace Gradle • Abstract packaging / deployment • Reach outside the servlet container • App profiles: Netty, Servlet, Batch, Hadoop • Deployment with runnable JARs • Support micro services, remove bloat, reduce dependencies 4
- 5. 5
- 6. 6
- 7. Why Netty / Ratpack? © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission. Why async?
- 8. What is application performance about? • Latency of operations • Throughput of operations • Quality of operations - efficiency, usability, responsiveness, correctness, consistency, integrity, reliability, availability, resilience, robustness, recoverability, security, safety, maintainability 8
- 10. Little's law L = λW MeanNumberInSystem = MeanThroughput * MeanResponseTime 10 → MeanThroughput = MeanNumberInSystem / MeanResponseTime
- 11. Cons of the thread-per-request model in the light of Little's law and Amdahl's law • From Little's law: MeanNumberInSystem = MeanThroughput * MeanResponseTime • In the thread-per-request model, the upper bound for MeanNumberInSystem is the maximum for the number of request handling threads. This might limit the throughput of the system, especially when the response time get higher or request handling threads get blocked and hang. • Shared locks and resources might set the upper bound to a very low value. Such problems get worse under error conditions. 11
- 12. Advantages of thread-per-request model • We are used to debugging the thread-per-request model - adding breakpoints, attaching the debugger and going through the stack • The synchronous blocking procedural programming model is something that programmers are used to doing. • There is friction in switching to different programming models and paradigms. 12
- 13. Declarative Programming model • Declarative programming expresses the logic of a computation without describing its control flow. • It's programming without the call stack, the programmer doesn't decide execution details. • Examples: functional and reactive programming, event / message based execution, distributed parallel computation algorithms like Map/Reduce 13
- 14. KillerApp for non-blocking async model • Responsive streaming of a high number of clients on a single box • continuously connected real-time apps where low-latency and high availablity is a requirement • limited resources (must be efficient/optimal) • Follow Pivotal's https://github.com/reactor/reactor project that provides a Reactive Streams (http://www.reactive-streams.org/) implementation 14
- 15. Hello world in Ratpack 15 1 import static ratpack.groovy.Groovy.ratpack 2 3 ratpack { 4 handlers { 5 get { 6 render "Hello world" 7 } 8 } 9 } https://github.com/lhotari/hello-ratpack/blob/master/src/ratpack/Ratpack.groovy
- 16. Ratpack applications • Ratpacks comes with Guice for dependency injection • Guice modules are also used as the plugin system for Ratpack • not actual "plugins" in a technical sense since there isn't a plugin API and the developer takes care of wiring modules to Ratpack applications. • Examples of Ratpack module contributions: • Integrations to RxJava and Reactor. Can be used for async composition and preventing "callback hell". • Integration to Netflix Hystrix for adding error resilience functionality . f.e., Circuit-breaker pattern impl. 16
- 17. Demo • https://github.com/lhotari/ratpack-gorm-example • Spring Boot embedded in Ratpack, running GORM • Uses Ratpack Spring Boot support (0.9.9-SNAPSHOT) • Grails 3 builds on Spring Boot 17
- 18. Modularity and Microservices © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
- 19. Modularity • logical partitioning of the "software design" • allows complex software to be manageable for the purpose of implementation and maintenance 19
- 20. Coupling and Cohesion • Coupling and cohesion are measures for describing how easy it will be to change the behaviour of some element in a system • Modules are coupled if a change in one forces a change in a the other • A module's cohesion is a measure of whether it's responsibilities form a meaningful unit source: GOOS book 20
- 21. Optimal coupling and cohesion • Low coupling between modules ⟹ easier to change • High cohesion within module ⟹ single responsibility 21
- 22. Microservice definition by James Lewis • Each application only does one thing • Small enough to fit in your head • Small enough that you can throw them away • Embedded web container • Packaged as a single executable jar • Use HTTP and HATEOAS to decouple services • Each app exposes metrics about itself 22
- 23. Polyglot persistence • Common principle is that each service owns it's data - there is no shared database across multiple services. • If this principle is followed, it usually means switching to Hexagonal architecture, where persistence is an integration and not part of the core. • "Start with the events and behaviour instead of the database." • Data consistency models in distributed systems 23
- 24. Brooks: "No silver bullet" • Essential complexity • complexity that you cannot escape • Accidental complexity • we could be adding complexity by bad design 24
- 25. Modular applications © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
- 26. Monoliths in systems-of-systems 26 μser vice A Single Page App in Browser API Gateway service SAAS Service A SAAS Service B μser vice B μser vice C μser vice D μser vice E μser vice F
- 27. Modular monoliths • Modular monoliths are composed of loosely coupled modules of single responsibility • Enabling the 3rd way (after monoliths and microservices) for building applications on the JVM across different libraries and frameworks • Modules can be turned into true micro services when needed - instead of introducing accidental complexity to projects that don't really require micro services in the beginning, but could benefit of them later 27
- 28. © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission. Questions?
- 29. Thanks! Lari Hotari @lhotari Pivotal Software, Inc. © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Editor's Notes
- #9: Performance == Fast , Latency Performance == Efficiency , Throughput Performance == Correctness , Quality