GGX 2014 Lari Hotari Modular Monoliths with Spring Boot and Grails 3

Modular Monoliths
with Grails 3 and
Spring Boot
Lari Hotari, Pivotal Software Inc.
presentation recording:
http://goo.gl/LRlrQK
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››

Pivotal Analytics
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Agenda
• Modularity: Why? What?
• How to approach the design of Modular Monoliths with
Grails 3 and Spring Boot?
– current alternatives
– challenges and drawbacks
– future possibilities?
presentation recording:
http://goo.gl/LRlrQK

What's the right way?

Microservices?

Velocity is the Killer App
Unless otherwise indicated, these slides are © 2013-2014 Pivotal Software, Inc. and
licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/
licenses/by-nc/3.0/

Conceptual graph of cost of change & time-to-value
Cost & time-to-value
per additional
feature/change
connected
monolith is
cheaper in the
beginning
cost per change is
high, system
replacement requires
changes too
You can plan to switch
strategies!
Cumulated number of changes / features
source: Kent Beck's blog post: To Design or Not To Design? A Third Good Question
http://www.threeriversinstitute.org/blog/?p=338

Modularity
• logical partitioning of the software at design time
• separation of concerns
• allows complex software to be manageable for the
purpose of implementation and maintenance

The challenge with using microservices
architecture
In the beginning:
• You don't need it.
• It will slow you down.
Later on:
• You need it.
• Refactoring is painful.
“Because of these issues, adopting a microservice
architecture should not be undertaken lightly.”
Chris Richardson: Microservices: Decomposing Applications
for Deployability and Scalability
http://www.infoq.com/articles/microservices-intro

http://martinfowler.com/bliki/SacrificialArchitecture.html

What is the problem we
are trying to solve?

Maintainability, not just modularity
• modularity
• conceptual clarity and consistency
• easy to learn and understand from developer's point of
view
– it's very important that developers understand the story
that the elements of the system is telling (DDD blue
book)
• as developers, we want to feel safe in doing changes to
the system (safety net of tdd, etc.), easy to validate
changes

From Reuse to Replaceability
• earlier software reuse was one of the main goals
• large legacy systems are hard to replace.
– stop building large monoliths!

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
For a longer and better explanation, read Kent Beck's blog post
on Coupling and Cohesion
http://www.threeriversinstitute.org/blog/?p=104

Optimal Coupling and Cohesion within the Context
• Low coupling between modules ⟹ easier to change
• High cohesion within module ⟹ meaningful single
responsibility

Coupling related guidelines
• Elements that change of the same reason should be kept
together to minimise the ripple effects.
• Separate things that change at different rates.

Other types of coupling
• Be aware of behavioural or temporal coupling that is
hidden and hard to detect: no static analysis can detect
this type of coupling.
• Shared mutable state related coupling
• coupling via shared database
• transactions
• RPC
• Your system can be extremely "clean" and technically
loosely coupled (at design time), but this doesn't really
improve the situation in the end when there is tight
behavioural or temporal coupling at runtime.
=> ripple effects, high cost of change

Brooks: "No silver bullet"
• Essential complexity
– complexity that you cannot escape
• Accidental complexity
– we could be adding complexity by bad design

Modularity of commonly
used
Spring/Grails application
architectures
styles

Sources of excess coupling in large Grails/
Spring applications (applies to many others
too)
• There is a common misconception that shared layers are
good for modularity. Usually they aren't. "Vertical slices"
should be also used.
• see Oliver Gierke's presentation for better explanation
https://www.youtube.com/watch?v=tEm0USdF-70
• Accidental architecture. You should have a sound plan to
accomplish modularity and also enforce it. See Oliver's blog
post: http://olivergierke.de/2013/01/whoops-where-did-my-architecture-
go/
• Unnecessary coupling to implementation details in
interfaces
• DRY at extremes causes coupling which reduces flexibility.
• Tests cause coupling too since tests have to be maintained.

Grails plugins
• Grails plugins provide a way to decompose the application to
vertical slices at design time.

Spring modularity related options
• Spring Boot applications can be decomposed in separate
jar-modules as well. These "plugins" can be reused like
Grails plugins.
• Spring bean contexts (configured with java config or xml)
can be used to encapsulate groups of Spring beans to be
packaged and reused as libraries in several applications.
• UI resources can be referenced from web jars
• DI is providing a way to decouple implementation classes
from consumer classes. DI is also used to inject
configuration parameters in Spring applications.
• Spring Boot Auto-Configuration for activating "starter"
modules that are on the classpath. You can build your own
"starter"/auto-configuration modules too.

Grails 3 apps are Spring Boot apps
• Since Grails 3 will be based on Spring Boot, the features
of Spring Boot are useable in Grails 3 apps too.
• Grails 3 apps are Spring Boot apps with extended
functionality to bring the developer similar behaviour and
features as in previous Grails versions.
• Watch Graeme's keynote tomorrow for a demo and more
information about Grails 3.

Presentation
Services
Persistence

Account Search Order
Presentation
Services
Persistence

Stefan Tilkov's
Vertical Systems approach
a.k.a Self Contained Systems
Microservices approach Vertical Systems approach
• Very small
• 100s
• Does one thing only
• Separate client
• No shared DB
• Medium sized
• 10s
• Small # of related things
• Includes UI
• No shared DB
• You don't need any special frameworks or containers to implement the
Self Contained Systems approach today. You usually need SSO and a way
to make the UI consistent across the vertical slices. You don't need a
portal server to do this.
http://www.infoq.com/presentations/modular-ecommerce-website

Account
Presentation
Services
Persistence
Search Order
Presentation
Services
Persistence
Presentation
Services
Persistence

Gradually migrating to
microservices?

Hybrid style - Microservices and Self Contained
Systems strategy
Account
Presentation
Services
Persistence
Search
Presentation
Services
Persistence
Order
Presentation
Services
Persistence

Everything as a microservice
Unrealistic in most enterprise environments?

Microservices? More like client-server
μservice
A
Monolith is
now in the
browser
Single Page
App in
Browser
API
Gateway
service
SAAS
Service A
SAAS
Service B
μservice
B
μservice
C
μservice
D
μservice
E
μservice
F

Do you need true "micro services"?
• There might not even be a real requirement for going
from self contained systems to "true" microservices.
• You might want to keep the core parts of your business as
"self contained systems" and add more functionality
around these systems as smaller microservices.
• In many context, microservices architecture has started to
mean this style of architecture. That's why "micro" is not a
very meaningful term in this context.
• Applying Microservices is more about building "cloud-native"
12-factor applications that can be run on cloud
platforms (where servers are cattle and not pets).

Recommendations
• Big monolithic systems cause trouble - don't let any single
code base become too large.
• Split your system in modules and gradually migrate
from a monolith, to vertical slices, then to self contained
systems and/or microservices. Refine as you go.
• Split the database too. Don't share the database since it
usually leads to a monolith.
• Build "cloud native" systems and 12-factor apps.
Use Spring Cloud and Reactor that contains helpers for
this way of building applications. Functional reactive
programming with Reactive Streams is a way to handle
complexity and reduce coupling in certain use cases. It's
not only about scaling to masses.

• Learn Domain Driven Design and the Bounded Context.
• http://martinfowler.com/bliki/BoundedContext.html
http://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices/43

Strategic design
Not all of a large
system will be well
designed.
Some or none will
be.
-Eric Evans

Why is Domain Driven Design important?
Success developing useful models comes down to three
points.
1. Sophisticated domain models are achievable and worth
the trouble.
2. They are seldom developed except through an iterative
process of refactoring, including close involvement of the
domain experts with developers interested in learning
about the domain.
3. They may call for sophisticated design skills to implement
and to use effectively.
source: Eric Evans: Domain Driven Design
You can only achieve "bounded contexts" or "vertical slices" with proper design.
Microservices are really about building in this style.
See Kent Beck's blog article "To Design or Not To Design? A Third Good Question" from 2009,
http://www.threeriversinstitute.org/blog/?p=338 gives good insight.

As a software developer, choose your battles
and fight for what actually matters.
-Me just know
Write software that matters.
-Dan North
Q&A
@lhotari
lhotari@pivotal.io

GGX 2014 Lari Hotari Modular Monoliths with Spring Boot and Grails 3

More Related Content

What's hot (20)

Similar to GGX 2014 Lari Hotari Modular Monoliths with Spring Boot and Grails 3 (20)

More from Lari Hotari (7)

Recently uploaded (20)

GGX 2014 Lari Hotari Modular Monoliths with Spring Boot and Grails 3

Editor's Notes