Feb 212013
 

Update (3/31/13): The video of the talk is online: High Availability at Braintree

The slides from my RubyConf Australia talk are now online: High Availability at Braintree.

The slides were generated using showoff.

  6 Responses to “High Availability at Braintree”

  1. Thanks for the very good presentation last night. I learned couple of new things. I have one question which I could not ask last night.

    1) Do you prefer NoSQL datastore over PostgresSQL to completely avoid schema change restrictions or do you have any specific requirements which are not suitable to use NoSQL Datastore at Braintree?

    • It’s hard to talk about NoSQL data stores as a whole since there are so many different ones. For example, some are eventually consistent, which require a different way of writing code.

      None truly remove schema change problems, however. For example, if we want to rename a key in our documents, we still have to migrate all of the existing documents. In these cases, a SQL database like PostgreSQL makes this operation much faster since we can rename a column without updating documents individually.

      We’ve evaluated and used a lot of different data stores at Braintree. Overall, we feel like PostgreSQL gives us the right mix of developer productivity and operational stability.

  2. Ref the talk last week, I must say I found some approaches that were discussed unorthodox and a violation of best practices.

    For example running different binaries on different hosts on a farm is not repeatable and has the potential to cause trouble. Given that protocols in payments applications do not change dramatically with releases, I am not sure why releases can not be completely simulated in a staging environment. In my experience, most shops release using rolling restarts.


    Ashok Misra, CISSP, CPISM/A, epaymentsNut
    Alina Consultants Inc
    http://www.linkedin.com/in/paymentsnut

    • It is not our normal practice to run multiple versions of the code for long periods of time. There are multiple versions running during rolling restarts, but these periods generally last for only a few minutes. There is definitely a risk with this process, but we think the lack of downtime outweighs it.

      • Another approach would be to bring up an entirely new stack and do a DNS (or perhaps something at a lower level in the stack) switch to point to the new stack.

        I think that’s how companies like Netflix and Twilio deploy.

  3. [...] JRuby, there are many applicable lessons that MRI may adopt to bring speed to multiple Ruby VMs. A behind the scenes look at Braintree’s application stack from Paul Gross demonstrated the power of a polyglot [...]

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">