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.