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 Square pre-Minecart.
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 team.
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.