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