monoliths (and why you break 'em)
DESCRIPTION
TRANSCRIPT
MONOLITHS
(when you have to break ‘em.. And why)
What’s a monolith?
• Simply put: an application that has grown too big for its own good
• Coined from the 2010 Railsconf presentation “From 1 to 30..”
• No discernable architecture
• Less hurtful term for BBM
Why Rails is particularly susceptible?
• Deceptively simple• Lots of abuse-able
features (sessions, controllers, embedded ruby)
• Fast development = fast degeneration
Disclaimer
• Just because its big, doesn’t mean it’s bad.• You can go big as long as you:– Have a plan (architecture) – Follow conventions (DRY, convention over
configuration)– Test (BDD)
“How did it come to this? “
• Badly executed agile application development
• Unfamiliarity with Ruby and/or Rails
• Doing it RIGHT took a backseat to Doing it RIGHT NOW
• Poor communication/cooperation between developers
• No refactoring
Symptoms
• Lack of modularity makes it hard to:– extend– maintain– deploy– test
• LOTS of duplication• LOTS of coupling• Difficult to bring in new
people
Why break it (up)?
• When a module goes down, only IT goes down
• A chance to start over without ACTUALLY starting over (Perfect opportunity to refactor)
• Opposite of everything in the previous slide (easier to maintain, test, etc..)
Why break it (up)? Continued…
• Developer autonomy• Enforced
modularization and decoupling
• Easier to debug
Getting started
1. Split application into as many logical modules as possible
2. Determine which ones have the most interaction
3. Group those together4. Repeat steps 1 -3 until comfortable5. ???6. Profit!
Implementation Ideas
• Shared DB + libraries• Multiple DB’s + Synching• Web services / interfaces
There’s always a catch…
• Performance hit unless on the same intranet• Extra layer of security for
webservices/interfaces• Servers aren’t free
In closing…
• If you don’t break it up.. it will break down