APIs for Internal Audiences - Netflix - App Dev Conference

Editor's Notes

• #2: To demonstrate the importance of knowing your audience when offering an API, I will be drawing from my current Netflix experience as well as from NPR, my previous employer. Although these two cases may not represent all companies, I do believe that they jointly offer a perspective that is useful when considering API development and strategy.
• #3: The NPR API has several distinct audiences. By the time I left NPR a year ago, the public developer community occupied the overwhelming number of API keys, but represented a sliver of the overall API consumption, as measured by API requests. The inverse is the case, however, for internal NPR development teams.
• #4: The great number of public developers have produced a wide range of apps on a range of platforms. All of them, in total, account for a very small percentage of the overall consumption.
• #6: Comparing this to Netflix, the distribution on both charts is basically the same, with two differences: 1. Netflix has a lot more API traffic. 2. The distribution is more extreme
• #7: Similarly, Netflix has a public developer community, which was the target audience for the API when it launched (we called this the “let 1,000 flowers bloom” model). In fact, when the API first launched, 100% of its traffic came from the flowers.
• #8: Over time, however, devices started to consume the API. Now we have hundreds of devices running off of the API. The 1,000 flowers are still there, but today, they account for less than .3% of the total API traffic, as measured by requests.
• #10: For NPR, we were able to grow the overall page view growth by 100% in a single year. Over 80% of that growth was due to API-enabled mobile products. The development of the mobile products would have been much more difficult without the API. This kind of growth would not have been possible without the API.
• #11: Similarly, Netflix’s growth chart goes up and to the right. But again, the numbers are bigger and the growth more extreme. In 18 months, the Netflix API grew by more than 50x. This growth can be attributed to an increase in devices using the API, an increase in adoption of those devices by Netflix customers, an increase in Netflix customers, and a changing request pattern for some of those devices to better serve our customers. So, the API growth is a proxy for the growth of the Netflix streaming service. Without the API, the growth of the Netflix streaming service likely would have been much less dramatic.
• #13: These metrics demonstrate that the API world for many companies is similar to an iceberg. Public APIs represent a relatively small percentage of the value for the company, but they are typically the most visible part of the API program. They equate to the small part of the iceberg that is above water, in open sight. Conversely, the private APIs that drive web sites, mobile phones, device implementations, etc. account for the vast majority of the value for many companies, although people outside of the company often are not aware of them. These APIs equate to the large, hard to see mass of ice underwater. In the API space, most companies get attracted to the tip of the iceberg because that is what they are aware of. As a result, many companies seek to pursue a public API program. Over time, however, after more inspection into the value propositions of APIs, it becomes clear to many that the greatest value is in the private APIs.
• #14: From the iceberg theory, the key takeaway from these metrics is to understand your audience. From that, many other questions surface, but the answers to them are much clearer if you know who your audiences are. Whichaudiences are the top priorities?How should you design your organization to satisfy these audiences?What is your resource allocation going to be for each audience? What expectations are you setting for each of these audiences?Howwill the audience prioritizations influence the design of the API?
• #15: For Netflix, the internal development teams who build and/or manage the Netflix-branded device implementations are very clearly the top priority.
• #16: This overwhelming priority has a tremendous affect on the Netflix engineering organization. Here are a few examples of the devices that are built/managed by internal Netflix teams. There are several distinct teams who build/manage the development for the hundreds of device implementations in the marketplace.
• #17: Those device implementations have a range of metadata about movies and TV shows that they need in order to create rich experiences to the users. That information is managed by a range of internal engineering teams. Some of these teams manage databases with movie metadata or user information, while others handle complex algorithmic data, such as movie recommendations, etc.
• #18: The API sits in between those two groups of engineering teams, drawing the information from the metadata/algorithm teams and delivering it to the various devices.
• #19: The API sits very much in the critical path of the overall Netflix streaming service. As a result, the API is in the DNA of the Netflix engineering culture.
• #20: The great thing about the API is that it is central to the Netflix streaming service. The issue, however, is that the current API is still designed for its original audience (the public developer community). In other words, even though the API is proving to be very successful, it is not designed for the highest priority audience.
• #21: In essence, while the current API is capable of serving us in the way we need, it is no longer the best tool for the job. This is especially the case as the streaming service grows and expands to new international regions. We believe we can do much better with a new API that is designed for the future of Netflix.
• #23: We already talked about the tremendous growth in API requests…
• #24: Metrics like 1B requests per day sound great, don’t they? Many companies would love to see numbers like this. The reality is that this number is concerning…
• #25: For a web site like NPR’s, it would be tremendous to have 1B requests per day (or per month). Growing request counts for web sites can produce great opportunity for ad impressions which translates directly into revenue.
• #26: But the output of an API looks more like this…
• #27: Or this…For 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.
• #28: As a result, we are challenging ourselves to redesign the API to see if those same 1B requests per day could have been 100M per day, 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.
• #29: Because of itsgranular REST-ful resource model, the current Netflix API model requires a many devices to call these resources individually, often in a synchronous manner. To load a device screen, it often requires a dozen or more requests across the network. The problem is that the network transaction is often the most expensive part of the transactions, so the more requests to the API from the device, the slower the load times for the devices screens.
• #30: In the new model, we will be changing our approach to solve this problem, moving away from traditional REST approaches. Ideally, the devices will be making just one request to the API servers to get everything it needs. The API will scripting tier then explode the one request into the many needed to get the data. Once the data is captured by the API from these various servers, the API will deliver the output back to the device in a single payload. There are a range of benefits from this scripting tier, as follows: 1. It allows us to have one network transaction with the majority of the work happening on the server rather than across HTTP. 2.It allows for dynamic updates to API interactions, which enable faster innovation as the scripts will be managed by the UI teams and dynamically compiled into the JVM. 3. It allows for very targeted payloads for each API call to diminish byte counts. 4. It allows each device to take advantage of its own capabilities without being constrained by generic API modeling. 5. It allows for easy development of custom formatting that may be specific to devices.
• #31: Today, the Netflix API is among the leaders in the API Billionaires Club, a growing list compiled by John Musser of ProgrammableWeb.com.
• #32: Our goal, if we are successful in changing the interaction model between the devices and the API, is to no longer be part of that club.
• #33: If we achieve that goal, all of our devices should run much faster.
• #34: Which, in turn, will help keep our customers happy.