Moving SoundCloud into a microservices architecture has been crucial in enabling our teams to build new features faster, Phil Calçado writes in a three-part series sharing their experiences moving away from a monolithic system.
SoundCloud, an online audio distribution platform where Phil is Director of Engineering, was created as a single Ruby on Rails application, but over time patching the system instead of resolving the scalability problem made them decide to fundamentally change their way of building products. The first step was the architecture and a decision to move to a microservices architecture. Due to earlier bad experiences of big-bang refactoring they went for an approach of not adding anything new to the old system, instead building new features as microservices.
A problem that soon arose was that due to so much of the logic remaining in the old system, most of the new services still had to communicate with it. A solution for this was to use the public API together with a new internal API, which also helped them keep all new microservices decoupled from the old system.
After the architectural changes were made, the next challenge was extracting features from the old application. The concept of bounded context from Domain-Driven Design (DDD) was chosen to define well-contained feature sets. Avoiding big-bang refactorings required that for each feature set extracted, the new microservice needed to work with the old system for as long as it took to completely move the logic. During the transition the new service was accessing the old database which meant that only the read-path could be implemented until the service was fully functional. By applying these principles the teams have been able to extract most existing features from the old system moving them into microservices.
Based on their own preferences they decided to stay with the JVM platform and the different languages available. When looking into frameworks to meet their requirements for RPC, resilience, and concurrency they settled on using Finagle, a protocol-agnostic RPC system, after investing time to address some minor issues.
Based on experiences of their work, Phil summarises by stating that the new microservice architecture has proven itself crucial for developing production-ready features with much shorter feedback cycles.
Phil’s ambition is to complete his series by describing how they are using Finagle and Scala to move from a single RESTful API to optimized back-ends.