This presentation introduces the idea of a "Minimal Viable Architecture". As a company and product evolves, its architecture should evolve as well. We talk about the different phases of a product -- from the idea phase, to the starting phase, scaling phase, and optimizing phase. For each phase, we discuss the goals and constraints on the business, and we suggest an appropriate software architecture to match. Throughout the presentation, we use examples from eBay, Google, StitchFix, and others.

1. Minimal Viable
Architecture
Randy Shoup
@randyshoup

2. Background
@randyshoup

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

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
@randyshoup

6. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/@randyshoup

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

8. What problem are
you trying to solve?
@randyshoup

9. “There is nothing
so useless as
doing efficiently
that which should
not be done at
all.”
@randyshoup
-- Peter Drucker

10. “A problem
well-stated
is a problem
half-solved.”
-- Charles Kettering,
head of research at GM
@randyshoup

11. “Prototype” Architecture
• Goal: Explore our problem 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
@randyshoup

12. “Prototype” Architecture
• Ideally No Technology At All
• Paper prototypes
• Google ads
• Excel spreadsheet
• Wordpress blog
• If you *really* need to build something …
• Familiar technology
• Cobble it together
@randyshoup

13. Engineering is about solving
problems.
Sometimes we solve those
problems by writing code.
@randyshoup

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

15. Two-Pizza Team
4-6
people
“A team should be no larger
than can be fed by two large
pizzas.”
-- Jeff Bezos, Amazon
@randyshoup

16. “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
@randyshoup

17. “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
@randyshoup

18. “Just Enough” Architecture
• Simple, Familiar Technology
• Expressive Power and Ease of Use
• Rapid prototyping frameworks (Ruby / Rails, PHP, etc.)
• Monolithic Architecture
• Single application
• Single database
• No Infrastructure
• Ideally Serverless or Platform-as-a-service
@randyshoup

19. Monolithic Architecture
2-3 monolithic tiers
Presentation
Application
Database@randyshoup

20. 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

21. Buy, Not Build
• Use Cloud Infrastructure
o Faster, cheaper, better than we can do ourselves
o WeWork and Stitch Fix have no owned physical infrastructure anywhere in the
world
• Prefer Open Source
o Usually better than the commercial alternatives (!)
@randyshoup

22. Buy, Not Build
• 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

23. Assembly,
not Construction

24. Preparing to Scale
• Modularity Discipline
• Use “shared libraries” within the monolith
• Easy to modify or replace
• Detailed Logging and Instrumentation
• Understand user behavior
• Enable diagnosis and recovery
@randyshoup

25. Continuous Delivery
• Repeatable Deployment Pipeline
o Low-risk, push-button deployment
o Rapid release cadence
o Rapid rollback and recovery
• Most applications deployed multiple times per day
• More solid systems
o Release smaller units of work
o Smaller changes to roll back or roll forward
o Faster to repair, easier to understand, simpler to diagnose
@randyshoup

26. Feature Flags
• Configuration “flag” to enable / disable a feature for a
particular set of users
o Independently discovered at eBay, Facebook, Google, etc.
• More solid systems
o Decouple feature delivery from code delivery
o Rapid on and off
o Develop / test / verify in production
o Dark launches
• Enables experimentation
o A | B testing
@randyshoup

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

28. 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
@randyshoup

29. 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
@randyshoup

30. Scalable Architecture
• Goal: Stay ahead of rapidly growing business. Keep the site up
(!)
• Scaling the Teams
• Scaling the Technology
• Repeatable Processes
@randyshoup

31. Many Two-Pizza Teams
Idea
Development
Quality
Operations
Idea
Development
Quality
Operations
Idea
Development
Quality
Operations

32. Business Alignment
<Business
Domain>
• Aligned around a business
problem
o Clear goals and metrics …
o … that matter to customers!
• Well-defined area of responsibility
o Single application / service or set of related
applications / services
@randyshoup

33. Scalable Architecture
• Technology that Scales
• Common migrations to {Python, Go, JVM languages}
• Latency and performance
• Separate services
• Payments, etc.
• Fit-for-purpose systems
• Analytics, search, etc.
@randyshoup

34. Scalable Architecture
• Scalable persistence
• Break up the monolithic database
• Publish-subscribe event system
• Use events to communicate between applications and services
@randyshoup

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

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

37. Microservice Architecture
• Each unit is simple
• Independent scaling
• Independent deployment
• “Optimal” technology stack
• Security boundary
• Multiple cooperating units
• Exchange in-process for
network latencies
• More sophisticated deployment
and monitoring
• Overall system complexity
Pros Cons

38. Getting to rearchitect a system
is a sign of success, not failure.
@randyshoup

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

40. 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)

41. STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/@randyshoup

42. If you don’t end up regretting
your early technology
decisions, you probably over-
engineered.
@randyshoup

43. Thank you!
@randyshoup
linkedin.com/in/randyshoup
medium.com/@randyshoup