Get the latest tech news

Ten Years and Counting: My Affair with Microservices

In early 2024, I hit ten years at Allegro, which also happens to be how long I’ve been working with microservices. This timespan also roughly corresponds to how long the company as a whole has been using them, so I think it’s a good time to outline the story of project Rubicon: a very ambitious gamble which completely changed how we work and what our software is like. The idea probably seemed rather extreme at the time, yet I am certain that without this change, Allegro would not be where it is today, or perhaps would not be there at all.

The codebase was a monolithic PHP application, with some auxiliary processes written in C. Checked out, the git monorepo weighed about 2 GB, and the number of pull requests produced daily by a few hundred developers was so large that if you started a new branch in the morning, you were almost sure to get some conflicts if you wanted to merge in the afternoon. various self-service tools allowing developers to handle common tasks such as creating databases themselves rather than by involving specialized support teams automation tools development of Hermes, our open-source message broker built on top of Kafka, started strategic DDD training with Eric Evans migration to Java 8 global architecture improvements allegro.tech, the project to coordinate the visibility of our tech division online and offline, of which this blog is a part, started SRE team created CQK (Code Quality Keepers) guild opened first Java services deployed to production intense recruitment and learning I think much of the anti-microservice sentiment you see around the internet today stems from treating microservices as a silver bullet that you can apply to any problem regardless of whether they actually make sense in given situation, or from not being aware that they can bring huge payoffs but also require great investments.

Get the Android app