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.

1. Minimal Viable Architecture
Good Enough is Good Enough
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup

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]”

4. Architecture Evolution
• eBay
• 5th generation today
• Monolithic Perl  Monolithic C++  Java  microservices
• Twitter
• 3rd generation today
• Monolithic Rails  JS / Rails / Scala  microservices
• Amazon
• Nth generation today
• Monolithic Perl / C++  Java / Scala  microservices

5. No one starts with microservices
…
Past a certain scale, everyone
ends up with microservices

6. Getting to rearchitect a system
is a sign of success, not failure.

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

9. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/

10. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
I
D
E
A

11. What problem are
you trying to solve?

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

15. “Do things that don’t scale”
-- Paul Graham

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

17. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
One Team
3-6 month
horizon

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

21. The Monolithic
Architecture
2-3 monolithic tiers
Presentation
Application
Database

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

24. Assembly,
not Construction

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

28. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
More and More Teams
6-24 month
horizon

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

31. Scaling Phase:
Scalable Architecture
• Scalable persistence
• Break up the monolithic database
• Functional partitioning
• Sharding

32. Microservices
• Single-purpose
• Simple, well-defined interface
• Modular and independent
A
C D E
B

33. Microservices
• Single-purpose
• Simple, well-defined interface
• Modular and independent
• Isolated persistence (!)
A
C D E
B

34. Microservices are nothing
more than SOA done properly.

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.

39. “Enforcing”
Standardization
• Encouraged via
o Libraries
o Support in underlying services
o Code reviews
o Searchable code

40. The easiest way to “enforce” a
standard practice is with
working code.

41. Rule of Three
“Three strikes and you refactor”

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

46. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
Fewer Teams
2-5 year
horizon

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)

48. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/

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

50. is hiring in NYC, SF, TLV
wework.com/careers