One of the goals of Grails 3 is to reach out of the servlet container. Grails 3 has a concept of application profiles for choosing a certain set of core plugins to use. In this talk Lari will present how Ratpack fits in Grails 3. He will also talk about how Grails 3 supports micro service architectures.
7. Little's law
• What does Little's law tell us when we are using
the thread-per-request model?
MeanNumberInSystem = MeanThroughput * MeanResponseTime
→
MeanThroughput = MeanNumberInSystem / MeanResponseTime
L = λW
8. 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
10. Ratpack applications
• Ratpacks comes with Guice for dependency injection
• Guice modules are also used as the plugin system for
Ratpack
• 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.
11. Demo
Ratpack and Grails (GORM) used together
• https://github.com/lhotari/ratpack-gorm-example
• Spring Boot embedded in Ratpack, running
GORM
12.
13. Modularity
• logical partitioning of the "software design"
• allows complex software to be manageable for
the purpose of implementation and maintenance
14. 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
15. • Low coupling between modules ⟹ easier to
change
• High cohesion within module ⟹ single
responsibility
16. 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
17. –Arnon Rotem-Gal-Oz, Practical SOA
“Nanoservice is an Anti-pattern where a
service is too fine grained. Nanoservice is a
service whose overhead (communications,
maintenance etc.) out-weights its utility.”
18. 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
19. Brooks: "No silver
bullet"
• Essential complexity
• complexity that you cannot escape
• Accidental complexity
• we could be adding complexity by bad design
20. - Google's "Solve for X"
“You don't spend your time
being bothered that you can't
teleport from here to Japan,
because there's a part of you
that thinks it's impossible.
Moonshot thinking is choosing
to be bothered by that.”
21. 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
22. The monoliths in the micro
services architecture
Single Page
App in
Browser
API Gateway
service
µservic
e A
SAAS
Service A
SAAS
Service B
µservic
e B
µservic
e C
µservic
e D
µservic
e E
µservic
e F