Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

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.

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

×