Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Modular Monoliths 
with Grails 3 and 
Spring Boot 
Lari Hotari, Pivotal Software Inc. 
presentation recording: 
http://goo...
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? 
– cur...
© 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 ...
Conceptual graph of cost of change & time-to-value 
Cost & time-to-value 
per additional 
feature/change 
connected 
monol...
Modularity 
• logical partitioning of the software at design time 
• separation of concerns 
• allows complex software to ...
The challenge with using microservices 
architecture 
In the beginning: 
• You don't need it. 
• It will slow you down. 
L...
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 f...
From Reuse to Replaceability 
• earlier software reuse was one of the main goals 
• large legacy systems are hard to repla...
Coupling and Cohesion 
• Coupling and cohesion are measures for describing how 
easy it will be to change the behaviour of...
Optimal Coupling and Cohesion within the Context 
• Low coupling between modules ⟹ easier to change 
• High cohesion withi...
Coupling related guidelines 
• Elements that change of the same reason should be kept 
together to minimise the ripple eff...
Other types of coupling 
• Be aware of behavioural or temporal coupling that is 
hidden and hard to detect: no static anal...
Brooks: "No silver bullet" 
• Essential complexity 
– complexity that you cannot escape 
• Accidental complexity 
– we cou...
Modularity of commonly 
used 
Spring/Grails application 
architectures 
styles 
© 2014 Pivotal Software, Inc. All rights r...
Sources of excess coupling in large Grails/ 
Spring applications (applies to many others 
too) 
• There is a common miscon...
Grails plugins 
• Grails plugins provide a way to decompose the application to 
vertical slices at design time. 
© 2014 Pi...
Spring modularity related options 
• Spring Boot applications can be decomposed in separate 
jar-modules as well. These "p...
Grails 3 apps are Spring Boot apps 
• Since Grails 3 will be based on Spring Boot, the features 
of Spring Boot are useabl...
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...
Account 
Presentation 
Services 
Persistence 
Search Order 
Presentation 
Services 
Persistence 
Presentation 
Services 
P...
Gradually migrating to 
microservices? 
© 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››
Hybrid style - Microservices and Self Contained 
Systems strategy 
Account 
Presentation 
Services 
Persistence 
Search 
P...
Everything as a microservice 
Unrealistic in most enterprise environments? 
© 2014 Pivotal Software, Inc. All rights reser...
Microservices? More like client-server 
μservice 
A 
Monolith is 
now in the 
browser 
Single Page 
App in 
Browser 
API 
...
Do you need true "micro services"? 
• There might not even be a real requirement for going 
from self contained systems to...
Recommendations 
• Big monolithic systems cause trouble - don't let any single 
code base become too large. 
• Split your ...
• Learn Domain Driven Design and the Bounded Context. 
• http://martinfowler.com/bliki/BoundedContext.html 
http://www.sli...
Strategic design 
Not all of a large 
system will be well 
designed. 
Some or none will 
be. 
-Eric Evans 
© 2014 Pivotal ...
Why is Domain Driven Design important? 
Success developing useful models comes down to three 
points. 
1. Sophisticated do...
As a software developer, choose your battles 
and fight for what actually matters. 
-Me just know 
Write software that mat...
Upcoming SlideShare
Loading in …5
×

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

2,415 views

Published on

Modular monoliths are composed of loosely coupled modules of single responsibility. Ideally these modules can be separated into true microservices when needed - instead of introducing accidental complexity and tradeoffs of distributed systems to projects in the beginning. In this presentation we will look in to the practicality of this approach with Grails 3 and Spring Boot.
recording: https://skillsmatter.com/legacy_profile/lari-hotari#skillscasts

Published in: Technology

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

  1. 1. 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. ‹‹#››
  2. 2. Pivotal Analytics © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  3. 3. 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. ‹#›
  4. 4. © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  5. 5. What's the right way? © 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››
  6. 6. Microservices? © 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››
  7. 7. 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/
  8. 8. 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. ‹#›
  9. 9. 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. ‹#›
  10. 10. 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. ‹#›
  11. 11. http://martinfowler.com/bliki/SacrificialArchitecture.html © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  12. 12. What is the problem we are trying to solve? © 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››
  13. 13. © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  14. 14. © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  15. 15. 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. ‹#›
  16. 16. 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. ‹#›
  17. 17. 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. ‹#›
  18. 18. 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. ‹#›
  19. 19. 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. ‹#›
  20. 20. 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. ‹#›
  21. 21. 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. ‹#›
  22. 22. Modularity of commonly used Spring/Grails application architectures styles © 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››
  23. 23. 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. ‹#›
  24. 24. Grails plugins • Grails plugins provide a way to decompose the application to vertical slices at design time. © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  25. 25. 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. ‹#›
  26. 26. 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. ‹#›
  27. 27. Presentation Services Persistence © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  28. 28. Account Search Order Presentation Services Persistence © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  29. 29. 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. ‹#›
  30. 30. Account Presentation Services Persistence Search Order Presentation Services Persistence Presentation Services Persistence © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  31. 31. Gradually migrating to microservices? © 2014 Pivotal Software, Inc. All rights reserved. ‹‹#››
  32. 32. 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. ‹#›
  33. 33. Everything as a microservice Unrealistic in most enterprise environments? © 2014 Pivotal Software, Inc. All rights reserved. ‹#›
  34. 34. 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. ‹#›
  35. 35. 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. ‹#›
  36. 36. 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. ‹#›
  37. 37. • 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
  38. 38. 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. ‹#›
  39. 39. 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. ‹#›
  40. 40. 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. ‹‹#››

×