public
Created

Speaker Notes for my presentation at Atlanta Riak meetup: Slides - https://speakerdeck.com/lusis/why-riak-matters

  • Download Gist
why-riak-matters-notes.md
Markdown

Disclaimers and Disclosures

  • Basho fanboy
  • Basho customer
  • enStratius product uses Riak
  • thus all customers run Riak as part of install
  • I am far from a subject matter expert

What this is not about

  • Running Riak in production
  • Riak itself
  • Riak administration or tuning

What even is a "distributed system"?

Fallacies of Distributed Computing

  • The network is reliable. (partition tolerance)
  • Latency is zero. (eventual consistency)
  • Bandwidth is infinite. (max node count)
  • The network is secure. (riak provides SSL)
  • Topology doesn't change.
  • There is one administrator.
  • Transport cost is zero.
  • The network is homogeneous

logo

  • quick note about the logo
  • cribbed from Justin Sheehey's Velocity talk
  • Each dot contains the same diagram
  • a distributed system within your distributed system

Riak is honest about its limitations

  • and embraces them
  • read the mailing list
  • read basho blog posts

Riak forces you to think about your data model

  • Do you really need a relational model? 5th normal form? Really?
  • What is your native format anyway?
  • Can you loosen your consistency requirements?

Riak is about tradeoffs

  • Querying is a pain in the ass (Riak+Redis)
  • Read any Boundary blog post
  • Read any mailing list post
  • Riak let's you choose (tunable CAP, multiple backends)
  • Riak doesn't try to be something it isn't

Riak is in Erlang (wat)

  • Erlang isn't perfect. There are shitty Erlang apps.
  • Alan Kay/Smalltalk/Message Passing
  • Actor Pattern
  • Let It Crash
  • Basho contributes back to the Erlang ecosystem to make it more approachable (rebar, lager, webmachine)

What can we learn?

  • Revisit the fallacies
  • Revisit CAP
  • Embrace failure
  • Fault Tolerance vs. Fault Prevention
  • Your entire stack doesn't have the same requirements (strict consistency vs. weak consistency)
  • Easy to reason about. (which is easier - let it crash or some complicated recovery scenario?)
  • Network partitions happen.
  • Be careful with clever
  • Each additional component risks unnecessary additional complexity and reduces reasonability

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.