ggx 2014 lari hotari modular monoliths with spring boot and grails 3

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

Modular Monoliths with Grails 3 and Spring BootLari Hotari, Pivotal Software Inc.

presentation recording:

http://goo.gl/LRlrQK


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

Pivotal Analytics


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:




What's the right way?


Microservices?

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

Velocity is the Killer App


Conceptual graph of cost of change & time-to-value

connected monolith is cheaper in the beginning

cost per change is high, system replacement requires changes too

Cumulated number of changes / features

http://www.threeriversinstitute.org/blog/?p=338

Cost & time-to-value per additional feature/change

You can plan to switch strategies!

source: Kent Beck's blog post: To Design or Not To Design? A Third Good Question



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

http://www.infoq.com/articles/microservices-intro

Chris Richardson: Microservices: Decomposing Applications for Deployability and Scalability

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.”

http://www.infoq.com/articles/microservices-intro


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

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.

https://www.youtube.com/watch?v=tEm0USdF-70

http://olivergierke.de/2013/01/whoops-where-did-my-architecture-go/


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


Presentation

Services

Persistence

Account Search Order


Stefan Tilkov's Vertical Systems approach a.k.a Self Contained Systems

• Very small • 100s • Does one thing only • Separate client • No shared DB

• Medium sized • 10s • Small # of related things • Includes UI • No shared DB

Microservices approach Vertical Systems approach

http://www.infoq.com/presentations/modular-ecommerce-website

• 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

Single Page App in

Browser

API Gateway service

SAAS Service A

SAAS Service B

µservice B

µservice C

µservice D

µservice E

µservice F

Monolith is now in the browser


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

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


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.



@lhotari

Q&A As a software developer, choose your battles and fight for what actually matters. -Me just know

Write software that matters. -Dan North

[email protected]

ggx 2014 lari hotari modular monoliths with spring boot and grails 3

Technology

pivotal software

complex software

pivotal analytics

cost time

design of modular monoliths

change time

beginning cost

large monoliths