SlideShare a Scribd company logo
1 of 53
Download to read offline
Git: h'ps://github.com/victorrentea/spring-modulith.git
Branch: devoxx-uk-24
Slides: TODO
👋 I'm Victor Rentea 🇷🇴 Java Champion, PhD(CS)
18 years of coding
10 years of training & consul2ng at 130+ companies on:
❤ Refactoring, Architecture, Unit Tes4ng
🛠 Java: Spring, Hibernate, Performance, ReacIve
Lead of European So8ware Cra8ers (7K developers)
Join for free monthly online meeIngs from 1700 CET
Channel: YouTube.com/vrentea
Life += 👰 + 👧 + 🙇 + 🐈 @victorrentea
https://victorrentea.ro
🇷🇴
past events
3 VictorRentea.ro
🙋🙋
Legacy Monolith?
Microservices?
Java?
Spring?
ArchUnit?
4 VictorRentea.ro
What's faster to build from scratch?
One Monolith or 3 Microservices
... to release in 6-12 months?
5 VictorRentea.ro
What's faster to build from scratch?
One Monolith or 3 Microservices
... to release in 6-12 months?
6 VictorRentea.ro
Big Ball of Mud
(BBoM Pattern)
= a sprawling, sloppy,
duct-tape,
spaghetti-code jungle,
showing signs of unregulated growth,
and repeated expedient repair.
In desperate need of refactoring, but lacking tests.
https://wiki.c2.com/?BigBallOfMud
7 VictorRentea.ro
☢ nano-services
Velocity
⏩
FAST
🐌
SLOW
Microservices
Autonomy of microservices
outweighs their overhead
Development Velocity
☢ BBoM
Monolith My system will be complex,
so, let's start with microservices!
(Next-Ne)lix Syndrome)
Project Age
Early Late
produc3vity drops due to
high complexity & coupling
1-2 years or ≥ 7 dev
8 VictorRentea.ro
You should NOT start a new project with microservices,
even if you're sure your application will be big enough
to make it worthwhile. - Martin Fowler
principal microservice evangelist
h5ps://mar3nfowler.com/bliki/MonolithFirst.html (2015)
Instead: start simple (KISS) and
address the system's natural bottlenecks as they occur
( bugs, delays, dev pain )
😔 😔 😔
Meanwhile: "If we don't start with microservices, THEY (the bosses) won't
give us the .me we need to break it into microservices later" = WASTE
9 VictorRentea.ro
Architecture is
the art of deferring decisions
10 VictorRentea.ro
Pain-Driven Architecture
Protect core logic vs ugly API call with an Adapter
Split Complexity by Layers of Abstraction (ie. Facade)
Isolate Persistence if Shared/Legacy storage
Grow a Rich Model in Complex Domains
Refactor to Modulith when team grows
Use Events for cleaner 1:N Decoupling
Go to Microservices to meet NFRs
11 VictorRentea.ro
Monolith to Microservices
12 VictorRentea.ro
1) Big-Bang Rewrite of a 12y-old, 3M LOC codebase
- Re-gather all requirements and start from scratch
- Any changes to the old system you (a) reject, (b) delay, or (b) cost x2 (old+new)
- 20-30% success rate & likely to turn into a Distributed Monolith
2) Strangler-Fig Pa4ern (outside-in) ✅
- Rewrite decoupled parts as microservices behind a proxy protecIng clients
3) Refactor to Modules > Extract (inside-out) ✅
- Progressively decouple logic and data in the monolithic codebase
From a BBoM to Microservices
13 VictorRentea.ro
Refactor to Modules
Modulith
Can prove the best
in some domains
Velocity
⏩
FAST
🐌
SLOW
Microservices
Development Velocity
Monolith
Project Age
Early Late
Easy to extract
a microservice
14 VictorRentea.ro
Can we have the best of both?
Deployment architecture of a Monolith
Logical decoupling of Microservices
+ Easy to extract a Microservice
15 VictorRentea.ro
Modul ith
ar Monol
16 VictorRentea.ro
Modulith
17 VictorRentea.ro
Big Ball of Mud Microservices
XXL Database
eShop
Application
Catalog
Microservice
Catalog DB
Orders
Microservice
Orders DB
REST REST/MQ
Payment
Microservice
Payment DB
18 VictorRentea.ro
Modulith
ApplicaIon
Catalog
Module
Orders
Module
Payment
Module
Database
19 VictorRentea.ro
Goal of Modulith
independent teams managing decoupled modules
Example #1 (e-health)
each team {4-5 DEV+FE+PO+QA} owns ~4 modules
x 8 teams
+ 2 x FuncIonal Architects
+ 3 x Core Pladorm Team
total = 60 people
CI build ≤ 15 minutes (tuned)
1 prod deploy /week on 10 instances
Example #2 (pharmacy): 30 people
Example #3 (loan approval): 24 people
20 VictorRentea.ro
How to start?
21 VictorRentea.ro
Modulith
Code Decoupling
VictorRentea.ro
com.foo.bar.
controller
service
entity
repository
Code Par))oning
top-level packages per...
VictorRentea.ro
* h$ps://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
Technical
layer/ring
Func)onal
sub-domain*
com.foo.bar.
catalog
inventory
order
payment
Code Partitioning
top-level packages per...
controller
service
entity
repository
com.foo.bar.
controller
service
entity
repository
24 VictorRentea.ro
= a stand-alone logical applicaEon, having its own:
§business features (user value)
§private implementaIon: domain model + logic
§public API:
- internal, for other modules: via method calls or events
- external, for other systems: via REST, Rabbit, KaOa...
§private tables in database
§micro-frontend: screens & shared components (monorepo)
What is a Module?
25 VictorRentea.ro
Internal API
for other modules
External API
for other systems
MQ
RPC
implementa4on
not accessible
by other modules
Events
publish
<< plugin >>
B
listen
Methods
Interface
26 VictorRentea.ro
§Publisher should NOT expect any effect ⚠
§Publisher is unaware of listeners (poten;ally mul;ple) J
§The order of listeners should not ma>er. If it does: chain a new event ⚠
§Events can carry state to avoid a call back to publisher 🤔
§All listeners run sequen1ally in the publisher's thread and transac;on (if any)
§Listeners can be @Async
§Events can be persisted if sent over KaJa/Rabbit..
- Spring-modulith @Applica3onModuleListener persist events in DB un3l processed
⚠ Events are harder to navigate than method calls è use only between modules
Events 101
Eventual Consistency
27 VictorRentea.ro
28 VictorRentea.ro
↙ Generated by spring-modulith
h5ps://github.com/victorrentea/spring-modulith
29 VictorRentea.ro
§ArchUnit @Test www.archunit.org + ported to most languages
§Spring Modulith @Test spring.io/projects/spring-modulith
§Build Modules (Maven/Gradle)
Enforce Code Boundaries
@Test !// unit test running on CI
public void encapsulatedModules() {
var classes = new ClassFileImporter().importPackages("com.myapp");
var sliceRule = slices().matching("!..myapp.(*)!..*")
.should().notDependOnEachOther()
.ignoreDependency(resideInAnyPackage("!..shared!..", "!..api!.."));
sliceRule.check(classes); !// #1 fail on any deviation
List<String> violations = sliceRule.evaluate(classes)!!...;
assertThat(violations).hasSizeLessThan(33); !// #2 fitness function
}
@Test
void verifyModularity() { !// uses ArchUnit rules under the hood
ApplicationModules.of(ModulithApp.class).verify();
}
30 VictorRentea.ro
⚠ Only a'er boundaries are clear AND the team is about to split
✅ Stronger separa2on
- Impossible to add excep:ons/@Disable to the ArchUnit @Tests 😏
- Impossible to have cycles è
- BeAer IDE sugges:ons (eg: imagine 2 classes named 'Product' in different modules)
✅ Selec2ve dependencies
- A module can decide to use jasperreports, use reactor, or refuse lombok
- ⚠ All modules share the SAME library VERSIONS in the final binary
✅ Par2al release
- Client customiza:ons: invoicing-nhs.jar
- Purchased features: payment-exports.jar
From Packages to Build Modules
(Maven/Gradle)
31 VictorRentea.ro
Cyclic Dependencies
« module »
A
« module »
B
= Tight Coupling (they oEen change together)
⚠ Build fails if modules are separate build units (eg maven/gradle)
use
use
32 VictorRentea.ro
?
?
A B
O
orchestrator
"facade"
Pull OrchestraIon Up
?
?
?
?
Allow the call cycle,
just fix the code cycle
shared
A-impl B-impl
A-api B-api
Extract API out
run5me calls
keep a coarse-grained API,
for a monolithic client/site
Strategical Dependencies between Modules
microservices: shared lib
microservices: events on queue
microservices: interdependent microservices + client.jar
microservices: api gateway/bff/saga microservices: shared lib/3rd service microservices: merge or break
❤
AB
Merge Modules
Tight Coupling
(eg dozens of links)
Dependency Inversion
B allows A to implement logic,
without depending on A
A B
ç event
call
Publish Events (in-mem)
⭐Decoupled
A B
S
Push Shared Down
A B
(code dep) implements è
call
Dependency Inversion
⭐Decoupled
AProviderImpl
runtime call
«interface»
AProvider
Module A must react to changes in B
"shared"
Module:
- StringUQls
- Logging/Audit
- Country list
Wrong boundaries.
Try others? 🤔
33 VictorRentea.ro
The 'Shared' Module
§If large => BBoM ☢
- Possible starIng point coming from BBoM
§Extract business logic
§Extract complex concerns: common-security, common-kaOa..
§Contain internal API of all modules: api.catalog|.inventory 🤔
- ✅ Pros: simple fix to cyclic dependencies
- ⚠ Cons: risk of coupling internal APIs (write an ArchUnit rule)
§Contain staEc reference data: Country, Region, DiagnosEc...
- Be'er than dozens of nano-modules
34 VictorRentea.ro
* the same applies for "Microservice"
Smaller! Nano!
Post-BBoM PTSD ?
How small should modules be?
or microservices
35 VictorRentea.ro
The Fallacy of Nano-Services
The microservices honeymoon is over.
Uber is refactoring thousands of microservices into a more manageable solution;
Kelsey Hightower is predicting monoliths are the future;
Sam Newman is declaring that microservices should never be the default choice,
but rather a last resort.
Monolith can be cheaper (Amazon) and faster (StackOverflow.com)
https://vladikk.com/2020/04/09/untangling-microservices/
Smaller pieces
=> more coupling
36 VictorRentea.ro
order product
fulfillment
place order
cancel order
return
catalog
search
filter
display
compare
stock
inventory
stock
warehouse
supply-chain
hEps://www.michaelnygard.com/blog/2018/01/services-by-lifecycle/
Scales
Be'er
Split by
Data Concept
(aka En*ty Service)
Bu$in€ss Capability / User Value
(aka Feature Service)
37 VictorRentea.ro
Modulith
Data Decoupling
38 VictorRentea.ro
Modules should not
share tables
Allows to keep in sync:
Problem Domain ó Domain Model ó DB
or Microservices
VictorRentea.ro
inventory
catalog
Split Domain Models
class InventoryItem {
Product product;
Long productId;
String productName;
...
}
class Product {
id
name
...
}
40 VictorRentea.ro
Data Decoupling Levels
1. No IsolaGon (BBoM): everyone freely reads/writes any table
⚠ Data CorrupIon: a module could write valid data in a table, but later read bad data.
2. Write IsolaGon: one module writes into a table, but any other can read
🧠 Might require spliong a table (in separate schemas)
INVENTORY.ITEMS vs CATALOG.PRODUCTS, CATALOG.PRODUCT_ATTRIBUTES
⚠ Frozen Table Structure: an ALTER TABLE can break the readers
3. Exclusive Access🤩💖: modules have private schemas
😏 Trick: except read-only VIEWS exposed for others to JOIN : INVENTORY.V_STOCK(id, items)
4. Consistency per Module - tables of two modules:
(a) do NOT share any Foreign Key, and
(b) are NOT updated in the same Transac4on
Defer unIl microservice
extrac4on is imminent
Strong Consistency
Eventual Consistency
41 VictorRentea.ro
(vs a tradiJonal Monolith)?
1. Complexity EncapsulaIon behind clear Module APIs
- Autonomy & Less cogniJve load per module
2. Smaller Domain Model gets specialized, thus more useful
- catalog.Product vs inventory.InventoryItem
3. Module owns its Persistence
- Easy to keep tables in sync with evolving Domain Model
What makes a Modulith maintainable
42 VictorRentea.ro
Modulith Challenges
Finding Boundaries 🔄
EncapsulaEng Code
Decoupling Data
Speed of Build & Test
OperaEon
45 VictorRentea.ro
§End-to-end tests are slow and fragile
- Prefer Module-scoped tests ✅ over fragile unit-tests ❌
§"Always ready to ship" using Feature Flags
- ⚠ Constantly remove unneeded flags
§Parallel Build 😎
§A Monorepo can build mulEple arEfacts:
- Modulith + Frontend + 2 Microservices 🤔
Unified Build
46 VictorRentea.ro
§Shared TransacIons
- An excepIon in a module you call/noIfy can roll back your transacIon
§Resource starvaIon
- Modules share thread/DB connec4on pool è Monitoring ⚠
§Deadlocks
- In-process or out- (DB, Redis)
§Single instance of DI container
- Global seongs, rogue aspects, bean name collision
§Unified OpenAPI
- Single version? Type name collisions?
DifficulFes of "Running Together"
47 VictorRentea.ro
Next Step?
Microservices!🦄
48 VictorRentea.ro
Benefits of Microservices
49 VictorRentea.ro
They are cool
😎
Benefits of Microservices
50 VictorRentea.ro
Benefits of Microservices
ü Faster Time-to-Market => 😁 Business
if independently deployable by autonomous teams
ü Lower CogniGve Load => 😁 Developers
if small & aligned with business
ü Scalability for the hot🔥 parts that require it
ü Availability: fault-tolerance to parBal failures
ü Technology Freedom vs language/library version
ü Security / Privacy (GDPR) / Compliance
Modulith also
provides these
51 VictorRentea.ro
Drawbacks of Microservices
§Complex to Develop & Deploy
§Network Latency & Reliability
§Asynchronous CommunicaGon (messages/events)
§Eventual Consistency
§Hard to Monitor, Trace & Debug
$M1 premium
52 VictorRentea.ro
§Separate persistence
- No cross-schema SELECT. 🤔 Think...
- Drop all Foreign Keys to ó from other modules' schemas 🤔
- Stop sharing transac4ons with other modules 🤔
§Separate threads
- Turn method calls into REST localhost:8080 calls 🤔 (+propagate TraceId!)
- Events: @Async, @ApplicaIonModuleListener, or via Rabbit, Kawa 🤔
§Separate build & deploy 🎉
- Extract module X internal API as a standalone library (x-api.jar)
- Then separate Git repo 🤔
Steps to Extract a Module as a Microservice
POSTPONE
UNTIL
EXTRACTING A
MICROSERVICE
IS PLANNED IN
NEAR-FUTURE
if a step makes
business panic
STOP
undo, and rethink
extracQon
54 VictorRentea.ro
§The safest & cheapest way to split a Monolith
- To experiment with boundaries & gradually enforce them
§A valid alternaEve to Microservices
- For complex domains with decent NFRs
Modular Monolith
is
55 VictorRentea.ro
Are you sure you need
Microservices?
Think again!
I was Victor Rentea,
trainer & coach for experienced teams.
Git: h'ps://github.com/victorrentea/spring-modulith.git
Branch: devoxx-uk-24
Meet me online at:

More Related Content

Similar to Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024

Vertical Slicing Architectures
Vertical Slicing ArchitecturesVertical Slicing Architectures
Vertical Slicing Architectures
Victor Rentea
 

Similar to Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024 (20)

Red Hat and kubernetes: awesome stuff coming your way
Red Hat and kubernetes:  awesome stuff coming your wayRed Hat and kubernetes:  awesome stuff coming your way
Red Hat and kubernetes: awesome stuff coming your way
 
How OpenShift SDN helps to automate
How OpenShift SDN helps to automateHow OpenShift SDN helps to automate
How OpenShift SDN helps to automate
 
Tungsten Fabric Overview
Tungsten Fabric OverviewTungsten Fabric Overview
Tungsten Fabric Overview
 
Migration Effort in the Cloud - The Case of Cloud Platforms
Migration Effort in the Cloud - The Case of Cloud PlatformsMigration Effort in the Cloud - The Case of Cloud Platforms
Migration Effort in the Cloud - The Case of Cloud Platforms
 
Dipping Your Toes Into Cloud Native Application Development
Dipping Your Toes Into Cloud Native Application DevelopmentDipping Your Toes Into Cloud Native Application Development
Dipping Your Toes Into Cloud Native Application Development
 
MicroProfile, Docker, Kubernetes, Istio and Open Shift lab @dev nexus
MicroProfile, Docker, Kubernetes, Istio and Open Shift lab @dev nexusMicroProfile, Docker, Kubernetes, Istio and Open Shift lab @dev nexus
MicroProfile, Docker, Kubernetes, Istio and Open Shift lab @dev nexus
 
DCVCS using GIT
DCVCS using GITDCVCS using GIT
DCVCS using GIT
 
Vertical Slicing Architectures
Vertical Slicing ArchitecturesVertical Slicing Architectures
Vertical Slicing Architectures
 
Reactive Microservices with Spring 5: WebFlux
Reactive Microservices with Spring 5: WebFlux Reactive Microservices with Spring 5: WebFlux
Reactive Microservices with Spring 5: WebFlux
 
Intro to GitOps with Weave GitOps, Flagger and Linkerd
Intro to GitOps with Weave GitOps, Flagger and LinkerdIntro to GitOps with Weave GitOps, Flagger and Linkerd
Intro to GitOps with Weave GitOps, Flagger and Linkerd
 
Microservices Application Tracing Standards and Simulators - Adrians at OSCON
Microservices Application Tracing Standards and Simulators - Adrians at OSCONMicroservices Application Tracing Standards and Simulators - Adrians at OSCON
Microservices Application Tracing Standards and Simulators - Adrians at OSCON
 
Cloud nativemicroservices jax-london2020
Cloud nativemicroservices   jax-london2020Cloud nativemicroservices   jax-london2020
Cloud nativemicroservices jax-london2020
 
Cloud nativemicroservices jax-london2020
Cloud nativemicroservices   jax-london2020Cloud nativemicroservices   jax-london2020
Cloud nativemicroservices jax-london2020
 
Building APIs with Mule and Spring Boot
Building APIs with Mule and Spring BootBuilding APIs with Mule and Spring Boot
Building APIs with Mule and Spring Boot
 
Monitoring in Big Data Platform - Albert Lewandowski, GetInData
Monitoring in Big Data Platform - Albert Lewandowski, GetInDataMonitoring in Big Data Platform - Albert Lewandowski, GetInData
Monitoring in Big Data Platform - Albert Lewandowski, GetInData
 
Putting microservices on a diet with istio
Putting microservices on a diet with istioPutting microservices on a diet with istio
Putting microservices on a diet with istio
 
Microservices development at scale
Microservices development at scaleMicroservices development at scale
Microservices development at scale
 
Micro Front-End & Microservices - Plansoft
Micro Front-End & Microservices - PlansoftMicro Front-End & Microservices - Plansoft
Micro Front-End & Microservices - Plansoft
 
The rise of microservices - containers and orchestration
The rise of microservices - containers and orchestrationThe rise of microservices - containers and orchestration
The rise of microservices - containers and orchestration
 
Red hat forum istio & kiali - introduction and overview
Red hat forum   istio & kiali - introduction and overviewRed hat forum   istio & kiali - introduction and overview
Red hat forum istio & kiali - introduction and overview
 

More from Victor Rentea

Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Victor Rentea
 

More from Victor Rentea (20)

Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
 
Microservice Resilience Patterns @VoxxedCern'24
Microservice Resilience Patterns @VoxxedCern'24Microservice Resilience Patterns @VoxxedCern'24
Microservice Resilience Patterns @VoxxedCern'24
 
Distributed Consistency.pdf
Distributed Consistency.pdfDistributed Consistency.pdf
Distributed Consistency.pdf
 
Clean Code @Voxxed Days Cluj 2023 - opening Keynote
Clean Code @Voxxed Days Cluj 2023 - opening KeynoteClean Code @Voxxed Days Cluj 2023 - opening Keynote
Clean Code @Voxxed Days Cluj 2023 - opening Keynote
 
Testing Microservices @DevoxxBE 23.pdf
Testing Microservices @DevoxxBE 23.pdfTesting Microservices @DevoxxBE 23.pdf
Testing Microservices @DevoxxBE 23.pdf
 
From Web to Flux @DevoxxBE 2023.pptx
From Web to Flux @DevoxxBE 2023.pptxFrom Web to Flux @DevoxxBE 2023.pptx
From Web to Flux @DevoxxBE 2023.pptx
 
Test-Driven Design Insights@DevoxxBE 2023.pptx
Test-Driven Design Insights@DevoxxBE 2023.pptxTest-Driven Design Insights@DevoxxBE 2023.pptx
Test-Driven Design Insights@DevoxxBE 2023.pptx
 
OAuth in the Wild
OAuth in the WildOAuth in the Wild
OAuth in the Wild
 
The tests are trying to tell you something@VoxxedBucharest.pptx
The tests are trying to tell you something@VoxxedBucharest.pptxThe tests are trying to tell you something@VoxxedBucharest.pptx
The tests are trying to tell you something@VoxxedBucharest.pptx
 
Software Craftsmanship @Code Camp Festival 2022.pdf
Software Craftsmanship @Code Camp Festival 2022.pdfSoftware Craftsmanship @Code Camp Festival 2022.pdf
Software Craftsmanship @Code Camp Festival 2022.pdf
 
Unit testing - 9 design hints
Unit testing - 9 design hintsUnit testing - 9 design hints
Unit testing - 9 design hints
 
Clean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflixClean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflix
 
Extreme Professionalism - Software Craftsmanship
Extreme Professionalism - Software CraftsmanshipExtreme Professionalism - Software Craftsmanship
Extreme Professionalism - Software Craftsmanship
 
Clean architecture - Protecting the Domain
Clean architecture - Protecting the DomainClean architecture - Protecting the Domain
Clean architecture - Protecting the Domain
 
Refactoring blockers and code smells @jNation 2021
Refactoring   blockers and code smells @jNation 2021Refactoring   blockers and code smells @jNation 2021
Refactoring blockers and code smells @jNation 2021
 
Hibernate and Spring - Unleash the Magic
Hibernate and Spring - Unleash the MagicHibernate and Spring - Unleash the Magic
Hibernate and Spring - Unleash the Magic
 
Integration testing with spring @JAX Mainz
Integration testing with spring @JAX MainzIntegration testing with spring @JAX Mainz
Integration testing with spring @JAX Mainz
 
The Proxy Fairy and the Magic of Spring @JAX Mainz 2021
The Proxy Fairy and the Magic of Spring @JAX Mainz 2021The Proxy Fairy and the Magic of Spring @JAX Mainz 2021
The Proxy Fairy and the Magic of Spring @JAX Mainz 2021
 
Integration testing with spring @snow one
Integration testing with spring @snow oneIntegration testing with spring @snow one
Integration testing with spring @snow one
 
Pure functions and immutable objects @dev nexus 2021
Pure functions and immutable objects @dev nexus 2021Pure functions and immutable objects @dev nexus 2021
Pure functions and immutable objects @dev nexus 2021
 

Recently uploaded

Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Peter Udo Diehl
 

Recently uploaded (20)

Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfSimplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
 
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptxUnpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx
 
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
TEST BANK For, Information Technology Project Management 9th Edition Kathy Sc...
 
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptxWSO2CONMay2024OpenSourceConferenceDebrief.pptx
WSO2CONMay2024OpenSourceConferenceDebrief.pptx
 
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo DiehlFuture Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
Future Visions: Predictions to Guide and Time Tech Innovation, Peter Udo Diehl
 
What's New in Teams Calling, Meetings and Devices April 2024
What's New in Teams Calling, Meetings and Devices April 2024What's New in Teams Calling, Meetings and Devices April 2024
What's New in Teams Calling, Meetings and Devices April 2024
 
Intro in Product Management - Коротко про професію продакт менеджера
Intro in Product Management - Коротко про професію продакт менеджераIntro in Product Management - Коротко про професію продакт менеджера
Intro in Product Management - Коротко про професію продакт менеджера
 
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
Integrating Telephony Systems with Salesforce: Insights and Considerations, B...
 
Easier, Faster, and More Powerful – Notes Document Properties Reimagined
Easier, Faster, and More Powerful – Notes Document Properties ReimaginedEasier, Faster, and More Powerful – Notes Document Properties Reimagined
Easier, Faster, and More Powerful – Notes Document Properties Reimagined
 
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
 
AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101AI presentation and introduction - Retrieval Augmented Generation RAG 101
AI presentation and introduction - Retrieval Augmented Generation RAG 101
 
Demystifying gRPC in .Net by John Staveley
Demystifying gRPC in .Net by John StaveleyDemystifying gRPC in .Net by John Staveley
Demystifying gRPC in .Net by John Staveley
 
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
Measures in SQL (a talk at SF Distributed Systems meetup, 2024-05-22)
 
Oauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftOauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoft
 
Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024
 
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
 
1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT
1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT
1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT
 
Where to Learn More About FDO _ Richard at FIDO Alliance.pdf
Where to Learn More About FDO _ Richard at FIDO Alliance.pdfWhere to Learn More About FDO _ Richard at FIDO Alliance.pdf
Where to Learn More About FDO _ Richard at FIDO Alliance.pdf
 
Speed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in MinutesSpeed Wins: From Kafka to APIs in Minutes
Speed Wins: From Kafka to APIs in Minutes
 
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdfHow Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
 

Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024

  • 2. 👋 I'm Victor Rentea 🇷🇴 Java Champion, PhD(CS) 18 years of coding 10 years of training & consul2ng at 130+ companies on: ❤ Refactoring, Architecture, Unit Tes4ng 🛠 Java: Spring, Hibernate, Performance, ReacIve Lead of European So8ware Cra8ers (7K developers) Join for free monthly online meeIngs from 1700 CET Channel: YouTube.com/vrentea Life += 👰 + 👧 + 🙇 + 🐈 @victorrentea https://victorrentea.ro 🇷🇴 past events
  • 4. 4 VictorRentea.ro What's faster to build from scratch? One Monolith or 3 Microservices ... to release in 6-12 months?
  • 5. 5 VictorRentea.ro What's faster to build from scratch? One Monolith or 3 Microservices ... to release in 6-12 months?
  • 6. 6 VictorRentea.ro Big Ball of Mud (BBoM Pattern) = a sprawling, sloppy, duct-tape, spaghetti-code jungle, showing signs of unregulated growth, and repeated expedient repair. In desperate need of refactoring, but lacking tests. https://wiki.c2.com/?BigBallOfMud
  • 7. 7 VictorRentea.ro ☢ nano-services Velocity ⏩ FAST 🐌 SLOW Microservices Autonomy of microservices outweighs their overhead Development Velocity ☢ BBoM Monolith My system will be complex, so, let's start with microservices! (Next-Ne)lix Syndrome) Project Age Early Late produc3vity drops due to high complexity & coupling 1-2 years or ≥ 7 dev
  • 8. 8 VictorRentea.ro You should NOT start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. - Martin Fowler principal microservice evangelist h5ps://mar3nfowler.com/bliki/MonolithFirst.html (2015) Instead: start simple (KISS) and address the system's natural bottlenecks as they occur ( bugs, delays, dev pain ) 😔 😔 😔 Meanwhile: "If we don't start with microservices, THEY (the bosses) won't give us the .me we need to break it into microservices later" = WASTE
  • 9. 9 VictorRentea.ro Architecture is the art of deferring decisions
  • 10. 10 VictorRentea.ro Pain-Driven Architecture Protect core logic vs ugly API call with an Adapter Split Complexity by Layers of Abstraction (ie. Facade) Isolate Persistence if Shared/Legacy storage Grow a Rich Model in Complex Domains Refactor to Modulith when team grows Use Events for cleaner 1:N Decoupling Go to Microservices to meet NFRs
  • 12. 12 VictorRentea.ro 1) Big-Bang Rewrite of a 12y-old, 3M LOC codebase - Re-gather all requirements and start from scratch - Any changes to the old system you (a) reject, (b) delay, or (b) cost x2 (old+new) - 20-30% success rate & likely to turn into a Distributed Monolith 2) Strangler-Fig Pa4ern (outside-in) ✅ - Rewrite decoupled parts as microservices behind a proxy protecIng clients 3) Refactor to Modules > Extract (inside-out) ✅ - Progressively decouple logic and data in the monolithic codebase From a BBoM to Microservices
  • 13. 13 VictorRentea.ro Refactor to Modules Modulith Can prove the best in some domains Velocity ⏩ FAST 🐌 SLOW Microservices Development Velocity Monolith Project Age Early Late Easy to extract a microservice
  • 14. 14 VictorRentea.ro Can we have the best of both? Deployment architecture of a Monolith Logical decoupling of Microservices + Easy to extract a Microservice
  • 17. 17 VictorRentea.ro Big Ball of Mud Microservices XXL Database eShop Application Catalog Microservice Catalog DB Orders Microservice Orders DB REST REST/MQ Payment Microservice Payment DB
  • 19. 19 VictorRentea.ro Goal of Modulith independent teams managing decoupled modules Example #1 (e-health) each team {4-5 DEV+FE+PO+QA} owns ~4 modules x 8 teams + 2 x FuncIonal Architects + 3 x Core Pladorm Team total = 60 people CI build ≤ 15 minutes (tuned) 1 prod deploy /week on 10 instances Example #2 (pharmacy): 30 people Example #3 (loan approval): 24 people
  • 24. 24 VictorRentea.ro = a stand-alone logical applicaEon, having its own: §business features (user value) §private implementaIon: domain model + logic §public API: - internal, for other modules: via method calls or events - external, for other systems: via REST, Rabbit, KaOa... §private tables in database §micro-frontend: screens & shared components (monorepo) What is a Module?
  • 25. 25 VictorRentea.ro Internal API for other modules External API for other systems MQ RPC implementa4on not accessible by other modules Events publish << plugin >> B listen Methods Interface
  • 26. 26 VictorRentea.ro §Publisher should NOT expect any effect ⚠ §Publisher is unaware of listeners (poten;ally mul;ple) J §The order of listeners should not ma>er. If it does: chain a new event ⚠ §Events can carry state to avoid a call back to publisher 🤔 §All listeners run sequen1ally in the publisher's thread and transac;on (if any) §Listeners can be @Async §Events can be persisted if sent over KaJa/Rabbit.. - Spring-modulith @Applica3onModuleListener persist events in DB un3l processed ⚠ Events are harder to navigate than method calls è use only between modules Events 101 Eventual Consistency
  • 28. 28 VictorRentea.ro ↙ Generated by spring-modulith h5ps://github.com/victorrentea/spring-modulith
  • 29. 29 VictorRentea.ro §ArchUnit @Test www.archunit.org + ported to most languages §Spring Modulith @Test spring.io/projects/spring-modulith §Build Modules (Maven/Gradle) Enforce Code Boundaries @Test !// unit test running on CI public void encapsulatedModules() { var classes = new ClassFileImporter().importPackages("com.myapp"); var sliceRule = slices().matching("!..myapp.(*)!..*") .should().notDependOnEachOther() .ignoreDependency(resideInAnyPackage("!..shared!..", "!..api!..")); sliceRule.check(classes); !// #1 fail on any deviation List<String> violations = sliceRule.evaluate(classes)!!...; assertThat(violations).hasSizeLessThan(33); !// #2 fitness function } @Test void verifyModularity() { !// uses ArchUnit rules under the hood ApplicationModules.of(ModulithApp.class).verify(); }
  • 30. 30 VictorRentea.ro ⚠ Only a'er boundaries are clear AND the team is about to split ✅ Stronger separa2on - Impossible to add excep:ons/@Disable to the ArchUnit @Tests 😏 - Impossible to have cycles è - BeAer IDE sugges:ons (eg: imagine 2 classes named 'Product' in different modules) ✅ Selec2ve dependencies - A module can decide to use jasperreports, use reactor, or refuse lombok - ⚠ All modules share the SAME library VERSIONS in the final binary ✅ Par2al release - Client customiza:ons: invoicing-nhs.jar - Purchased features: payment-exports.jar From Packages to Build Modules (Maven/Gradle)
  • 31. 31 VictorRentea.ro Cyclic Dependencies « module » A « module » B = Tight Coupling (they oEen change together) ⚠ Build fails if modules are separate build units (eg maven/gradle) use use
  • 32. 32 VictorRentea.ro ? ? A B O orchestrator "facade" Pull OrchestraIon Up ? ? ? ? Allow the call cycle, just fix the code cycle shared A-impl B-impl A-api B-api Extract API out run5me calls keep a coarse-grained API, for a monolithic client/site Strategical Dependencies between Modules microservices: shared lib microservices: events on queue microservices: interdependent microservices + client.jar microservices: api gateway/bff/saga microservices: shared lib/3rd service microservices: merge or break ❤ AB Merge Modules Tight Coupling (eg dozens of links) Dependency Inversion B allows A to implement logic, without depending on A A B ç event call Publish Events (in-mem) ⭐Decoupled A B S Push Shared Down A B (code dep) implements è call Dependency Inversion ⭐Decoupled AProviderImpl runtime call «interface» AProvider Module A must react to changes in B "shared" Module: - StringUQls - Logging/Audit - Country list Wrong boundaries. Try others? 🤔
  • 33. 33 VictorRentea.ro The 'Shared' Module §If large => BBoM ☢ - Possible starIng point coming from BBoM §Extract business logic §Extract complex concerns: common-security, common-kaOa.. §Contain internal API of all modules: api.catalog|.inventory 🤔 - ✅ Pros: simple fix to cyclic dependencies - ⚠ Cons: risk of coupling internal APIs (write an ArchUnit rule) §Contain staEc reference data: Country, Region, DiagnosEc... - Be'er than dozens of nano-modules
  • 34. 34 VictorRentea.ro * the same applies for "Microservice" Smaller! Nano! Post-BBoM PTSD ? How small should modules be? or microservices
  • 35. 35 VictorRentea.ro The Fallacy of Nano-Services The microservices honeymoon is over. Uber is refactoring thousands of microservices into a more manageable solution; Kelsey Hightower is predicting monoliths are the future; Sam Newman is declaring that microservices should never be the default choice, but rather a last resort. Monolith can be cheaper (Amazon) and faster (StackOverflow.com) https://vladikk.com/2020/04/09/untangling-microservices/ Smaller pieces => more coupling
  • 36. 36 VictorRentea.ro order product fulfillment place order cancel order return catalog search filter display compare stock inventory stock warehouse supply-chain hEps://www.michaelnygard.com/blog/2018/01/services-by-lifecycle/ Scales Be'er Split by Data Concept (aka En*ty Service) Bu$in€ss Capability / User Value (aka Feature Service)
  • 38. 38 VictorRentea.ro Modules should not share tables Allows to keep in sync: Problem Domain ó Domain Model ó DB or Microservices
  • 39. VictorRentea.ro inventory catalog Split Domain Models class InventoryItem { Product product; Long productId; String productName; ... } class Product { id name ... }
  • 40. 40 VictorRentea.ro Data Decoupling Levels 1. No IsolaGon (BBoM): everyone freely reads/writes any table ⚠ Data CorrupIon: a module could write valid data in a table, but later read bad data. 2. Write IsolaGon: one module writes into a table, but any other can read 🧠 Might require spliong a table (in separate schemas) INVENTORY.ITEMS vs CATALOG.PRODUCTS, CATALOG.PRODUCT_ATTRIBUTES ⚠ Frozen Table Structure: an ALTER TABLE can break the readers 3. Exclusive Access🤩💖: modules have private schemas 😏 Trick: except read-only VIEWS exposed for others to JOIN : INVENTORY.V_STOCK(id, items) 4. Consistency per Module - tables of two modules: (a) do NOT share any Foreign Key, and (b) are NOT updated in the same Transac4on Defer unIl microservice extrac4on is imminent Strong Consistency Eventual Consistency
  • 41. 41 VictorRentea.ro (vs a tradiJonal Monolith)? 1. Complexity EncapsulaIon behind clear Module APIs - Autonomy & Less cogniJve load per module 2. Smaller Domain Model gets specialized, thus more useful - catalog.Product vs inventory.InventoryItem 3. Module owns its Persistence - Easy to keep tables in sync with evolving Domain Model What makes a Modulith maintainable
  • 42. 42 VictorRentea.ro Modulith Challenges Finding Boundaries 🔄 EncapsulaEng Code Decoupling Data Speed of Build & Test OperaEon
  • 43. 45 VictorRentea.ro §End-to-end tests are slow and fragile - Prefer Module-scoped tests ✅ over fragile unit-tests ❌ §"Always ready to ship" using Feature Flags - ⚠ Constantly remove unneeded flags §Parallel Build 😎 §A Monorepo can build mulEple arEfacts: - Modulith + Frontend + 2 Microservices 🤔 Unified Build
  • 44. 46 VictorRentea.ro §Shared TransacIons - An excepIon in a module you call/noIfy can roll back your transacIon §Resource starvaIon - Modules share thread/DB connec4on pool è Monitoring ⚠ §Deadlocks - In-process or out- (DB, Redis) §Single instance of DI container - Global seongs, rogue aspects, bean name collision §Unified OpenAPI - Single version? Type name collisions? DifficulFes of "Running Together"
  • 47. 49 VictorRentea.ro They are cool 😎 Benefits of Microservices
  • 48. 50 VictorRentea.ro Benefits of Microservices ü Faster Time-to-Market => 😁 Business if independently deployable by autonomous teams ü Lower CogniGve Load => 😁 Developers if small & aligned with business ü Scalability for the hot🔥 parts that require it ü Availability: fault-tolerance to parBal failures ü Technology Freedom vs language/library version ü Security / Privacy (GDPR) / Compliance Modulith also provides these
  • 49. 51 VictorRentea.ro Drawbacks of Microservices §Complex to Develop & Deploy §Network Latency & Reliability §Asynchronous CommunicaGon (messages/events) §Eventual Consistency §Hard to Monitor, Trace & Debug $M1 premium
  • 50. 52 VictorRentea.ro §Separate persistence - No cross-schema SELECT. 🤔 Think... - Drop all Foreign Keys to ó from other modules' schemas 🤔 - Stop sharing transac4ons with other modules 🤔 §Separate threads - Turn method calls into REST localhost:8080 calls 🤔 (+propagate TraceId!) - Events: @Async, @ApplicaIonModuleListener, or via Rabbit, Kawa 🤔 §Separate build & deploy 🎉 - Extract module X internal API as a standalone library (x-api.jar) - Then separate Git repo 🤔 Steps to Extract a Module as a Microservice POSTPONE UNTIL EXTRACTING A MICROSERVICE IS PLANNED IN NEAR-FUTURE if a step makes business panic STOP undo, and rethink extracQon
  • 51. 54 VictorRentea.ro §The safest & cheapest way to split a Monolith - To experiment with boundaries & gradually enforce them §A valid alternaEve to Microservices - For complex domains with decent NFRs Modular Monolith is
  • 52. 55 VictorRentea.ro Are you sure you need Microservices? Think again!
  • 53. I was Victor Rentea, trainer & coach for experienced teams. Git: h'ps://github.com/victorrentea/spring-modulith.git Branch: devoxx-uk-24 Meet me online at: