Stitcher, a mobile audio company based in San Francisco, CA, provides an application for streaming podcasts and radio shows directly to mobile devices, desktop and automobiles. Customers can create playlists of their favorite radio shows and podcasts and listen to them on demand. Stitcher uses a sophisticated discoverability algorithm to expose users to additional shows that they can add to their favorites.

When Stitcher launched in 2008, the company was using a co-location service for its infrastructure. By the next year, Stitcher added Amazon Simple Storage Service (Amazon S3) to the environment because the company needed cost-effective, expandable storage to archive its audio files. The service ran on this hybrid solution until 2012, when the company began having availability and scaling issues. It would typically take almost three weeks to purchase and deploy new web servers, which was impeding the company’s ability to scale with its rapidly growing user base. Stitcher also had very little insight into the colocation facility, which meant when there were server related issues, Stitcher was unable to diagnose and address them in a timely manner. Moreover, there was limited redundancy and failover in the infrastructure, so a failure on a single piece of hardware could potentially cause an outage for all customers. “We had trouble with the service going down and not being able to bring on new servers quickly,” says Todd Pringle, VP of Product. “We knew that we were outgrowing the co-location service and we wanted to find a scalable and cost-effective alternative.”

Stitcher researched both on-premises and service provider options, and used cost, ease of implementation, scalability and redundancy as decision criteria. Amazon Web Services (AWS) met all four criteria. While Stitcher was planning the migration, a severe server failure in the co-location environment made the team decide to accelerate the timeline. Using Puppet to write configuration management and deployment scripts, Stitcher’s engineers were able to build, test, and deploy production servers onto AWS in about six weeks. “We were planning a six-month migration,” says Brooke Maury, Director of Engineering, “but we were able to migrate to AWS in six weeks without any down time.”

Stitcher set up its environment using Amazon Virtual Private Cloud (Amazon VPC), where it runs database, web, and memcached servers on Amazon Elastic Compute Cloud (Amazon EC2) instances with Elastic Load Balancing. Stitcher uses a variety of instance types and scales from 28 to 42 instances to boost bandwidth for event updates and alerts. The environment includes Amazon CloudFront for content delivery, Amazon Simple Email Service (Amazon SES) for e-mail, and Amazon Simple Queue Service (Amazon SQS) for alerts and notifications. “One of the features that differentiates AWS from the competition is just how easily programmable the environment is,” Maury says. “The APIs makes it really easy for us to work in the AWS environment.”

Stitcher runs mostly MySQL database servers and has three database servers running Continuent Tungsten for disaster recovery. “We worked with AWS Solution Architects who encouraged us to build our infrastructure for redundancy and failover from the beginning,” says Maury. The infrastructure is divided across two Availability Zones in the US East (Northern Virginia) Region. On the back-end, Stitcher deploys servers for data processing, metrics, data analysis, and search. The following diagram demonstrates Stitcher’s environment on AWS.


Figure 1: Stitcher Architecture on AWS

Stitcher works by crawling its content providers for audio files and processing the files to optimize for streaming to mobile devices. The service stores and archives all content on Amazon S3 so customers can listen to past as well as current episodes of broadcasts, and data size increases daily and continuously. Stitcher has been more than doubling in size every year and the data footprint grows at about 130% of user growth. Stitcher also uses Amazon S3 for database backups. When storage costs began to rise, Stitcher consulted with AWS to use Amazon S3 more efficiently. “We were able to reduce our storage costs almost 60 percent,” says Maury. For the future, Stitcher plans to use Amazon Glacier for items that it no longer needs.

Stitcher reports that, since moving to AWS, its engineers can spin up a web server from scratch, and configure and deploy it in ten minutes, compared to 3 weeks at the co-location facility. They can also provision a database server with data and deploy it in 8 hours instead of 3 weeks. “Improved uptime and availability have been huge business wins,” reports Pringle.

Stitcher has had no major outages since moving to AWS, compared to several outages per year with the previous infrastructure. Radio station load time, a direct benefit for customers, is one of Stitcher’s key performance metrics. Maury estimates that moving to AWS improved station load time by nearly 100 percent.

Stitcher credits early guidance from AWS when they started to build the infrastructure, as well as documentation and community support, for the success of its environment. “It’s complicated to migrate to a new environment,” says Maury. “Using AWS makes it surprisingly smooth and gave us immediate improvement in availability and cost savings straight out of the box. We were able to nearly double our server footprint while maintaining the same cost.”

To learn more about how AWS can help your mobile application needs, visit our Web, Mobile, and Social Data details page: