The mobile app Sleeve Music is becoming an international sensation, thanks to the vision and talent of the savvy developers at Orange Tribes and their use of Microsoft Azure. When they needed scalability, they turned to Azure App Service. When they needed more scalability at lower cost, Microsoft helped them devise a cache-based architecture. The move to Azure App Service was fast, too; Orange Tribes implemented it in one day.

Maarten-Jan Vermeulen, Founder & CEO of Orange Tribes, came up with the   idea for Sleeve Music after enjoying the beach at Bali. But the development effort hasn’t always been a day at the beach. We spoke with him about the problem he wanted to solve, about the problems he encountered along the way—and how he’s conquered them all.

 

What’s the problem you were trying to solve?

Vermeulen: We wanted to give music lovers everywhere a way to follow their favorite artists, see their latest updates, and discover new music all from one place. That simply wasn’t possible before. We wanted to eliminate the need for music lovers to scour the Internet for their daily music fix—and we have. Our curators are always looking for new and interesting music that matches a music lover’s every mood. This app is a must-have for music lovers!

What were some of the challenges to solving this problem from a development standpoint?

Vermeulen: First, we faced the need to support massive hourly crawl updates of 120,000 music artists on a variety of sites: Facebook, Twitter, Instagram, Last.fm, SoundCloud, YouTube, and Spotify. And we needed a way to minimize the latency in displaying the latest updates of groups of artists on Windows Phone, iOS, and Android.

In our proof-of-concept version of Sleeve Music, the app would directly call all social media providers from Windows Phone for updates of music artists. But we found that this solution was not scalable due to third-party API limitations in terms of number of calls allowed. We also needed to reduce the bandwidth usage and latency of the app in order to improve its responsiveness.

Why did you choose Azure App Service?

Vermeulen: We needed to migrate to a cost-effective, scalable cloud platform. This was a two-fold migration: we had to migrate the crawling process from Windows Phone into a backend that ran in the cloud, and we had to expand our user base to iOS and Android. Azure App Service allowed for a fast migration of each type. All logic—such as access to third-party, social-network providers—is written in C#, which fit in seamlessly in the mobile app backend of Azure. And that mobile app backend has ready-to-use, cross-platform clients for Windows Phone, iOS, and Android. Azure App Service was exactly what we were looking for.

How has using App Service has been going so far?

Vermeulen: Since the migration to Azure, we are monitoring 100,000 artists and 300,000 feeds, and we have ingested 10 million updates into Azure SQL Database. We use caching mechanisms such as Table Storage and Azure Redis Cache, which serve 500,000 users up to 20,000 calls per hour.

We find that monitoring tools allow for rapid resolution and that the modular setup of App Service allows for short iterations of extension, for example when we added Spotify to our crawler in just a few days. I’d say that using App Service has gone very well.

How would you have solved this problem prior to App Service?

Vermeulen: We would probably have hosted the crawler, caching, and API services in virtual machines using either Azure or one of the competitors’ services. By using App Service, we reduced the resources we needed for setup, migration, monitoring, maintenance, extension, and scalability.

Have you had any surprises along the way?

Vermeulen: Yes—quite a big one. The app originally used an Azure worker role to scan for and receive feeds and updates from external sources, and then stored that data in a Microsoft Azure SQL Database. When Azure Mobile Services received a query from the app, it queried the database and passed the desired information to the consumer’s phone.

We found that the load peaked at up to 20,000 API requests per hour when consumers woke each morning and logged on to the app to get their updates. We hadn’t anticipated that volume, and it threatened to degrade performance—which might have driven away consumers just as momentum was building. An Azure Customer Advisory Team was monitoring the load, contacted us, and suggested troubleshooting. The team also suggested a data hierarchy in which the most often-accessed information is maintained in Azure Redis Cache, less-frequently accessed data is in Table Storage, and administrative data is in Azure SQL, minimizing the impact on the higher-cost Azure SQL Database. It worked.

Based on your experience with App Service, what advice would you give others in your shoes?

Vermeulen: You can easily achieve scalability using App Service, but keep in mind that scalability is more than just an Azure-to-mobile implementation. Make use of caching mechanisms such as Table Storage and Redis to reduce anticipated loads on SQL. And be sure to test whether the created solution is scalable using the available tools.

What has been the final impact of the solution?

Vermeulen: With the limited resources of a startup, we were able to grow Sleeve Music nicely into the current, successful product. Azure App Service was instrumental in that.

Be our guest for up to an hour of temporary sandboxed Azure App Service experience with no Azure subscription, free of charge and commitment. Stay longer for the full Azure App Service experience with an Azure free trial subscription.