Monoliths (and why you break 'em)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
422
On Slideshare
402
From Embeds
20
Number of Embeds
2

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 20

http://www.railsjam.net 12
http://localhost:3000 8

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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