Competition is fierce in the streaming music industry, where major brands are constantly sharpening their services with additional features and functionality and hundreds of startups try to enter the game with brand new offerings.
Earlier this year, CNET reported that iHeartRadio, iHeartMedia’s all-in-one digital service, hit 70 million registered users. iHeartRadio is a free, live digital radio and music streaming service that lets users listen to thousands of Live Stations from across the country, create personalized Custom Stations based on an artist or song, hear on-demand podcasts and enjoy stations perfect for any mood or occasion. It is available online, on mobile devices, in cars, and on connected devices including TVs, gaming consoles and wearables.
Here, we will highlight how microservices and Reactive help to power the next phase of technology innovation for one of streaming music's biggest players.
Increasing the speed of new feature creation and overall developer velocity are key business drivers for iHeartRadio. In a competitive landscape where users flock to the best methods for discovering and interacting with music, the rate of feature innovation is a key business driver.
In early 2015, the engineering team sought to break a major ball and chain for new features development: its monolithic Java back-end.
Through the breakneck engineering pace path on which it acquired 70 million users in just four years, iHeartRadio accumulated a massive code block with major dependencies. The resulting complexity started to affect new feature development with a set of new problems:
The legacy monolith - called AMP - is a REST Tomcat application written in Java. The AMP codebase is divided into three tiers: the rest layer, the business logic layer and the data access layer. AMP accesses many external systems, including databases (Mongo, Cassandra, Couchbase, PostgreSQL, ElasticSearch) queues (RabbitMQ and Kafka) and external entities (e.g. Facebook/Google APIs). AMP also includes a few layers of caching (CDN, request caching at each server, and distributed caching via Couchbase), and its most heavily used libraries were Spring and Guava.
iHeartRadio decided to break apart this single backend service into microservices (read the full blog post), implemented as Akka apps with Akka Cluster. The four main goals were:
After careful evaluation of all available technologies, iHeartRadio’s team decided that Akka apps without Http interface made the mode sense for its main goals. Here were the most important benefits they isolated in their evaluation:
One of the common protocols used by microservices is HTTP with JSON body. This setup has a performance cost of text (JSON) parsing and a development cost of writing JSON parsers. Akka’s message communication over binary protocol is more optimized for performance and there is no extra parsing code to write. iHeartRadio values both benefits over the looser coupling provided by HTTP with JSON. The iHeartRadio team also separates its message API with the service implementation to provide enough decoupling between the clients and services.
The Akka programming model -- the Actor model -- is transparent within and across microservices. At iHeartRadio, all calling is done through asynchronous message passing regardless of whether the caller and responder are on the same microservice or different ones. This single programming model within and across microservices has two major benefits: 1) it makes development experience consistent - when writing clients, you don’t need to remember where the service actor is, local or remote; and 2) it makes it easier to move logic around, you can easily merge or split microservices with little-to-no code change.
With Akka under the hood for driver-worker communication, using the full power of Akka Cluster, gave the iHeartRadio team confidence in continuing to invest in the technologies powering their platform.
The Akka community is substantial, but what made it different from other candidates in iHeartRadio’s list was the option of having commercial support from Lightbend, which is provided by the core developers in the Akka teams. It was important for iHeartRadio to quickly find answers for engineering issues and not be blocked by a technical problem for any extended period of time.
In a recent discussion with iHeartRadio, Lightbend learned that they have already decoupled several major services from its monolith, using Akka cluster as its microservices framework. Here are some of the early results:
Previously the legacy monolithic application presented so many dependencies and such a massive code base that it was very hard for iHeartRadio to bring any new team members up to speed. With today’s microservices approach, each service is one to several processes at a maximum, with less than 1000 lines of code that are easy to reason with, which has made a huge difference in terms of onboarding new developers.
The flexibility that the microservices approach has brought to iHeartRadio has allowed for the re-organization into feature-oriented teams. These new teams each have responsibility for individual feature development, end-to-end, which further increases developer velocity.
When iHeartRadio receives large amounts of requests over capacity, its system is still able to serve users. Instead of every user seeing a very slow application, most have normal interaction from the application.
Each new microservice is deployed to a Docker container, so deploying a new service is as simple as deploying a new container to the cluster, with fewer manual steps involved. Eventually iHeartRadio intends to move from an internal cloud to Amazon Web Services, so the simple container model is laying some of the groundwork for that migration as an added benefit.
Back to the original highest-level business goal that pushed iHeartRadio to break the monolith into microservices and embrace the Reactive philosophy, the company is currently hard at work on new features expected to drive the next waves of innovation. iHeartRadio is continuing its expansion of the micro-service platform every day, and continues to see benefits in the speed of new feature delivery.
Inspired by this story? Contact us to learn more about what Lightbend can do for your organization.