Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Minimal Viable Architecture
Good Enough is Good Enough
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup
Background
• VP Engineering at WeWork
o Physical space as a service
• VP Engineering at Stitch Fix
o Using technology and ...
“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]”
Architecture Evolution
• eBay
• 5th generation today
• Monolithic Perl  Monolithic C++  Java  microservices
• Twitter
•...
No one starts with microservices
…
Past a certain scale, everyone
ends up with microservices
Getting to rearchitect a system
is a sign of success, not failure.
If you don’t end up regretting
your early technology
decisions, you probably over-
engineered.
Minimal Viable
Architecture
• You Ain’t Going to Need It (!)
• Use the Right Tool for the Right Job (at the Right Time!)
•...
STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
I
D
E
A
What problem are
you trying to solve?
“Building the wrong thing is
the biggest waste in software
development.”
-- Mary and Tom Poppendieck,
Lean Software Develo...
“A problem well-stated is a
problem half-solved.”
-- Charles Kettering, former head of research
for General Motors
Idea Phase:
“Prototype” Architecture
• Goal: Explore the space as rapidly and cheaply as
possible
• Find business model
• ...
“Do things that don’t scale”
-- Paul Graham
Idea Phase:
“Prototype” Architecture
• Ideally No Technology At All
• I’m serious – what are you even building?!
• If you ...
STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
One Team
3-6 month
horizon
Starting Phase:
“Just Enough” Architecture
• Goal: Meet near-term, evolving customer needs as
cheaply as possible
• Deligh...
“The best code you can write
now is code you’ll discard in a
couple of years time”
-- Martin Fowler
http://martinfowler.co...
Starting Phase:
“Just Enough” Architecture
• Familiar Technology
• Ease of Use
• Expressive Power
• Simple (!)
• Monolithi...
The Monolithic
Architecture
2-3 monolithic tiers
Presentation
Application
Database
Monolithic Architecture
• Simple at first
• In-process latencies
• Single build and
deployment unit
• Resource-efficient a...
Buy, Not Build
• Open-Source Software
o Often better than commercial alternatives
• Third-Party Services
o Logging, monito...
Assembly,
not Construction
Starting Phase:
Preparing to Scale
• Modularity Discipline
• Use “shared libraries” within the monolith
• Easy to modify o...
When to
Rearchitect?
• Velocity
o Time to market is constrained by coupling and lack of isolation in the monolith
o Teams ...
When to
Rearchitect?
• Deployment
o Parts of the system need to deploy independently of others
o Monolithic release is too...
STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
More and More Teams
6-24 month
horizon
Scaling Phase:
Scalable Architecture
• Goal: Stay ahead of rapidly growing business. Keep the
site up (!)
• Scaling the Te...
Scaling Phase:
Scalable Architecture
• Technology that Scales
• Common migrations to {Python, Go, JVM languages}
• Concurr...
Scaling Phase:
Scalable Architecture
• Scalable persistence
• Break up the monolithic database
• Functional partitioning
•...
Microservices
• Single-purpose
• Simple, well-defined interface
• Modular and independent
A
C D E
B
Microservices
• Single-purpose
• Simple, well-defined interface
• Modular and independent
• Isolated persistence (!)
A
C D...
Microservices are nothing
more than SOA done properly.
Microservice Architecture
• Each unit is simple
• Independent scaling and
performance
• Independent testing and
deployment...
Evolution,
not Central Control
• No centralized design or approval
o Most technology decisions made locally instead of glo...
“Every service at Google is
either deprecated or not ready
yet.”
-- Google engineering proverb
Standardization
• Standardized communication
o Network protocols
o Data formats
o Interface schema / specification
• Stand...
“Enforcing”
Standardization
• Encouraged via
o Libraries
o Support in underlying services
o Code reviews
o Searchable code
The easiest way to “enforce” a
standard practice is with
working code.
Rule of Three
“Three strikes and you refactor”
“Do you have time to do it
twice?”
“We don’t have time to do it
right!”
The more constrained you are
on time or resources, the more
important it is to build it right
the first time.
Quality
Discipline
• Quality and Reliability are “Priority-0 features”
o Equally important to users as product features an...
Build It Right (Enough)
The First Time
• Build one great thing instead of two half-finished things
• Right != Perfect
o 80...
STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
Fewer Teams
2-5 year
horizon
Optimizing Phase:
Stable Architecture
• Goal: Make a stable system more sustainable, efficient,
effective
• Sustainable, i...
STARTING SCALING OPTIMIZING
https://ittybiz.com/s-curve/
Minimal Viable
Architecture
• You Ain’t Going to Need It (!)
• Use the Right Tool for the Right Job (at the Right Time!)
•...
is hiring in NYC, SF, TLV
wework.com/careers
Upcoming SlideShare
Loading in …5
×

of

Minimum Viable Architecture - Good Enough is Good Enough Slide 1 Minimum Viable Architecture - Good Enough is Good Enough Slide 2 Minimum Viable Architecture - Good Enough is Good Enough Slide 3 Minimum Viable Architecture - Good Enough is Good Enough Slide 4 Minimum Viable Architecture - Good Enough is Good Enough Slide 5 Minimum Viable Architecture - Good Enough is Good Enough Slide 6 Minimum Viable Architecture - Good Enough is Good Enough Slide 7 Minimum Viable Architecture - Good Enough is Good Enough Slide 8 Minimum Viable Architecture - Good Enough is Good Enough Slide 9 Minimum Viable Architecture - Good Enough is Good Enough Slide 10 Minimum Viable Architecture - Good Enough is Good Enough Slide 11 Minimum Viable Architecture - Good Enough is Good Enough Slide 12 Minimum Viable Architecture - Good Enough is Good Enough Slide 13 Minimum Viable Architecture - Good Enough is Good Enough Slide 14 Minimum Viable Architecture - Good Enough is Good Enough Slide 15 Minimum Viable Architecture - Good Enough is Good Enough Slide 16 Minimum Viable Architecture - Good Enough is Good Enough Slide 17 Minimum Viable Architecture - Good Enough is Good Enough Slide 18 Minimum Viable Architecture - Good Enough is Good Enough Slide 19 Minimum Viable Architecture - Good Enough is Good Enough Slide 20 Minimum Viable Architecture - Good Enough is Good Enough Slide 21 Minimum Viable Architecture - Good Enough is Good Enough Slide 22 Minimum Viable Architecture - Good Enough is Good Enough Slide 23 Minimum Viable Architecture - Good Enough is Good Enough Slide 24 Minimum Viable Architecture - Good Enough is Good Enough Slide 25 Minimum Viable Architecture - Good Enough is Good Enough Slide 26 Minimum Viable Architecture - Good Enough is Good Enough Slide 27 Minimum Viable Architecture - Good Enough is Good Enough Slide 28 Minimum Viable Architecture - Good Enough is Good Enough Slide 29 Minimum Viable Architecture - Good Enough is Good Enough Slide 30 Minimum Viable Architecture - Good Enough is Good Enough Slide 31 Minimum Viable Architecture - Good Enough is Good Enough Slide 32 Minimum Viable Architecture - Good Enough is Good Enough Slide 33 Minimum Viable Architecture - Good Enough is Good Enough Slide 34 Minimum Viable Architecture - Good Enough is Good Enough Slide 35 Minimum Viable Architecture - Good Enough is Good Enough Slide 36 Minimum Viable Architecture - Good Enough is Good Enough Slide 37 Minimum Viable Architecture - Good Enough is Good Enough Slide 38 Minimum Viable Architecture - Good Enough is Good Enough Slide 39 Minimum Viable Architecture - Good Enough is Good Enough Slide 40 Minimum Viable Architecture - Good Enough is Good Enough Slide 41 Minimum Viable Architecture - Good Enough is Good Enough Slide 42 Minimum Viable Architecture - Good Enough is Good Enough Slide 43 Minimum Viable Architecture - Good Enough is Good Enough Slide 44 Minimum Viable Architecture - Good Enough is Good Enough Slide 45 Minimum Viable Architecture - Good Enough is Good Enough Slide 46 Minimum Viable Architecture - Good Enough is Good Enough Slide 47 Minimum Viable Architecture - Good Enough is Good Enough Slide 48 Minimum Viable Architecture - Good Enough is Good Enough Slide 49 Minimum Viable Architecture - Good Enough is Good Enough Slide 50
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

5 Likes

Share

Download to read offline

Minimum Viable Architecture - Good Enough is Good Enough

Download to read offline

The “right” architecture and organization depends on the size and scale of your company. The only constant is change, and what works for 5 engineers does not work for 5000. Based upon lessons from Google and eBay, learn how to evolve both technology and organization together successfully.

This presentation is based on many hard-won lessons by the speaker, who led large-scale engineering teams at Google and eBay, but also co-founded a tiny startup and tried (unsuccessfully) to apply the same techniques. This session hopes to help others from making the same mistakes by introducing the concept of “Minimal Viable Architecture”. It outlines the common architectural evolution of a company or project through the search, execution, and scaling phases, and discusses the appropriate technologies, disciplines, and organizational structures at each phase. You'll start with a monolith, and end up with microservices, and that's completely and entirely appropriate.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Minimum Viable Architecture - Good Enough is Good Enough

  1. 1. Minimal Viable Architecture Good Enough is Good Enough Randy Shoup @randyshoup linkedin.com/in/randyshoup
  2. 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. 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. 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. 5. No one starts with microservices … Past a certain scale, everyone ends up with microservices
  6. 6. Getting to rearchitect a system is a sign of success, not failure.
  7. 7. If you don’t end up regretting your early technology decisions, you probably over- engineered.
  8. 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. 9. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/
  10. 10. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ I D E A
  11. 11. What problem are you trying to solve?
  12. 12. “Building the wrong thing is the biggest waste in software development.” -- Mary and Tom Poppendieck, Lean Software Development
  13. 13. “A problem well-stated is a problem half-solved.” -- Charles Kettering, former head of research for General Motors
  14. 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. 15. “Do things that don’t scale” -- Paul Graham
  16. 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. 17. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ One Team 3-6 month horizon
  18. 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. 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. 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. 21. The Monolithic Architecture 2-3 monolithic tiers Presentation Application Database
  22. 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. 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. 24. Assembly, not Construction
  25. 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. 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. 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. 28. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ More and More Teams 6-24 month horizon
  29. 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. 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. 31. Scaling Phase: Scalable Architecture • Scalable persistence • Break up the monolithic database • Functional partitioning • Sharding
  32. 32. Microservices • Single-purpose • Simple, well-defined interface • Modular and independent A C D E B
  33. 33. Microservices • Single-purpose • Simple, well-defined interface • Modular and independent • Isolated persistence (!) A C D E B
  34. 34. Microservices are nothing more than SOA done properly.
  35. 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. 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. 37. “Every service at Google is either deprecated or not ready yet.” -- Google engineering proverb
  38. 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. 39. “Enforcing” Standardization • Encouraged via o Libraries o Support in underlying services o Code reviews o Searchable code
  40. 40. The easiest way to “enforce” a standard practice is with working code.
  41. 41. Rule of Three “Three strikes and you refactor”
  42. 42. “Do you have time to do it twice?” “We don’t have time to do it right!”
  43. 43. The more constrained you are on time or resources, the more important it is to build it right the first time.
  44. 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. 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. 46. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ Fewer Teams 2-5 year horizon
  47. 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. 48. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/
  49. 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. 50. is hiring in NYC, SF, TLV wework.com/careers
  • cpfurquim

    Jun. 17, 2020
  • LuisHerrera199

    Jun. 15, 2020
  • BrunoCsarMachadodeCa

    Jun. 12, 2020
  • olivernautsch

    Oct. 21, 2018
  • SocrateesSamipillai

    Oct. 20, 2018

The “right” architecture and organization depends on the size and scale of your company. The only constant is change, and what works for 5 engineers does not work for 5000. Based upon lessons from Google and eBay, learn how to evolve both technology and organization together successfully. This presentation is based on many hard-won lessons by the speaker, who led large-scale engineering teams at Google and eBay, but also co-founded a tiny startup and tried (unsuccessfully) to apply the same techniques. This session hopes to help others from making the same mistakes by introducing the concept of “Minimal Viable Architecture”. It outlines the common architectural evolution of a company or project through the search, execution, and scaling phases, and discusses the appropriate technologies, disciplines, and organizational structures at each phase. You'll start with a monolith, and end up with microservices, and that's completely and entirely appropriate.

Views

Total views

1,770

On Slideshare

0

From embeds

0

Number of embeds

101

Actions

Downloads

49

Shares

0

Comments

0

Likes

5

×