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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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

What's the right way?
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››

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

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

http://martinfowler.com/bliki/SacrificialArchitecture.html
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

What is the problem we
are trying to solve?
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››

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

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

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

From Reuse to Replaceability
• earlier software reuse was one of the main goals
• large legacy systems are hard to replace.
– stop building large monoliths!
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Optimal Coupling and Cohesion within the Context
• Low coupling between modules ⟹ easier to change
• High cohesion within module ⟹ meaningful single
responsibility
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Brooks: "No silver bullet"
• Essential complexity
– complexity that you cannot escape
• Accidental complexity
– we could be adding complexity by bad design
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Modularity of commonly
used
Spring/Grails application
architectures
styles
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››

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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Grails plugins
• Grails plugins provide a way to decompose the application to
vertical slices at design time.
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Presentation
Services
Persistence
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Account Search Order
Presentation
Services
Persistence
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Account
Presentation
Services
Persistence
Search Order
Presentation
Services
Persistence
Presentation
Services
Persistence
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Gradually migrating to
microservices?
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››

Hybrid style - Microservices and Self Contained
Systems strategy
Account
Presentation
Services
Persistence
Search
Presentation
Services
Persistence
Order
Presentation
Services
Persistence
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

Everything as a microservice
Unrealistic in most enterprise environments?
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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).
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

• 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
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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.
© 2014 Pivotal Software, Inc. All rights reserved. ‹#›

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
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››