AWS Case Study: Skifta


Skifta is a free service that allows consumers to shift media from the network it is stored on and access it in other locations. For example, you can access your music stored on your home PC, then play it on your TV, Playstation3, mobile device, or wireless radio. The idea for the service came out of the team’s own frustration and desire to listen to their music while away from home.
Skifta

Skifta is a great example of a product that may not have been possible without cloud computing. Skifta has a six-person development team and is a wholly owned subsidiary of Qualcomm. Ed Smith, Director, Product Development, explains, “The alternative solution would have been to build out large development and test environments to evaluate the cost of deploying Skifta globally. Then, assuming the investment could be justified, petition for a large budget to build a global infrastructure to support a solution yet to prove its viability. It is doubtful the service would exist today were it not for AWS.”

The maturity of the AWS solution was the primary factor in Skifta choosing it as their hosting provider. “With six people on the team it was imperative that the development tools allowed one primary and one secondary person to run all our environments (development, integration, test, stage and production) and manage all aspects of those environments (deployment, elasticity, scaling, monitoring and disaster recovery). All of this needed to be achieved without impacting the rest of the team’s activities. Amazon stands head and shoulders above its competitors – in terms of the quality and range of AWS services and the international reach. We have been impressed with the quality of the implementations and tools and we derive confidence in the knowledge that Amazon is innovating as quickly as we are.”

The AWS cloud computing platform allows Skifta to run in multiple regions in a redundant, disaster recovery architecture, and scale according to usage needs – by geography. They have built Skifta around the AWS philosophy, architecture, and feature set. Smith breaks down their architecture by AWS service:

  • Amazon EC2 – Used for development, testing stage and production environments (particularly useful for stress testing the solution for 24-hour periods). These environments include our web and mobile web sites, the super peers that assist in streaming media from one location to the other, the distribution centers that distribute the client downloads, and finally the backend logic. We also utilize Regions in conjunction with geographic DNS to allow customers to contact the server nearest them.
  • Amazon S3 – Used in all our systems for serving binary files, from images and user-defined avatars to installation files. Amazon S3 scalability means we don’t need to worry about load and gives us a convenient location for storage of permanent data outside the application servers. With this architecture, we can create multiple instances on demand of the application servers without worrying about synchronizing their data at create-time.
  • Amazon SQS – Used to synchronize cache and runtime data between regions.
  • Amazon SimpleDB – Used for event data from production systems. Useful in terms of unstructured storage where the exact definition varies from event type to event type. Gives us an efficient “event dump” area that can be analyzed at a later stage.

The Skifta team has been able to deploy a full solution for a fraction of the cost of traditional hosting models. “A capex approach to this project would have meant an expenditure of over $1M on hardware and data centers. But in the last twelve months, we have developed, deployed and launched a media shifting solution that can scale to support millions of subscribers, performing millions of transactions, with a total hardware and software spend of less than $70,000,” confirms Smith.

Not only has Skifta been able to save money and go to market quickly, Smith also believes there are underlying development advantages. “The ability to design and code a software service that can take advantage of elastic computing has produced better code, better deployment and scaling tools and a better approach to iterative code development. It makes a huge difference that the code development and test cycle does not need to be project managed to ensure the appropriate resources are available and configured in time for the right testing cycles. Testing can take place on an as-needed basis.”

Cloud computing has also required a different mindset with regards to the lifespan of machines. In our case, all machines are created dynamically. This has cut the risk of operator error on installations and upgrades to virtually zero, since everything including automated testing can be tested in the replica environments ensuring no fat finger trouble on eventual launch into production.”

Visit http://www.skifta.com This link will launch in a new browser window or tab. to sign up for a free account.

(Published January 2010)

Top









AWS Security Center
Learn about our physical and operational security processes and download the latest AWS Security Whitepaper.

Go to AWS Security Center



Webinars
Listen to previously recorded webinars featuring AWS services, partners, and customers and sign up for upcoming virtual events.

Go to AWS Webinar Homepage

©2010, Amazon Web Services LLC or its affiliates. All rights reserved.