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