This document discusses the concept of minimal viable architecture and how architecture should evolve over time as a system grows. It recommends starting with simple prototypes and monolithic architectures, then transitioning to scalable architectures like microservices as needs increase. Key points are to solve current problems simply, use standard tools, iterate quickly, and focus on quality from the beginning rather than over-engineering prematurely. Architecture should progress from starting to scaling to optimizing phases as the system matures.
2. Background
• VP Engineering at WeWork
o Physical space as a service
• VP Engineering at Stitch Fix
o Using technology and data science to revolutionize clothing retail
• Director of Engineering for Google App Engine
o World’s largest Platform-as-a-Service
• Chief Engineer at eBay
o Evolving multiple generations of eBay’s infrastructure
3. “Tell us how you did
things at Google and
eBay.”
“Sure, I’ll tell you, but
you have to promise
not to do them!
[… yet]”
7. If you don’t end up regretting
your early technology
decisions, you probably over-
engineered.
8. Minimal Viable
Architecture
• You Ain’t Going to Need It (!)
• Use the Right Tool for the Right Job (at the Right Time!)
• Solve the problems you have, not the problems you
might have
12. “Building the wrong thing is
the biggest waste in software
development.”
-- Mary and Tom Poppendieck,
Lean Software Development
13. “A problem well-stated is a
problem half-solved.”
-- Charles Kettering, former head of research
for General Motors
14. Idea 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
16. Idea 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
18. Starting 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
19. “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.html
20. Starting Phase:
“Just Enough” Architecture
• Familiar Technology
• Ease of Use
• Expressive Power
• Simple (!)
• Monolithic Architecture
• Single database
• Minimal Infrastructure
• Ideally serverless
• PaaS or Lambda instead of IaaS
22. Monolithic Architecture
• Simple at first
• In-process latencies
• Single build and
deployment unit
• Resource-efficient at
small scale
• Coordination overhead as
team grows
• Poor enforcement of
modularity
• No horizontal scaling
• Single point of failure, single
performance bottleneck
Pros Cons
23. Buy, Not Build
• Open-Source Software
o Often better than commercial alternatives
• Third-Party Services
o Logging, monitoring, alerting
o Project management, bug tracking
o Payments, billing, fraud detection
o Etc.
• Focus on your core competency
o Use services for everything else (!)
@randyshoup linkedin.com/in/randyshoup
25. Starting Phase:
Preparing to Scale
• Modularity Discipline
• Use “shared libraries” within the monolith
• Easy to modify or replace
• Detailed Logging
• Understanding user behavior
• Instrumenting for diagnosis and recovery
• Continuous Delivery
• Deploy many times per day
26. When to
Rearchitect?
• Velocity
o Time to market is constrained by coupling and lack of isolation in the monolith
o Teams step on each others’ toes, and can no longer develop independently
o Difficult for new engineers to be productive
• Scaling
o Vertical scaling of the monolith no longer works
o Parts of the system need to scale independently of others
27. When to
Rearchitect?
• Deployment
o Parts of the system need to deploy independently of others
o Monolithic release is too slow, too complicated, too risky
29. Scaling Phase:
Scalable Architecture
• Goal: Stay ahead of rapidly growing business. Keep the
site up (!)
• Scaling the Team(s)
• Scaling the Technology
• Repeatable Processes
30. Scaling Phase:
Scalable Architecture
• Technology that Scales
• Common migrations to {Python, Go, JVM languages}
• Concurrency
• Asynchrony
• Independent systems
• Fit-for-purpose systems: analytics, search
• Separated services: payments, etc.
• Layered services: caching, etc.
• Event queue
• Use events to communicate between applications and services
35. Microservice Architecture
• Each unit is simple
• Independent scaling and
performance
• Independent testing and
deployment
• “Optimal” technology stack
• Security boundary
• Multiple cooperating units
• Exchange in-process for
network latencies
• More sophisticated
deployment and monitoring
tools
• Overall system complexity
Pros Cons
36. Evolution,
not Central Control
• No centralized design or approval
o Most technology decisions made locally instead of globally
• Build services as needed
o Create / extract new services when needed to solve a problem
o Services justify their continued existence through usage
o Deprecate services when no longer used
37. “Every service at Google is
either deprecated or not ready
yet.”
-- Google engineering proverb
38. Standardization
• Standardized communication
o Network protocols
o Data formats
o Interface schema / specification
• Standardized infrastructure
o Source control
o Configuration management
o Cluster management
o Monitoring, alerting, diagnosing, etc.
42. “Do you have time to do it
twice?”
“We don’t have time to do it
right!”
43. The more constrained you are
on time or resources, the more
important it is to build it right
the first time.
44. Quality
Discipline
• Quality and Reliability are “Priority-0 features”
o Equally important to users as product features and engaging user experience
• Developers responsible for
o Features
o Quality
o Performance
o Reliability
o Manageability
45. Build It Right (Enough)
The First Time
• Build one great thing instead of two half-finished things
• Right != Perfect
o 80 / 20 Rule
47. Optimizing Phase:
Stable Architecture
• Goal: Make a stable system more sustainable, efficient,
effective
• Sustainable, incremental improvements in functionality
• Sustainable improvements in technology efficiency
• Consolidating the Team(s)
49. Minimal Viable
Architecture
• You Ain’t Going to Need It (!)
• Use the Right Tool for the Right Job (at the Right Time!)
• Solve the problems you have, not the problems you
might have