This is a presentation that I gave to ESPN's Digital Media team about the trajectory of the Netflix API. I also discussed Netflix's device implementation strategy and how it enables rapid development and robust A/B testing.
RSS feeds are one example of a commonly used API, albeit a very simple one.
Podcasts are another example of an API, extended from RSS.
In addition to the APIs that ESPN currently offers online, ESPN is also consuming perhaps the most popular API – Google Maps.
Netflix has a series of engineering teams that focus on very specific problems around movie and user information. That information needs to get to the hundreds of devices where Netflix users enjoy our streaming service. That information gets through through the API.
Visual representation of the “1,000 flowers” model.
Some of the apps that have been built by the open developer community (1,000 flowers).
Then streaming started taking off for Netflix
And the API started supporting more and more internal device implementations
Now, we have hundreds of devices being run off the API, driving tremendous business growth.
Including the Android app, which just launched in May, 2011.
And the Netflix API traffic has gone through the roofAveraging over 20B requests per monthWith peak traffic over 18,000 requests per second
And the proportion of API requests coming to the Netflix API through the public has gone way down.The 1,000 flowers represent less than ½ a percent of the total API traffic
So, we are now on hundreds of devices. How do we modify our development approach to make it easier to add new devices? How do we improve the efficiency around device implementation to match the efficiencies that the API provide us?
Especially when features differ from device to device.
The differences across the devices call into question how to develop effectively and efficiently for all of them. This raises a decision on how to implement for the devices. For us, that became a question about WebKit or native app implementations. Most of our implementations are WebKit-based.
iPhone and Android apps are both WebKit implementations. In fact, the Netflix Android app is derivative from the same codebase as the iPhone app. There are key differences, but the iPhone codebase can be leveraged here in ways that a native app cannot.
So, we have seen tremendous growth in API consumption.
Metrics like 20B requests per month sound great, don’t they? The reality is that this number is concerning…
In the web world, increasing request numbers mean increasing opportunity of ad impressions, which means increasing opportunity for generating revenue. And when you hit certain thresholds in impressions, CPMs start to rise, which means even more money.
Other media organizations are employing different techniques to generate more traffic. The New York Times, for example, is paginating their article pages which creates more potential page views and therefore ad impressions.
But for systems that yield output that looks like this, such as APIs, ad impressions are not part of the game. As a result, the increase in requests don’t translate into more revenue. In fact, they translate into more expenses. That is, to handle more requests requires more servers, more systems-admins, a potentially different application architecture, etc.
We are challenging ourselves to redesign the API to see if those same 20 billion requests could have been 5 billion or perhaps even less. Through more targeted API designs based on what we have learned through our metrics, we will be able to reduce our API traffic as Netflix’ overall traffic grows.
So, when redesigning the API, we want to target it towards to key audiences. For us, the key audiences are our devices.
Once it is designed for our future, we will trickle it down to the 1000 flowers and/or other audiences.
And we don’t just plan to design the API to be for our current audience. Instead, we plan to dream bigger and design the system for the audience that we want.That doesn’t mean we should implement today the system we want for the dream audience. It just means the design should allow for the system to scale to that audience.
For Netflix, we have designed our server architecture, using AWS, to be highly scalable. The API redesign will help us scale the software better to handle this scaling more effectively and efficiently.
Transcript of "Presentation to ESPN about the Netflix API"
The Netflix API<br />How Netflix Launched an API and Evolved it to Serve Millions on Hundreds of Devices<br />By Daniel Jacobson<br />
Who Am I?<br />Director of Engineering for Netflix API since October 2010<br />Tenure at NPR from 1999 to 2010<br />Built the custom CMS in 2002<br />Extended system for RSS and Podcasting<br />Launched the NPR API in 2008<br />Launched NPR redesign in 2009<br />
Netflix Overview<br />Netflix offers subscriptions to unlimited streaming movies and TV shows for a very low price<br />About 700 operational employees, 300 engineers<br />More than 23 million subscribers in US and Canada<br />Market capitalization is about $12B<br />Account for over 20% of US bandwidth during peak hours (some say 30%)<br />
What is an API?<br />An API is a “contract” between two computer applications or systems to deliver content or functionality from one to the other.<br />
Original Charter for the Netflix API<br />Expose Netflix metadata and services to the public developer community to “let 1,000 flowers bloom.” That community will build rich and exciting new tools and services to improve the value of Netflix to our customers.<br />
Netflix <br />API<br />There are currently over<br />17,000 flowers <br />
New Charter for the Netflix API<br />Build and maintain an infinitely horizontally scalable data distribution pipeline for getting metadata and services from internal Netflix systems to streaming client apps on all platforms in the format and/or delivery method that is most optimal for each app and platform.<br />
Some of the many <br />Netflix-ready <br />devices<br />
Products and Features Vary from Device to Device<br />Application development attempts to treat all apps the same until they are different<br />Different devices enable different features, so implementations should consider those differences<br />Aspect Ratios<br />Connection Speeds<br />Security Concerns<br />Screen Real Estate<br />User Expectations<br />
Other Benefits of WebKit:A/B Testing<br />Run multiple test cells at once<br />Tests can be for minor changes or fundamentally different designs<br />Winning tests are determined through metrics, not conjecture<br />Winning tests graduate easily to production<br />Pushing tests often do not require partner involvement<br />