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.

of

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

3 Likes

Share

Download to read offline

Minimal Viable Architecture - Silicon Slopes 2020

Download to read offline

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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Minimal Viable Architecture - Silicon Slopes 2020

  1. 1. Minimal Viable Architecture Randy Shoup @randyshoup
  2. 2. Background @randyshoup
  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]” @randyshoup
  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 @randyshoup
  6. 6. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/@randyshoup
  7. 7. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ I D E A @randyshoup
  8. 8. What problem are you trying to solve? @randyshoup
  9. 9. “There is nothing so useless as doing efficiently that which should not be done at all.” @randyshoup -- Peter Drucker
  10. 10. “A problem well-stated is a problem half-solved.” -- Charles Kettering, head of research at GM @randyshoup
  11. 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. 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. 13. Engineering is about solving problems. Sometimes we solve those problems by writing code. @randyshoup
  14. 14. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ One Team 3-6 month horizon @randyshoup
  15. 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. 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. 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. 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. 19. Monolithic Architecture 2-3 monolithic tiers Presentation Application Database@randyshoup
  20. 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. 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. 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. 23. Assembly, not Construction
  24. 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. 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. 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. 27. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ More and More Teams 6-24 month horizon @randyshoup
  28. 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. 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. 30. Scalable Architecture • Goal: Stay ahead of rapidly growing business. Keep the site up (!) • Scaling the Teams • Scaling the Technology • Repeatable Processes @randyshoup
  31. 31. Many Two-Pizza Teams Idea Development Quality Operations Idea Development Quality Operations Idea Development Quality Operations
  32. 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. 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. 34. Scalable Architecture • Scalable persistence • Break up the monolithic database • Publish-subscribe event system • Use events to communicate between applications and services @randyshoup
  35. 35. Microservices • Single-purpose • Simple, well-defined interface • Modular and independent A C D E B @randyshoup
  36. 36. Microservices • Single-purpose • Simple, well-defined interface • Modular and independent • Isolated persistence (!) A C D E B @randyshoup
  37. 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. 38. Getting to rearchitect a system is a sign of success, not failure. @randyshoup
  39. 39. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/ Fewer Teams 2-5 year horizon @randyshoup
  40. 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. 41. STARTING SCALING OPTIMIZING https://ittybiz.com/s-curve/@randyshoup
  42. 42. If you don’t end up regretting your early technology decisions, you probably over- engineered. @randyshoup
  43. 43. Thank you! @randyshoup linkedin.com/in/randyshoup medium.com/@randyshoup
  • whilpert

    Jun. 9, 2020
  • SergeyPolischouck

    Mar. 28, 2020
  • kikicarbonell

    Feb. 4, 2020

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.

Views

Total views

1,164

On Slideshare

0

From embeds

0

Number of embeds

45

Actions

Downloads

32

Shares

0

Comments

0

Likes

3

×