This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

QCon SF 2009: Adam Wiggins, Architecting for the Cloud: Horizontal Scalability via Transient, Shardable, Share-Nothing Resources

Stefan Tilkov,

These are my unedited notes from Adam Wiggins's talk about Architecting for the Cloud: Horizontal Scalability via Transient, Shardable, Share-Nothing Resources at QCon SF 2009

  • Heroku is a platform to transparently run existing Ruby and Ruby on Rails applications in the cloud
  • Heroku has over 40,000 applications, not bad for a startup with 50 guys
  • Automatically scaling applications without code changes "scale my app" slider
  • A lot of it due to enabling factors - virtualization as a service
  • Moore's law at an end – buying a larger box is no longer a good answer
  • Scaling out instead scaling up
  • First ingredient: Shardable resources
  • Resource examples: Database, Caching, HTTP Router, Message Bus
  • Making these resources horizontally scalable means making the app scalable without changing it
  • memcached – the father of all modern shardable resources
  • Hashtable in the sky
  • memcached built by the LiveJournal guys - one of the first big Web properties
  • Facebook runs 800 memcached servers supplying 28 TB of memory - all of these appear as one resource to the application
  • Why is it easy to scale out memcached so widely while one can't do that with MySQL?
  • Principles: Transient, Shardable, Share-nothing
  • Transient: any node in the memcached cluster can be lost
  • Shardable: Client lookup by "hashring": load distributed by clients
  • Share nothing: Nodes are unware of each other
  • Is memcached cheating? after all it doesn't really have any state
  • No - the same approach can be applied to any type of resource
  • CouchDB: document database with eventual consistency
  • Multiversion concurrency control instead of locking - comparable to a distributed source control system
  • CouchDB is a transient, shardable, share-nothing DB
  • http://books.couchdb.org/relax/ - free copy of the book draft available, recommended as a description of the new kind of architecture
  • Next example: Hadoop. Flightcaster, Heroku customer, does massive processing using Hadoop
  • Redis - basically memcached with persistence; shards with hashring; lists and sets; extremely fast and lightweight
  • Varnish - like Squid, but horizontally scalable; combine with ngx_http_upstream_consistent_hash for hashring-style access
  • Each varnish node only holds parts of the cached data; hashring approach ensures correct server is hit
  • RabbitMQ, basically thrown in because he likes it so much - cross-language messaging bus
  • Erlang is used quite a bit at Heroku: Erlang is share-nothing - high concurrency, no mutable variables (in other words: your variables don't vary), lightweight processes
  • Erlang used for information exchange and routers - Principles such as shared-nothing, transient, shardable built in to the language

  • Horizontal scalability promises to shatter the ceiling of scalability - but only if we architect resources to be shardable, transient, share-nothing

  • Q. Cassandra? A. Hasn't looked into it, but seems to be well-aligned with these ideas.

  • Q. Experience in scaling SQL databases? A. Do this the same everybody else does, but there's a lot of pain because it doesn't fit the cloud. Desaster recovery is one of the major challenges with a SQL DB, much harder than with the new DB models
  • Q. How easy is it to backup CouchDB to another data center? A. It's so easy that it's almost laughable, CouchDB simply uses HTTP. Latest version of Ubuntu ships with CouchDB to replicate address book and other data between machines [See, just like Lotus Notes ;-)]
  • Q. Details about "slider for scaling"? A. Very quick way to control the number of processes for Web requests and workers; frees you from having to decide whether to put more processes on the existing boxes or add new ones.
  • Q. Any downsides to a document database? A. SQL databases are great at ad-hoc queries, not something document DBs are very good at. SQL is a functional programming language [ed. Only as long as you only talk about SELECT …]