Ruby at Wimdu - a long relationship

I will always remember my first eurucamp fondly. It was 2012, and I had just made the decision to switch to Ruby in my professional career. I was amazed by how friendly everyone was, even though I was a newbie in the Ruby world. Moreover, the whole conference setup felt almost like a family event. I remember going on a bike ride during the mid-day break and chatting with a developer from Songkick about their foray into breaking a Rails monolith into services. It was a perfect start into my Ruby journey.

Now, 3 years later, I am in the fortunate position to work as CTO for Wimdu, and our company is one of the sponsors of the conference. It feels like a nice way of giving something back.

At Wimdu, we are on a journey too. Over the past few years, we have built one of the largest Rails applications in Europe (or so I’m told). Often people are incredulous – do you really serve all these visits with “just” a Rails app? Yes. Actually, it’s holding up fairly well in production, even though it’s not that optimized. We host everything on Rackspace, and we scale the application horizontally as needed. With this setup, we currently serve about 200-300 requests per second. What about the database? To be honest, we basically just keep our fingers crossed…

We are now at a point though that many companies have found themselves at in the past two or three years: our Rails monolith, which served us well in the beginning, is now so big that it is holding us back. It doesn’t fit into one head anymore. If you want to make a small change, you will always need to deploy the big mothership. And everything is entangled anyway. So last year we realized it was time for a change, and the direction became clear quite soon: it would be best for us to break the monolith apart into small services. So we hopped onto the microservices hype train.

After many discussions, we are now finally underway. We have built the first pieces of the infrastructure puzzle - a “real" microservice, wrapped in a docker container, deployed on Amazon AWS. We added observers to our main app that send changes on certain models to a RabbitMQ message bus, which are then picked up by any interested consumer services. We are migrating our whole infrastructure to AWS, which feels liberating. This setup will give us the flexibility and horsepower to automate and streamline the whole application delivery pipeline, which is a basic prerequisite for a successful microservices setup. We understand that for a distributed architecture like this, you have to pay a hefty initial price, and considering the size of our platform and team, we are willing to pay it. It will pay off over time.

Everyone in our IT and Product team is excited about the challenges ahead. We continue to build an IT organization that is decentralized and built on lean and agile principles, which will fit neatly with the architecture we are envisioning. Migrating to a microservices architecture will allow us to give more autonomy to the teams. We also decided to invest further into our team, and grow it substantially. If you want to be part of this challenge, you can expect interesting technical problems to work on, flat hierarchies and a great engineering culture. We’ll be glad to hear from you!