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.

Minimum Viable Architecture -- Good Enough is Good Enough in a Startup

13,714 views

Published on

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.

Published in: Technology

Minimum Viable Architecture -- Good Enough is Good Enough in a Startup

  1. 1. Good Enough is Good Enough “Minimal Viable Architecture” in a Startup Randy Shoup @randyshoup linkedin.com/in/randyshoup
  2. 2. http://xkcd.com/974/
  3. 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. 4. Phases of a Startup • Search Phase • Execution Phase • Scaling Phase
  5. 5. Phases of a Startup • Search Phase • Execution Phase • Scaling Phase
  6. 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
  7. 7. “Do things that don’t scale” -- Paul Graham
  8. 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. 9. Phases of a Startup • Search Phase • Execution Phase • Scaling Phase
  10. 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. 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. 12. Execution Phase: “Just Enough” Architecture • Familiar Technology • Ease of Use • Expressive Power • Simple (!) • Monolithic Architecture • Single database • Minimal Infrastructure • PaaS over IaaS
  13. 13. The Monolithic Architecture 2-3 monolithic tiers • {JS, iOS, Android} • {PHP, Ruby, Python} • {MySQL, Mongo} Presentation Application Database
  14. 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. 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. 16. Phases of a Startup • Search Phase • Execution Phase • Scaling Phase
  17. 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. 18. “If you don’t end up regretting your early technology decisions, you probably over-engineered” -- me
  19. 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. 20. Scaling Phase: Change Incrementally • Find your worst scaling bottleneck • Wall it off behind an interface • Replace it • Rinse and Repeat
  21. 21. You’re In Good Company • 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

×