1. MONOLITHS (when you have to break ‘em.. And why)

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

3. Why Rails is particularly susceptible? Deceptively simple Lots of abuse-able features (sessions, controllers, embedded ruby) Fast development = fast degeneration

4. 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)

5. “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

6. Symptoms Lack of modularity makes it hard to: extend maintain deploy test LOTS of duplication LOTS of coupling Difficult to bring in new people

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

8. Why break it (up)? Continued… Developer autonomy Enforced modularization and decoupling Easier to debug

9. Getting started Split application into as many logical modules as possible Determine which ones have the most interaction Group those together Repeat steps 1 -3 until comfortable ??? Profit!

10. Implementation Ideas Shared DB + libraries Multiple DB’s + Synching Web services / interfaces

11. There’s always a catch… Performance hit unless on the same intranet Extra layer of security for webservices/interfaces Servers aren’t free

12. In closing… If you don’t break it up.. it will break down