• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Architecting for Massive Scalability - St. Louis Day of .NET 2011 - Aug 6, 2011

Architecting for Massive Scalability - St. Louis Day of .NET 2011 - Aug 6, 2011



The Cloud now makes seemingly infinite amounts of computing power accessible to everyone. However, to maximize this power, your applications need to scale. In this session, we will explore patterns ...

The Cloud now makes seemingly infinite amounts of computing power accessible to everyone. However, to maximize this power, your applications need to scale. In this session, we will explore patterns that enable massive scalability. We will examine Brewer’s CAP Theorem and contrast it to the ACID principles that guide traditional LOB applications. And finally, we will explore how to apply these patterns when building applications for the Cloud using Windows Azure.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Architecting for Massive Scalability - St. Louis Day of .NET 2011 - Aug 6, 2011 Architecting for Massive Scalability - St. Louis Day of .NET 2011 - Aug 6, 2011 Presentation Transcript

    • Architecting forMassive ScalabilityEric D. BoydDirector, Chicago + Cloud Practice
    • Introduction Eric D. Boyd 15 Years in Technology
    • I’m From Here
    • I Moved Here
    • I Work Here
    • I Work On
    • I Blog @ ericdboyd.com
    • I Tweet @EricDBoyd
    • Agenda What is Scalability? ACID, BASE & CAP Compute Patterns Data Patterns Q&A
    • What is Scalability? A service is said to be scalable if when we increase the resources in a system, it results in increased performance in a manner proportional to resources added. --Werner Vogels, CTO, Amazon.com
    • What is Scalability? Measures of Performance Response Time Throughput Measures of Scalability Transaction Volume Concurrent Users Size of Data and Growth
    • What can be Scaled? Servers CPU Memory Hard Disk Licensing Network Ports Bandwidth Cooling Power Racks Floor Space
    • Why is Scalability Important? Predictable Growth Unpredictable Growth Design for Scale Benefits of Scalability Dynamic Capacity Planning Cost is Linear
    • Workload Patterns On and Off Growing Fast Compute Compute Inactivity On off Period Average Usage Average Usage Time Time • On & off workloads (e.g. batch job) • Successful services needs to grow/scale • Over provisioned capacity is wasted • Keeping up w/ growth is big IT challenge • Time to market can be cumbersome • Complex lead time for deployment Unpredictable Bursting Predictable Bursting“ Compute Compute Average Usage Average Usage Time Time • Unexpected/unplanned peak in demand • Services with micro seasonality trends • Sudden spike impacts performance • Peaks due to periodic increased demand • Can’t over provision for extreme cases • IT complexity and wasted capacity
    • Traditional Line-of-Business (LOB) Apps A - Atomic C - Consistent I - Isolated D - Durable
    • CAP Theorem Consistency. The client perceives that a set of operations has occurred all at once. Availability. Every operation must terminate in an intended response. Partition tolerance. Operations will complete, even if individual components are unavailable.
    • Brewer’s CAP Theorem Consistency Partition Availability Tolerance
    • BASE Basically Available Soft State Eventually Consistent
    • Eventual Consistency Given a sufficiently long period of time over which no updates are sent, we can expect that during this period, all updates will eventually propagate through the system and all the replicas will be consistent. --Wikipedia, http://en.wikipedia.org/wiki/Eventual_consistency
    • Real-World twitter Facebook eBay Amazon Foursquare
    • Compute Patterns
    • Scale Up
    • Scale Out
    • Why Isn’t this the Norm? Data is typically Bottleneck Designed for and expects ACID Not designed for Scale Out Load is fixed and constant Mind shift and additional work
    • I Need Scalability Loose Coupling Stateless Messaging & SOA Async & Background Processes Queuing Monitoring and Diagnostics
    • Front-End (FE) + Back-End (BE) Model FE BE Persistent Storage
    • Front-End (FE) + Back-End (BE) Architecture (FE) requests (BE) to perform work (BE) completes work (BE) reports results back to (FE)
    • Worker-Queue Model BE Work Queue FE Persistent Storage
    • Worker-Queue Architecture Front-End (FE) loads work in a Queue Back-End (BE) gets work off of Queue Back-End (BE) completes work
    • Job Manager-Worker-Queue Model Request Queue BEFE Work Queue JM Result Queue Persistent Storage
    • Job Manager-Worker-Queue Architecture Front-End (FE) loads work in a Queue Job Manager (JM) breaks up work Job Manager (JM) requests (BE) to do work Back-End (BE) completes work (BE) reports results back to (JM) (JM) aggregates results (JM) reports results to (FE) (JM) Monitors and Manages Resources
    • Data Patterns
    • Local Storage Use Cautiously Stateless Node Affinity
    • Caching Data will be stale Reduce load on Data Store Compute nodes Volatile stores Good use of Local Storage Distributed cache Transformed and denormalized Persistent stores Volatile stores
    • Geographic Distribution Minimize Travel Costs Localize Data Centers CDNs
    • CQRS Command Query Responsibility Segregation More Reads than Writes
    • CQRS Cache Cache Cache BEFE BE Persistent Storage
    • Partitioning Balance load across servers Avoid transactions across partitions Might need to rebalance
    • Vertical Partitioning Functional Partitioning Systems Catalog Customers Vendors Orders Reference Data
    • Vertical Partitioning FE Customers Catalog eCommerce Orders Vendors
    • Horizontal Partitioning (Sharding) Slices of the same functional data Not Relational, No Joins No referential integrity across partitions Constraints are moved to the application Partitioning Strategy Name, Geography, Date, etc. Application needs to be partition-aware One logical DB, multiple physical partitions Rebalance Scales for both reads and writes
    • Horizontal Partitioning (Sharding) FE Eastern Central Customers Mountain Pacific
    • Relational vs. Non-Relational (NoSQL) Relational Non-RelationalNormalization Normalized DenormalizedDuplication Avoided EmbracedTransactions Distributed Scoped to PartitionStructure Schema Schema-less, JaggedResponsibility Database ApplicationScalability Vertical or Sharded Horizontal
    • Takeaways Design for Scale Scale Compute Out Decouple Processing Async Scale Data CAP & BASE over ACID Partition
    • Resources Brewers Keynote on CAP http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf CAP articles: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem http://www.allthingsdistributed.com/2008/12/eventually_consistent.html BASE Articles http://queue.acm.org/detail.cfm?id=1394128 High Scalability http://highscalability.com Werner Vogels, CTO of Amazon http://www.allthingsdistributed.com/
    • Other Sessions Exploring Scalability and Roles Insight, Next Session, Mike Benkovich Making $$$ with Windows Phone Imagination C/D, 3:00PM-4:00PM
    • Q&A
    • http://www.AzureStudyGroup.com
    • Thank You!Eric D. BoydDirector, Chicago + Cloud PracticeCentareEmail: eric.boyd@centare.comTwitter: www.twitter.com/EricDBoydBlog: www.ericdboyd.com