Ratpack and Grails 3 (and Spring Boot) SpringOne 2GX 2014
-
Upload
lari-hotari -
Category
Software
-
view
464 -
download
3
description
Transcript of Ratpack and Grails 3 (and Spring Boot) SpringOne 2GX 2014
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Ratpack and Grails 3by Lari Hotari @lhotari
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Ratpack and Spring Bootby Lari Hotari @lhotari
Agenda
• Grails 3 and Ratpack - Why
• Why async?
• Modularity and micro service architectures
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
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Why Netty / Ratpack?Why async?
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
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
Amdahl's law
Little's law
MeanNumberInSystem = MeanThroughput * MeanResponseTime→
MeanThroughput = MeanNumberInSystem / MeanResponseTime
L = λW
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.
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.
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
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
Hello world in Ratpack
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
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.
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
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission. © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Modularity and Microservices
Modularity
• logical partitioning of the "software design"
• allows complex software to be manageable for the
purpose of implementation and maintenance
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
Optimal coupling and cohesion
• Low coupling between modules easier to change⟹
• High cohesion within module single responsibility⟹
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
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
Brooks: "No silver bullet"
• Essential complexity
• complexity that you cannot escape
• Accidental complexity
• we could be adding complexity by bad design
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission. © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Modular applications
Monoliths in systems-of-systems
µservice A
Single Page App in Browser
API Gatewayservice
SAAS Service A
SAAS Service B
µservice B
µservice C
µservice D
µservice E
µservice F
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
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Questions?
© 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Thanks!Lari Hotari @lhotari
Pivotal Software, Inc.