Slide 1

Slide 1 text

Smash the Monolith Refactoring Rails Applications

Slide 2

Slide 2 text

The ‘A’ Word

Slide 3

Slide 3 text

The definition, composition, and interactions of parts of a system. Software architecture is...

Slide 4

Slide 4 text

A compromise between viability and perfection. Software architecture is...

Slide 5

Slide 5 text

Tempered by the need to deliver a solution. Software architecture is...

Slide 6

Slide 6 text

Some science. Lots of aesthetics. Software architecture is...

Slide 7

Slide 7 text

Software architecture is...

Slide 8

Slide 8 text

vs. An age-old conflict... Big Up-Front Design Cowboy Coding

Slide 9

Slide 9 text

Then: Big Up-Front Design

Slide 10

Slide 10 text

Advantages Long-term product roadmaps Rich design artifacts Guided evolution Predictability

Slide 11

Slide 11 text

Disadvantages Slow implementation Resistance to change New feature friction No room for mistakes

Slide 12

Slide 12 text

Now: Ad-Hoc Architecture

Slide 13

Slide 13 text

Guiding Principles Convention over configuration Discrete MVC layers Good separation of concerns RESTful and resourceful

Slide 14

Slide 14 text

The Best Intentions Test-driven development + pair programming + pull requests + code reviews = emergent design

Slide 15

Slide 15 text

The Best Intentions

Slide 16

Slide 16 text

Non-CRUD controller methods. The Road to Hell

Slide 17

Slide 17 text

Logic leaking into controllers and views. The Road to Hell

Slide 18

Slide 18 text

Complex object graphs. The Road to Hell

Slide 19

Slide 19 text

/lib/ becomes a junk drawer. The Road to Hell

Slide 20

Slide 20 text

Undocumented gem dependencies. The Road to Hell

Slide 21

Slide 21 text

Bloated user model. The Road to Hell

Slide 22

Slide 22 text

Signs of a Degraded Design Rigidity

Slide 23

Slide 23 text

Signs of a Degraded Design Fragility

Slide 24

Slide 24 text

Signs of a Degraded Design Immobility

Slide 25

Slide 25 text

Signs of a Degraded Design Feature friction

Slide 26

Slide 26 text

Change Gets Harder Over Time Relatively Easy Delegate If Possible Take a Sick Day KILL IT WITH FIRE Difficulty of Change Time

Slide 27

Slide 27 text

How did we get here?

Slide 28

Slide 28 text

How did we get here? Dozens of hands on the code.

Slide 29

Slide 29 text

How did we get here? Classes naturally attract new methods.

Slide 30

Slide 30 text

How did we get here? Increasingly slow test suite.

Slide 31

Slide 31 text

How did we get here? Entropy.

Slide 32

Slide 32 text

How did we get here? One line of code at a time.

Slide 33

Slide 33 text

“Most software eventually degrades to the point where someone will declare the design to be unsound.” Uncle Bob Martin

Slide 34

Slide 34 text

Values-Driven Development

Slide 35

Slide 35 text

Things We Value Fresh ideas combined with best practices.

Slide 36

Slide 36 text

Things We Value Solid design principles applied in novel ways.

Slide 37

Slide 37 text

A Values-Based Approach Culture of innovation + best practices + solid design principles = better architecture?

Slide 38

Slide 38 text

Hexagonal Design

Slide 39

Slide 39 text

Theoretical Backing Layered architectures break down in practice.

Slide 40

Slide 40 text

Domain Objects HTTP Command Line Testing Messaging Persistence Monitoring Sinatra Cron Test Unit Beanstalkd Postgres Honey Badger Rails Rake RSpec Rabbit MongoDB New Relic

Slide 41

Slide 41 text

Design Considerations Design for all of your users, not just the obvious ones.

Slide 42

Slide 42 text

Design Considerations Give every class its own distinct API.

Slide 43

Slide 43 text

Design Considerations Write your application in pure Ruby.

Slide 44

Slide 44 text

Theoretical Backing Achieve framework independence.

Slide 45

Slide 45 text

Using APIs & Messages

Slide 46

Slide 46 text

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Doug McIlroy, Bell Labs CSRC HTTP

Slide 47

Slide 47 text

Design Considerations Implement an ecosystem of small applications.

Slide 48

Slide 48 text

Design Considerations Divide models between the applications.

Slide 49

Slide 49 text

Design Considerations Persistence is a service.

Slide 50

Slide 50 text

Design Considerations Bind applications together using APIs and messaging.

Slide 51

Slide 51 text

Design Considerations Determine a caching strategy.

Slide 52

Slide 52 text

Design Considerations Pick a messaging solution.

Slide 53

Slide 53 text

Rethinking Architecture

Slide 54

Slide 54 text

Roots Rock.

Slide 55

Slide 55 text

A Sudden Revelation What if we think of an application... ...as just another object?

Slide 56

Slide 56 text

Object-Oriented Architecture

Slide 57

Slide 57 text

Theoretical Backing Apply OO design principles to the architecture itself.

Slide 58

Slide 58 text

Classes communicating via messages Applications communicating via APIs & queues ! Theoretical Backing

Slide 59

Slide 59 text

Applying OO Principles An application is a group of components that perform tasks on the same data.

Slide 60

Slide 60 text

Applying OO Principles An application should do one well-defined thing.

Slide 61

Slide 61 text

Applying OO Principles APIs allow us to easily extend our interfaces.

Slide 62

Slide 62 text

Applying OO Principles It doesn’t matter what application sends, receives or processes our messages.

Slide 63

Slide 63 text

Applying OO Principles APIs and presenters allow us to easily create client-specific interfaces.

Slide 64

Slide 64 text

Legacy Applications

Slide 65

Slide 65 text

What is a legacy app? Age is not measured in months or years or versions.

Slide 66

Slide 66 text

What is a legacy app? Legacy code is not broken.

Slide 67

Slide 67 text

What is a legacy app? Don’t git blame.

Slide 68

Slide 68 text

What is a legacy app? A storehouse of information about a problem space.

Slide 69

Slide 69 text

Refactoring Tactics Dismantle god classes.

Slide 70

Slide 70 text

Refactoring Tactics Extract behaviors into modules.

Slide 71

Slide 71 text

Refactoring Tactics Extract models and business logic into engines.

Slide 72

Slide 72 text

Refactoring Tactics Migrate engines into discrete applications.

Slide 73

Slide 73 text

Refactoring Tactics Implement observers using a messaging service.

Slide 74

Slide 74 text

Refactoring Tactics Provide persistence through asynchronous services.

Slide 75

Slide 75 text

Refactoring Tactics Direct calls between applications rely on a good set of APIs.

Slide 76

Slide 76 text

Refactoring Tactics Use your API as a guide to refactoring your models.

Slide 77

Slide 77 text

Synchronous Calls via APIs Credentials Auth Token Auth Service Client App

Slide 78

Slide 78 text

Asynchronous Calls via Message Queues Prefs Update Client App Attr Change Persistence Service

Slide 79

Slide 79 text

Refactoring Tactics Find functional edges and refactor them into services.

Slide 80

Slide 80 text

Refactoring Tactics Make liberal use of the presenter pattern.

Slide 81

Slide 81 text

A declarative framework useful for building APIs. faceted.rb

Slide 82

Slide 82 text

On the Other Side of Refactoring

Slide 83

Slide 83 text

A Small App Ecosystem Consumer App Internal App 1 Internal App 2 Persistence API Messaging API Reporting API Dashboard App

Slide 84

Slide 84 text

Reap the Benefits Reduced cost of change.

Slide 85

Slide 85 text

Reap the Benefits Support for unexpected and novel use cases.

Slide 86

Slide 86 text

Reap the Benefits Reduction of ceremony around releases.

Slide 87

Slide 87 text

Reap the Benefits Low-impact downtime.

Slide 88

Slide 88 text

Reap the Benefits Short ramp-up time for new developers.

Slide 89

Slide 89 text

Reap the Benefits Increased performance of test suites.

Slide 90

Slide 90 text

Reap the Benefits A/B testing on applications and infrastructure.

Slide 91

Slide 91 text

Reap the Benefits Greater flexibility.

Slide 92

Slide 92 text

Reap the Benefits Democratization of application architecture.

Slide 93

Slide 93 text

Go smash your monolith.

Slide 94

Slide 94 text

smashthemonolith.com Corey Ehmke @bantik