joeya

I suggest: (1) choose a tool/language/library you want to learn, (2) work through a use case and write a blog post about it to help the next person do the same, (3) consider how the README or docs should be updated accordingly.

Writing up your experience is often a useful trigger to create an open-source tool/library or modify an existing one. It forces you to consider how your own experience can be made useful for others.

Also read the source of tools/libraries you use. Often, gaps or modifications jump out readily.

SQL would certainly have been an adequate solution for this. In our case (I work at Artsy and contributed to the code described in the post), our environment relies primarily on MongoDB already.

I think the work is interesting precisely because it achieves some of the benefits of transactional systems using a data store that isn't usually considered for these purposes. Immutable documents and serializing the processing of bids (to limit concurrent access), as described in the post, helped.

Hey mnutt, I agree--it's a nice model. Scalarium was building such a product, but Amazon bought them and made it OpsWorks :)

They were originally using an older version, but Chef 11 is now supported. I believe it's the default for new stacks, and old ones can be updated from the stack settings page.

http://aws.amazon.com/about-aws/whats-new/2013/07/24/aws-ops...

Thanks for the kind words! To be honest, I have to agree with you about the text color. Will fix.

I've heard a little about Ansible but look forward to learning more. I'm in awe that you took the time to get up to speed on each of those tools. Some of the learning curves are... intimidating.

For what it's worth, I actually found OpsWorks' usage of Chef to be more intuitive than Opscode's own. OpsWorks relies on "events" (setup, deploy, shutdown, etc.) that trigger (i.e., push) recipes to be applied to instances. Opscode, at least in its typical architecture, relies on clients pulling configuration from a Chef server at a regular interval.

I can confirm this. We experimented with Unicorn as a way to get some of the benefits of availability-based routing despite Heroku's random routing. Our medium-sized app (occupying ~230 MB on boot) would quickly exceed Heroku's 512 MB memory limit when forking just 2 unicorn workers, so we had to revert to thin and a greater number of dynos.

This is also interesting for sites which can't acquire their own certificates (i.e., anything at .cu, .ir, .kp, .sd, and .sy).