JRuby at Square
Recently we internally launched Minecart, a project that deeply ties Ruby
applications into our Java service infrastructure. To accomplish this we had
to dive into the bowels of JRuby. My hope is to share many of our learnings
along with a couple of practical examples and pitfalls. For purposes of this
post I will set the stage and talk a little bit about the state of the world at
Like many modern startups, Square's platform started off as a single Rails app.
Over time, that app grew into a monolith, and it became hard to have so many
engineers working together in the same codebase with such a stringent SLA.
Though there are many ways to solve this problem, we took the path of
segmenting our monolith into a service oriented architecture. We split
services out by both availability requirements and ownership of data.
Java ended up being the language of choice for new services. I believe this
happened for two main reasons. First, most of the team who had experience
migrating to an SOA were comfortable in Java. Second, our tools for deploying
and monitoring Java services matured after the formation of our core services
Our core services team did a wonderful job of making Java service development
painless. Java services gained many advanced features: discoverable unified
APIs, service-to-service request chaining, standardized logging, and automated
monitoring dashboards. But whenever a Java service had to integrate with a
Ruby one, or a Ruby service had to integrate with a Java one, developers had to
do custom work to bridge the gap. So, I started wondering if was it possible
to build Ruby on top of our Java infrastructure in a way that could still
utilize all of the same technologies a Ruby developer was familiar with.
After a hack week project which demoed Sequel running on top of Hibernate, I
decided to shoot for the moon. I wanted teams at Square to be able to pick the
language in which they felt most likely to succeed. I wanted a culture where
anyone could convince a few of their peers of an idea, build it, and show it.
And where those ideas, as they took hold, could continue to grow seamlessly
into full-fledged production services with known and consistent maintenance
costs. So, I took some time to develop Minecart, and holy crap, it's working.
We already have 2 production Ruby services running on our Java infrastructure,
and several more are in the pipeline.
I learned a lot, but there's still much I don't know. The JRuby community has
already shared tons of cool stuff, though building that last 10% for our custom
use cases was often painful. Over the next few weeks, my colleagues and I will
share as much as possible to hopefully light some of the path for the next
traveler. We'll kick off the technical posts tomorrow with JRuby and Guice.