SoundCloud's Shift to Microservices Sped Delivery
For streaming platform SoundCloud, switching from SOA to microservice architecture paid off in greater speed and productivity.
In 2014, the popular music and podcast streaming platform SoundCloud was a victim of its own success. At the time, users were uploading 12 hours of music to the Berlin-based service every minute, with hundreds of thousands of visitors consuming audio from the platform daily. Not only did SoundCloud face major scaling issues, it was also confronted with lengthy delays when implementing new features.
The root of these problems could be traced back to the mid-‘90s, when service-oriented architecture (SOA)—an architectural style that lets various application components share services over the network—became the hot trend in programming. The design style allowed some of the earliest web-based services to operate, and it made cross-departmental and inter-company technical integration possible.
In the decades since its heyday, however, use of SOA has declined as criticism of the design style has mounted—namely, assertions that overhead can be high and performance sluggish. In response, programmers increasingly have turned to microservices as an alternative architectural approach. The idea: Break a service down into smaller components, splitting up applications into pieces that can be more easily distributed and replicated. Critically, microservice architecture allows for continuous delivery and deployment, as the smaller components can be more easily, and thus more frequently, updated.
New Architecture for a New Era
SoundCloud began its switch to microservices in 2014, and its developers meticulously documented the labor-intensive process of converting its monolithic architecture to the new format.
“At the time, we were organized with front-end teams working on user-facing features, and a backend team that provided the data and API,” says Sean Treadway, SoundCloud’s Senior Principal Engineer. “Front-end teams could wait up to a month for the backend team to implement the support for features, increasing work management volumes and delaying delivery.”
The shift to microservice architecture resulted in the creation of end-to-end delivery teams, says Treadway. Beyond that, “it also introduced an API gateway approach, similar to what Netflix had published, called BFFs [Backends for Frontends],” he explains. “Using an API gateway for each front end—desktop website, mobile application or embedded widget—enabled engineers to implement the data APIs tailored to each application, without coordination.”
Treadway says that the switch has proven to be a success for the platform, “especially for basic features and updating the API gateways.”
Microservices significantly increase operational complexity, and having a DevOps mindset and willingness to operate another’s services as well as one’s own is a good way to manage complexity with a small team.
— Sean Treadway, Senior Principal Engineer, SoundCloud
SoundCloud “has roots in agile methodologies,” he notes, and microservices fit well into its DevOps mentality. “Our culture and practice of staffing teams with both development and operational skills result in higher-quality services and shorter incident-response times,” he says. “Microservices significantly increase operational complexity, and having a DevOps mindset and willingness to operate another’s services as well as one’s own is a good way to manage complexity with a small team.”
The Costs and Challenges of Restructuring
As rewarding as the switch to microservices has proven to be for SoundCloud, the process itself was no easy feat.
“We anticipated that moving to a microservice architecture would require common conventions and tooling,” says Treadway, “but we underestimated how much effort it would take to keep engineers productive when building new or maintaining existing services. We also learned that there’s a long list of non-functional requirements that need to be met for a service to be operational.”
Consistency and security are other challenges with microservices. Network APIs are easy to write, Treadway says, but difficult to keep consistent.
“Each of our services map APIs to HTTP slightly differently, which led to the emergence of API client libraries handling those nuances,” he explains. “Linking to shared API client libraries led to transitive dependency conflicts, which defeated the purpose of having independent service deployments.”
Still, the results have proven to be worth the extra work, he says: “It’s a significant productivity gain for engineers to have monitoring, logging, tracing, deployment, configuration validation and connection pooling satisfied with common tools and conventions.”
Would he recommend the switch to microservices to everyone? No—but Treadway believes it can pay off under the right circumstances. “I’d say a service architecture is most effective when a small team of engineers are maintaining a handful of services,” he advises.
Securing Microservice APIs >