Developing an API strategy should be considered a journey, not a project with a predetermined outcome. This presentation describes Netflix's journey to discover a winning API strategy as well as future directions for the API.
WhatsApp 9892124323 ✓Call Girls In Kalyan ( Mumbai ) secure service
API Strategy Evolution at Netflix
1. API Strategy Evolution at
Michael Hart (@michaelhart)
Director of Engineering, Social Systems
(Former Director of Engineering, API)
Daniel Jacobson (@daniel_jacobson)
Director of Engineering, API
2. Presentation is designed for presenting vs. reading.
Please review speaker notes if reading online.
25. Some of our Key Goals
• Resiliency, Reliability and Stability
– Maximize uptime
• Scalability
– System can grow without needing frequent refactoring
• Simplicity
– Easier integration for API consumers
• Agility
– Architecture will support rapid development without compromising the core
of the system
30. (Some) API Interfaces and Their Dependencies
Auto-
Complete
Similars QueuesLIsts
Rental
History
Agg
Lists
SEARCH
SIMILARS
SYSTEM
RECOMMENDATION
ENGINE
QUEUE
RENTAL
HISTORY
REST Interface API Dependency
Title
Details
Previews Ratings Recommendations
Title
States
CONTENT
MANAGEMENT
SYSTEM
TITLE STATES CINEMATCH
40. Flexible API Requests
As flexible as SQL
SELECT person_first_name, person_last_name, dept_name
FROM person, department
WHERE UPPER(dept_name) LIKE ‘%Engineering%’
AND person_added_date BETWEEN ‘2002-01-01’ AND sysdate
ORDER BY person_last_name ASC
Manages Partial Response
Determines the Selected API
Restricts Output
Sorts Results
GOAL: API should be able to handle any request that you can do in SQL
46. Questions?
API Management
• Engineering Manager – Web API Systems: http://bit.ly/9O3Hic
• API Integration Systems Analyst: http://bit.ly/hyPxCh
API Engineering
• Senior Software Engineer/Architect – Web API Platform: http://bit.ly/e0AKw4
API Test Engineering
• Senior Software Engineer in Test – API: http://bit.ly/9zHPtJ
• Senior Software Engineer in Test – API Platform: http://bit.ly/eD3tLn
• Lead Software Engineer in Test – API: http://bit.ly/fqxBYC
Social Engineering
• Social Systems – Engineer Architect: http://bit.ly/dYq6C8
Michael Hart
Director of Engineering – Social
@michaelhart
Daniel Jacobson
Director of Engineering – API
@daniel_jacobson
Notas del editor
The first point I’d like to make is that API strategy, like any strategy, is only valid in a particular context, the opportunities and constraints within which each business operates
Your mileage may vary.
The initial API strategy could be called A Thousand Flowers, as in “let a thousand flowers bloom”
The inspiration for the API program came from the same inspiration as the Netflix prize- an attempt to outsource some aspects of innovation.
The Netflix Prize: thousands of teams spent almost3 years trying to come up with a recommendations engine that could beat our own by 10% and win $1M.
A testament to not only our ability outsource some aspects of innovation, but also to our own ability to innovate: it took three years for thousands of teams to beat the recommendations engine we developed by just 10%.
Outsourcing some innovation is just one of the ways Netflix tries to stay small, a “big startup”.
This is a slide I showed at the Business of APIs conference two years ago showing a range of potential partners from large to small.
Could we recreate the same innovation dynamic around an API as we did with the Netflix Prize, enabling external innovation around our API to create user experiences that would improve movie discovery, especially by enabling the smaller developers down the tail to have an equal shot of innovating with our service as larger potential partners?
We win if one developer comes up with a very big idea or a bunch of developers develop apps that addressed specific niches that, in total, would be significant.
@Netflix: the simplest measure of “significant” for any initiative means delivering some tangible value to at least 20% of our subs in any given month. That criteria helps us maintain focus and stay small and nimble by not chasing small opportunities. What is a small opportunity for Netflix might be a relatively larger opportunity for others business. Again, YMMV.
As you can see in this distribution of API-enabled application usage, the long tail didn’t really materialize.
Furthermore, the total value delivered didn’t come close to our 20% bar.
Most popular apps weren’t all that innovative in terms of scenarios, they just delivered our existing scenarios to form factors it wasn’t efficient for us to reach. Mobile apps were the most successful, but they were just delivering existing Netflix website scenarios like search and recommendations.
Why? With varied implementation technologies (C, C#, Objective C), and unclear sub reach, it would have been costly in both real and opportunity costs for Netflix to experiment with developing apps for these platforms, and external developers filled that void.
Even with that bright spot, overall sub usage wasn’t high enough to justify the API program alone.
The something interesting happened: Xbox approached us for ideas for the v2 version of the Netflix application
We were already seeing signs that streaming device reach was big driver for the business.
Up until this point, our streaming device apps didn’t support discovery of titles (we weren’t sure we could do this well).
We also delivered our streaming app to partners via a C-based Linux application supported by a client SDK in turn supported by private APIs separate from our public API. A partner app couldn’t be built directly against this API and minor extensions to the API required a whole new API version. Porting the app and SDK to a non-Linux platform like Xbox also took extra time.
It took at least a quarter to roll out new scenarios through this implementation stack.
Our private API plus client SDK didn’t have anything new to offer over the v1 application.
Did we just learn something from the 1000 flowers experiment? The REST-based open API could be revved more quickly and was easier to work with cross-platform given it was designed without any client requirement It happened to have a new recommendation API, internally called LOLOMO for “Lists of Lists of Movies”, which was our first foray into enabling subscribers to discover movies and tv shows on a device.
LOLOMO was integrated into Xbox using the open API and streaming usage went up noticeably after launch. It was now clear that we could deliver new, Netflix-originated scenarios quickly to devices via the open API.
Exciting, but that put a big “?” on the 1000 flowers strategy.
Rights restrictions on streaming titles demanded that they be delivered only within Netflix-branded applications
Netflix branded applications demanded an application certification process to ensure a quality experience for our subscribers. Unlike third-party applications, our name was on the app which meant we couldn’t simply disable it if it was a disappointing experience for our subscribers, used the API inefficiently, etc.
However IW device reach had proven to be a major driver for our business, and the user attach rate per Netflix app was much higher than for third-party apps
Couple that with the possibility of increased viewing per device, and it became possible to move metrics beyond sub usage to subscriber acquisition, retention and lower distribution costs due to streams substituting for disc shipments
Achieved fantastic success accelerating the rollout of proven app scenarios quickly across branded Netflix applications
API gave us flexibility to deliver to quickly to C/Linux apps, Flash apps, and more
Also variety of development approaches, Netflix, vendor or partner. Equal access to our service functionality for all.
That flexibility in both client platforms and development approaches helped us deliver these new scenarios quickly to all three major game consoles and the top 10 brands in TVs and Blu-ray players
This picture is from May, we’re now on over 200 devices at retail
At this point, our investment in the API had clearly paid off. Over 60% of subs streamed last quarter and we’re also realizing significant per sub streaming increases, albeit some percentage are PC and pre API devices.
But having achieved this kind of TV device reach, what would we do next?
Mobile was next frontier for us, having reached this critical mass of TV connected devices.
At this time, we were also investigating the promise of using HTML 5 and Javascript stack for our device applications. HTML 5 offered a number of potential benefits.
Deliver compelling device experiences with visual effects that didn’t make you feel like you were on a PC website.
User expectations on TV devices: EPG, performance you get with native apps and local data. Game consoles bar is higher.
On mobile, most native apps trump web apps with similar functionality.
Despite the outsourcing of some innovation through programs like the API and the Netflix Prize, we do also do a fairly good job of innovating at Netflix. Innovation through iteration on www through two week site updates.
Web delivered UI gave us the power to completely control our experience on partner devices. We don’t have to incur the release delays associated with iPhone app store or other device partner application approval or certification processes, since updates to HTML content are very low risk compared to native code updates.
Our iPhone app shown here is basically a browser shell for an HTML UI with extensions for DRM’d video playback.
If you play this out to a logical conclusion, it could mean the end of the API usage for delivering Netflix device experiences at some point in the future. Server-generated HTML web pages wouldn’t necessarily need a publicly accessible API.
Server-generated web pages couldn’t achieve performance goals without leveraging AJAX heavily. Consider a two-dimensional grid of movie recommendations. Only part of the grid is visible at any time, and offscreen titles can be loaded incrementally. API responses are also smaller network payloads than downloaded HTML.
The API gave us exactly what we needed to build great AJAX-powered experiences.
And, guess what? Most compelling mobile platforms like iPhone and Android lead in HTML 5 browser penetration. In fact, unlike on a PC, it’s only HTML 5 browsers on those platforms. No cross-browser compatibility concerns on a device.
We now could leverage the API effectively for the aforementioned device applications plus a Netflix-delivered, web-based user on HTML-5-enabled mobile devices. But, we didn’t stop at mobile.
What if instead of implementing our UI natively on a TV device, we brought WebKit to the party instead?
Not only do we update service features rapidly on two week release cycles, all new features or even incremental enhancements to existing features also undergo rigorous A/B testing, involving different user experiences being tested in parallel with distinct groups of users. This is the only practical way to ensure that new experiences are indeed better than their predecessors, and not simply outperforming them due to other external factors like seasonality, new content license deals, etc. We’ve been employing these techniques to improve our website experience for years.
When we re-launched our PS3 app a few weeks back we began testing of 4 different app experiences concurrently.
Once an API-supported scenario has been rapidly developed and tested on one or more HTML 5 applications, it can be finalized and then be leveraged in other less updateable application.
Once your API starts supporting rapid product innovation, you have to ensure that rapidly developed APIs supporting test experiences for thousands of users don’t affect the stability of APIs supporting millions of users.
How do you balance these competing goals? You actually don’t have to choose between the two.
Provisional APIs are one tactic for addressing this tension. Since new features are tested on platforms with easily updated client code, provisional APIs can be developed for a test scenario and then deprecated or modified before creating stable APIs that can be used by a wider range of clients as well as external developers. The test client can be updated to manage these changes as necessary.
These provisional APIs can also be deployed and operated on different server clusters than the stable APis, minimizing the chance of less tested, more rapidly developed code being tested with thousands of users from potentially destabilizing services being used by millions of other users. Apigee’s Gateway allow you to easily route incoming API traffic to enable this partitioning.
Call this the third evolution of Netflix API Strategy: Tons of Tests. While any potential competitor will have to work hard to get our device reach, we’ll be accelerating our user experience innovation on top of our API.
Despite these major changes, the API has still been able to achieve the goals of the company to the point that it is now serving roughly ? billion requests per month.
Over the last two years, the API has seen a ton of changes. Some tactical, some fundamental.
All under great time constraints and pressure to propel the business forward.