7 Stages of Scaling Web Applications

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

4 comments

Comments 1 - 4 of 4 previous next Post a comment

  • + praba_tuty praba_tuty 1 month ago
    For database caching , refer

    http://www.csqldb.com
  • + joy4you joy4you 2 years ago
    If I could read it earlier when I was in stage 1,2,3, that will be more help... Nice pitch.
  • + jboutelle Jonathan Boutelle 2 years ago
    This was REALLY awesome presentation. Nice work!
  • + guest37071d guest37071d 2 years ago
    great presentation short and sweet. any references for further reading on stage 5, 6, 7
Post a comment
Embed Video
Edit your comment Cancel

89 Favorites & 1 Group

7 Stages of Scaling Web Applications - Presentation Transcript

  1. The 7 Stages of Scaling Web Apps: Strategies for Architects John Engates CTO, Rackspace Presented: LinuxWorld Conference & Expo, San Francisco August 6, 2008
  2. Agenda
    • Desirable Properties in a Web App
    • Typical Growth Scenario
    • Best practices
    • Q & A
  3. Desirable Properties of a Web App
    • Scalability
    • High Availability
    • Performance
    • Manageability
    • Low Cost
    • Feature Rich
    • Generates $$$
  4. High Availability Defined
    • High Availability (HA) is a design and implementation that ensures a certain degree of operational continuity.
    • In other words…
      • The site is up
      • The users are happy
      • The business is not losing money due to outages
      • (And the system doesn’t cost more than it’s worth)
  5. Scalability Defined
    • What scalability is:
      • Scalability is a desirable property of a system which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged as demands increase.
    • What scalability is not :
      • Raw speed or performance (2 GHz vs. 3 Ghz)
      • About the operating system (Solaris vs. Linux)
      • About a particular software technology (Java vs. Python vs. Rails)
      • About a particular hardware platform (AMD vs. Intel)
      • About optimized code (10 lines of code vs. 1000)
      • About storage technology (SAN vs. NAS)
  6. PERFORMANCE AND SCALABILITY ARE NOT THE SAME…
  7. Performance
  8. Scalability
  9.  
  10. Performance
  11. Scalability
  12. More Scalability
  13. Truth #1
    • It won’t scale if it’s not designed to scale.
  14. Truth #2
    • Even if it’s designed to scale, there’s going to be pain!
  15. Pain Scale Back
  16. Typical Growth Scenario
    • Stage 1 – The Beginning
    • Simple architecture
      • Firewall and load balancer
      • A pair of web servers
      • Database server
      • Internal storage
    • Low complexity and overhead means quick development and lots of features, fast
    • No redundancy, low operational cost – great for startups
  17. Typical Growth Scenario
    • Stage 2 – More of the same, just bigger
    • Business is becoming successful – risk tolerance low
    • Add redundant firewalls, load balancers
    • Add more web servers for performance
    • Scale up the database and optimize with DBA help
    • Add database redundancy
    • Database storage moves to SAN or DAS
    • Still relatively simple from an application perspective
  18. Typical Growth Scenario
    • Stage 3 – The Pain Begins
    • Publicity hits (Digg, Slashdot)
    • Squid or Varnish reverse proxy, or high end load balancers – to cache static content
    • Add even more web servers
      • Managing content becomes painful
    • Single database can’t cut it anymore
      • Split reads and writes - all writes go to a single master server with read-only slaves
    • May require some re-coding of the app
  19. Scaling Through Database Replication
  20. Typical Growth Scenario
    • Stage 4 – The Pain Intensifies
    • Caching with memcached
    • Replication doesn’t work for everything
      • Single “writes” database - Too many writes - Replication takes too long
    • Database partitioning starts to make sense
      • Certain features get their own database
    • Shared storage makes sense for content
    • Requires significant re-architecting of the app and DB
      • Devs may not have done this stuff before
  21. Typical Growth Scenario
    • Stage 5 – This Really Hurts!
    • Panic sets in. Hasn’t anyone done this before?
      • Re-thinking entire application / business model
      • Why didn’t we architect this thing for scale?
    • Can’t just partition on features – what else can we use?
      • Partitioning based on geography, last name, user ID, etc
      • Create user-clusters
    • All features available on each user-cluster
    • Use a hashing scheme or master DB for locating which user belongs to which cluster
  22. Typical Growth Scenario
    • Stage 6 – Getting (a little) less painful
    • Scalable application and database architecture
    • Acceptable performance
    • Starting to add new features again
    • Optimizing some of the code
    • Still growing, but it’s manageable
  23. Typical Growth Scenario
    • Stage 7 – Entering the unknown…
    • Where are the remaining bottlenecks?
      • Power, Space
      • Bandwidth, CDN, Hosting provider big enough?
      • Firewall, Load balancer bottlenecks
      • Storage
      • People and process
      • Database technology limits – scalable, key-value store anyone?
    • All eggs in one basket?
      • Single datacenter
      • Single instance of the data
      • Difficult to replicate data and load balance geographically
  24. Good Practices
    • Don’t re-invent the wheel, copy someone else
    • Think Simplicity
      • Everything should be made as simple as possible -- but not simpler. A. Einstein
    • Think horizontal…not vertical…on everything
      • “ How many?” vs. “how fast?”
    • Use commodity equipment
    • Make troubleshooting easy
      • Design for operation
      • Isolate services
      • Don’t change lots of things at once
  25. More good practices…
    • Don’t spend your time over-optimizing
      • Get your architecture right, adjust often, optimize later (or never)
    • Test your ability to scale with appropriate load testing
      • Get a baseline before you think you need it
    • Use caching wherever it makes sense
    • Lots of memory and 64-bit architecture helps
    • Evaluate every feature vs. performance/scalability impact
      • Nice to have vs. have to have
  26. Managing Change Protects Availability
    • Don’t underestimate the need for process and documentation
    • Release Management
      • Develop – Test – Release
      • Procedures in place to support these activities
    • Source Control
      • RCS, CVS, Subversion
    • Issue Tracking
    • Coding Standards
    • Change Management
      • Plan – Test – Implement
      • Critical for high availability infrastructure
    • Cloud Computing …
    • The Future?
  27. Questions?
    • jengates “at” rackspace.com
  28. http://racklabs.com
  29. Help Wanted!

+ David MitzenmacherDavid Mitzenmacher, 2 years ago

custom

19916 views, 89 favs, 30 embeds more stats

Slides from LinuxWorld presentation by John Engates more

More info about this document

© All Rights Reserved

Go to text version

  • Total Views 19916
    • 18539 on SlideShare
    • 1377 from embeds
  • Comments 4
  • Favorites 89
  • Downloads 1
Most viewed embeds
  • 684 views on http://www.rackspace.com
  • 241 views on http://www.webyantra.net
  • 228 views on http://www.profyclub.org
  • 41 views on http://www.i-knowledge.ru
  • 38 views on http://hi-load.social.php.com.ua

more

All embeds
  • 684 views on http://www.rackspace.com
  • 241 views on http://www.webyantra.net
  • 228 views on http://www.profyclub.org
  • 41 views on http://www.i-knowledge.ru
  • 38 views on http://hi-load.social.php.com.ua
  • 31 views on http://www.saasburst.com
  • 22 views on http://www.cnblogs.com
  • 19 views on http://hi-load.php.com.ua
  • 15 views on http://yekmer.blogspot.com
  • 10 views on http://boand.ru
  • 8 views on http://social.php.com.ua
  • 8 views on http://wiki
  • 6 views on http://profyclub.org
  • 5 views on http://www.techiegyan.com
  • 3 views on http://php.com.ua
  • 2 views on https://bmx.updatelog.com
  • 2 views on http://www.jasonslater.co.uk
  • 2 views on http://newbrand.ejohnson.dev.marketing.rackspace.com
  • 1 views on http://1378907655.nvmodules.netvibes.com
  • 1 views on http://www.slideshow.com
  • 1 views on http://wildfire.gigya.com
  • 1 views on http://static.slidesharecdn.com
  • 1 views on http://developmant.alpacom.ru
  • 1 views on http://www.diolan.demo.alpacom.ru
  • 1 views on http://203.208.35.101
  • 1 views on http://tumblr.iamdanw.com
  • 1 views on http://devportal.com
  • 1 views on http://74.125.113.104
  • 1 views on http://redmine.ntis.us.to
  • 1 views on http://surf.googlemashups.com

less

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint
Having problems? Go to our helpdesk?

Categories