Building services and integrating them into Rails is hard. Often times we talk about how nice it would be if our Rails apps were smaller and we had nicely encapsulated services. And it would be, but services introduce complexity. If you build your application this way from the beginning, you're going to do extra work and probably get some of it wrong. If you wait too long, you've got a mess on your hands.
At Yammer, we work constantly to clean up the mess that worked well in the early days, but has become troublesome to maintain, scale, or handle lots of data. We're tasked with pulling things out of the core Rails app, standing them up on their own, and making sure they do what they do really well and really fast.
With over 20 services now running in production, we've learned some lessons along the way. Services that seem clean and simple in the beginning can turn into development environment nightmares. Temporary data double-dispatching solutions turn into duplication and developer confusion. Monitoring one app turns into monitoring a suite of apps and handling failure between them. This talk is a look into the tradeoffs, mistakes, and solutions that we deal with every day and how we're able to maintain velocity given the additional complexity.
At the end of the day, having services and a smaller Rails codebase makes for scalable development teams, happier engineers, and smoother and more predictable production environments. Getting there is full of tradeoffs and hard decisions -- sometimes we do it right, sometimes we fuck it up, but we usually have a story to tell.