@robb1e
Simple, small web application
Service oriented RESTful/pubsub/LMAX/P2P
distributed architecture
Gray area
Slide 5
Slide 5 text
@robb1e
Our codebase is 5 years
old and too hard to change
Slide 6
Slide 6 text
@robb1e
We’ve allowed our design
to evolve into a big
ball of mud
Slide 7
Slide 7 text
@robb1e
We’ll probably create
services at some point,
might as well start there
Slide 8
Slide 8 text
@robb1e
I’m going to design
everything up front based on
unvaldiated assumptions
Slide 9
Slide 9 text
@robb1e
Kent Beck
Make it work,
make it right,
make it fast
Slide 10
Slide 10 text
@robb1e
• Features that have hypotheses
• Hypotheses that can be easily validated
• Code that is always production ready
• Code that is easy to change
Goals
@robb1e
Perceived performance is more
important than actual performance
Take away
Slide 98
Slide 98 text
@robb1e
Was that really the
best use of your time?
Story
Slide 99
Slide 99 text
@robb1e
During technical due
diligence for an acquisition
Slide 100
Slide 100 text
@robb1e
The company had built
their own message queue
Slide 101
Slide 101 text
@robb1e
No persistence
Slide 102
Slide 102 text
@robb1e
Didn’t use standard
protocol like AMPQ
Slide 103
Slide 103 text
@robb1e
Not explicitly sending a
terminating character
would eventually result
in the queue crashing
Slide 104
Slide 104 text
@robb1e
Almost all transactions
passed through this queue
Slide 105
Slide 105 text
@robb1e
Not buying a message
queue company
Slide 106
Slide 106 text
@robb1e
- Joel Spolsky, 2001
"If it's a core business
function - do it yourself,
no matter what."
Slide 107
Slide 107 text
@robb1e
Time is the most expensive out going
Bonus
Slide 108
Slide 108 text
@robb1e
Real-time vs near-time
Story
Slide 109
Slide 109 text
@robb1e
Trading system which
updates users’ screen
every 10 seconds
Slide 110
Slide 110 text
@robb1e
Lots of number crunching
and message queues
Slide 111
Slide 111 text
@robb1e
Did some in the
field research
Slide 112
Slide 112 text
@robb1e
Traders only checked
values every few minutes
Slide 113
Slide 113 text
@robb1e
This was not high
volatile trading
http://www.boldjack.com/wp-content/uploads/2012/01/wall_street4.jpg
Slide 114
Slide 114 text
@robb1e
Removed message
queues and moved
to publishing updates
to web server directly
Slide 115
Slide 115 text
@robb1e
Reduced complexity
of the product
Slide 116
Slide 116 text
@robb1e
Ron Jefferies, ~2005
Always implement things when
you actually need them, never
when you just foresee that you
need them
Slide 117
Slide 117 text
@robb1e
‘Real-time’ can mean different things
depending on who you talk too
Bonus
Slide 118
Slide 118 text
@robb1e
Buy vs build
Story
Slide 119
Slide 119 text
@robb1e
$50 a month is really
expensive for this
hosted service
Slide 120
Slide 120 text
@robb1e
We can build it ourselves
and get exactly the
features we need
Slide 121
Slide 121 text
@robb1e
Can you build the
widget service yourself
in that time?
Slide 122
Slide 122 text
@robb1e
Are you in the
widget business?
Slide 123
Slide 123 text
@robb1e
Francis Hwang, 2012
The biggest expense for a startup
is your time. Not your laptop, not
your hosting bill, not your office,
but the hours in your day.
Slide 124
Slide 124 text
@robb1e
Focus on your differentiators
Bonus
Slide 125
Slide 125 text
@robb1e
Over engineering is a form of waste
Take away
Slide 126
Slide 126 text
@robb1e
Horizontal Scalability
Story
Slide 127
Slide 127 text
@robb1e
Guardian Content API
is read only and
eventually consistent
Slide 128
Slide 128 text
@robb1e
Used by m., iPhone app,
parts of www. and more
Slide 129
Slide 129 text
@robb1e
Just a simple API over
an indexed data store
Slide 130
Slide 130 text
@robb1e
Each server has
it’s own data store
Slide 131
Slide 131 text
@robb1e
Each data store is a replica
of an internal master
Slide 132
Slide 132 text
@robb1e
Simple, elegant design can prevent
complex architecture creep
Lesson
Slide 133
Slide 133 text
@robb1e
• Solr
• Elastic Search
• MongoDB
Tools
Slide 134
Slide 134 text
@robb1e
Emergency mode
Story
Slide 135
Slide 135 text
@robb1e
Use of feature switches
at Guardian enable
‘super happy fun mode’
Slide 136
Slide 136 text
@robb1e
Turn features off when
site under increased load
Slide 137
Slide 137 text
@robb1e
Content is king and must
be readable at all times
Slide 138
Slide 138 text
@robb1e
Page pressing enables
zero downtime and
last fallback
Slide 139
Slide 139 text
@robb1e
Feature flags can offer resilience as
well as a way to roll out new features
Lesson
Slide 140
Slide 140 text
@robb1e
Complex should be lots of simple
Take away
Slide 141
Slide 141 text
@robb1e
Allow architecture to evolve
Spend your time wisely
Refactor continuously
Slide 142
Slide 142 text
@robb1e
Sandi Metz
“The wrong abstraction is far more
damaging than no abstraction at
all. Waiting trumps guessing every
time”