BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Parse Got a Tenfold Reliability Improvement Moving from Ruby to Go

| by Sergio De Simone Follow 5 Followers on Jun 19, 2015. Estimated reading time: 2 minutes |

In order to improve scalability, Parse moved part of their services, including their API, from Ruby on Rails to Go, Charity Majors, Engineer at Parse, recounts. In doing so, both their reliability and deployment times benefited greatly.

Parse started in 2011 as a Ruby on Rails project. This choice made it possible for a small group of engineers to implement the first version of Parse quickly, says Majors. However, as Parse grew, their architecture started showing a few inconveniences:

  • the growth in Parse code base made deployments, and rollbacks, lengthy; furthermore their HTTP server, Unicorn, stopped restarting gracefully. The end effect was more and more monkeypatching.
  • Rails’ “one process per request” model started to “fall apart” when the API traffic and number of apps grew. In fact, Rails worker pool easily filled up when many slow request came in, due to auto-scaling the worker pool size not being fast enough. It also happened that many of those workers were mostly just waiting on some external services.

Those issues led Parse engineers to realize they needed to move to a real async model, thus leaving behind Rails’ “one process per request” model. Since Ruby was not deemed fit for the task due to the vast majority of gems not being asynchronous and many times not thread safe either, they set up to choose a different language. The alternatives they took into considerations were the following:

  • JRuby, which was ruled out because, although the JVM is able to handle massive concurrency, Ruby still would have the problem of asynchronous library support.
  • C++, which was ruled out due to its being less productive than other languages and lacking of library support for things like HTTP request handling, or async operations.
  • C#, which was deemed a very good option for its async/await async model, but ruled out because “C# development on Linux always felt like a second-class citizen”.
  • Go, finally, was considered the best available option thanks to its native support for asynchronous operation, best-in-class support for MongoDB, and coroutines.

Parse engineer sort of tested out their choice by implementing their EventMachine in Go. The result was going from 250k connections per node to 1.5 millions. From there, they went on rewriting their services one by one, including the core API, all the while guaranteeing backward compatibility.

At the end of the process, the results were worth the effort, according to Majors:

  • Parse “reliability improved by an order of magnitude”.
  • The API stopped becoming more and more fragile with the number of spun up databases.
  • The time taken by the full integration test suite dropped from 25 to 2 minutes.
  • Full API server deploy dropped from 30 to 3 minutes.
  • The API server can finally be restarted gracefully.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

EventMachine and threadsafe? by Lionel Bouton

I'm not sure why they view lack of thread safety as a problem when they choose an event-based concurrency model which does not require thread safety.

Java? by Igor Kolomiets

Would interesting to know why not Java (since they did evaluate C#).

Re: Java? by Vadzim Dombrovsky

I think I know the answer. All these languages they considered fall into "write less, do more" category. Java on the other hand is not so expressive. You need to write (and maintain) far more lines of code than you would in Ruby, for example. Even C# being a "Java" class language has so many features, like delegates, extension methods, reified generics, properties, async/await, etc.

P.S. if you need to use java for your next project, you should consider using Kotlin instead, it is a JVM language, 100% compatible with java (you can have both java and kotlin source files in the same project), and has a small runtime (300kb). It has most of the features missing from java. for example lambdas from kotlin work even on Java 6! I'm using it for android development and it makes my life so much easier. The only dowside is that kotlin is not released yet, so things are changing from time to time.

Why not handing over long requests to workers? by Atul Jain

There are other design options to solve this problem. One can design the API(s) to be always fast. Any long operations are handled by workers and API returns 202 instead of 200. Client then needs to either do polling or a notification based system is used. That will obviate the need where the client facing threads/processes are blocked on long request. Not sure whether this alternative was explored before moving from Ruby to Go.

Why not handing over long requests to workers? by Atul Jain

There are other design options to solve this problem. One can design the API(s) to be always fast. Any long operations are handled by workers and API returns 202 instead of 200. Client then needs to either do polling or a notification based system is used. That will obviate the need where the client facing threads/processes are blocked on long request. Not sure whether this alternative was explored before moving from Ruby to Go.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT