I have spent the last decade building large-scale systems at eBay and Google -- and talking publicly about it -- and this presentation is about why a startup should completely ignore what I said! In an early-stage startup, it is not only not worth architecting for a future of massive scale; it is actively counterproductive. This presentation from the SF Startup CTO Summit outlines the common architectural evolution of a startup through the search, execution, and scaling phases, and discusses the appropriate technologies and disciplines at each phase. It ends with some real-world examples from eBay, Twitter, and Amazon to illustrate the point.
3. Minimal Viable
Architecture
• You Ain’t Going to Need It (!)
• Use the Right Tool for the Right Job (at the Right
Time!)
• Only Change Incrementally
4. Phases of a Startup
• Search Phase
• Execution Phase
• Scaling Phase
5. Phases of a Startup
• Search Phase
• Execution Phase
• Scaling Phase
6. Search Phase:
“Prototype” Architecture
• Goal: Explore the space as rapidly and cheaply as
possible
• Find business model
• Find product market fit
• Acquire first customers
• Rapid Iteration
• *Everything* is a prototype
• You *will* throw it all away
8. Search Phase:
“Prototype” Architecture
• Ideally No Technology At All
• I’m serious – what are you even building?!
• If you *really* need to build something …
• Familiar technology
• Cobble it together
9. Phases of a Startup
• Search Phase
• Execution Phase
• Scaling Phase
10. Execution Phase:
“Just Enough” Architecture
• Goal: Meet near-term, evolving customer needs as
cheaply as possible
• Delight first customers
• Acquire more
• Rapid Learning and Improvement
• Team Productivity
• NOT about scaling
11. “The best code you can write
now is code you’ll discard in a
couple of years time”
-- Martin Fowler
http://martinfowler.com/bliki/SacrificialArchitecture.htm
l
12. Execution Phase:
“Just Enough” Architecture
• Familiar Technology
• Ease of Use
• Expressive Power
• Simple (!)
• Monolithic Architecture
• Single database
• Minimal Infrastructure
• PaaS over IaaS
14. The Monolithic
Architecture
Pros
Simple at first
In-process latencies
Single codebase, deploy unit
Resource-efficient at small scale
Cons
Coordination overhead as team
grows
Poor enforcement of modularity
Poor scaling (vertical only)
All-or-nothing deploy (downtime,
failures)
Long build times
15. Execution Phase:
“Just Enough” Architecture
• Modularity Discipline
• Bound cognitive load
• Easy to modify or replace
• Detailed Logging
• Insights into user behavior
• Diagnosis and recovery
• Continuous Delivery
• Deploy many times per day
16. Phases of a Startup
• Search Phase
• Execution Phase
• Scaling Phase
17. Scaling Phase:
“Next-Gen” Architecture
• Goal: Stay ahead of rapidly growing business. Keep
the site up (!)
• Scaling the Team
• Scaling the Technology
• Concurrency and Efficiency
18. “If you don’t end up
regretting your early
technology decisions, you
probably over-engineered”
-- me
19. Scaling Phase:
“Next-Gen” Architecture
• Technology that Scales
• Common migrations to {Python, Go, JVM languages}
• Concurrency
• Asynchrony
• Independent systems
• Fit-for-purpose systems: analytics, search
• Layered services: caching, etc.
• Event queue
• Scalable persistence
• Break up the monolithic database
• Functional partitioning
• Sharding
• Scalable Infrastructure
• IaaS for some systems
20. Scaling Phase:
Change Incrementally
• Find your worst scaling bottleneck
• Wall it off behind an interface
• Replace it
• Rinse and Repeat