Why API? - Business of APIs Conference

Director of Engineering - Netflix API at Netflix
Sep. 10, 2013
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
Why API? - Business of APIs Conference
1 of 50

More Related Content

What's hot

Scaling the Netflix APIScaling the Netflix API
Scaling the Netflix APIDaniel Jacobson
KPIs for APIs (and how API Calls are the new Web Hits, and you may be measuri...KPIs for APIs (and how API Calls are the new Web Hits, and you may be measuri...
KPIs for APIs (and how API Calls are the new Web Hits, and you may be measuri...John Musser
Set Your Content Free! : Case Studies from Netflix and NPRSet Your Content Free! : Case Studies from Netflix and NPR
Set Your Content Free! : Case Studies from Netflix and NPRDaniel Jacobson
Netflix API - Separation of ConcernsNetflix API - Separation of Concerns
Netflix API - Separation of ConcernsDaniel Jacobson
Netflix API: Keynote at Disney Tech ConferenceNetflix API: Keynote at Disney Tech Conference
Netflix API: Keynote at Disney Tech ConferenceDaniel Jacobson
Techniques for Scaling the Netflix API - QCon SFTechniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SFDaniel Jacobson

Viewers also liked

API Frenzy: API Strategy 101API Frenzy: API Strategy 101
API Frenzy: API Strategy 101Akana
Pragmatic REST APIsPragmatic REST APIs
Pragmatic REST APIsamesar0
Api for dummies  Api for dummies
Api for dummies Patrick Bouillaud
API for BeginnersAPI for Beginners
API for BeginnersGustavo De Vita
API Economy:  2016 Horizonwatch Trend BriefAPI Economy:  2016 Horizonwatch Trend Brief
API Economy: 2016 Horizonwatch Trend BriefBill Chamberlin
Welcome to the API EconomyWelcome to the API Economy
Welcome to the API EconomyNino Guarnacci

Similar to Why API? - Business of APIs Conference

APIs as a Product StrategyAPIs as a Product Strategy
APIs as a Product StrategyRavi Kumar
Pitney Bowes Uses Development and Testing Tools to Drive Early API Developmen...Pitney Bowes Uses Development and Testing Tools to Drive Early API Developmen...
Pitney Bowes Uses Development and Testing Tools to Drive Early API Developmen...CA Technologies
Oscon2014 Netflix API - Top 10 Lessons LearnedOscon2014 Netflix API - Top 10 Lessons Learned
Oscon2014 Netflix API - Top 10 Lessons LearnedSangeeta Narayanan
Top 10 Lessons Learned from the Netflix API - OSCON 2014Top 10 Lessons Learned from the Netflix API - OSCON 2014
Top 10 Lessons Learned from the Netflix API - OSCON 2014Daniel Jacobson
Accidental API developer - the 12 month pregnancy to create new APIAccidental API developer - the 12 month pregnancy to create new API
Accidental API developer - the 12 month pregnancy to create new APIMarjukka Niinioja
ReliefWeb's Journey from RSS Feed to Public APIReliefWeb's Journey from RSS Feed to Public API
ReliefWeb's Journey from RSS Feed to Public APIPhase2

Similar to Why API? - Business of APIs Conference(20)

More from Daniel Jacobson

Netflix Edge Engineering Open House Presentations - June 9, 2016Netflix Edge Engineering Open House Presentations - June 9, 2016
Netflix Edge Engineering Open House Presentations - June 9, 2016Daniel Jacobson
Maintaining the Front Door to Netflix : The Netflix APIMaintaining the Front Door to Netflix : The Netflix API
Maintaining the Front Door to Netflix : The Netflix APIDaniel Jacobson
History and Future of the Netflix API - Mashery Evolution of DistributionHistory and Future of the Netflix API - Mashery Evolution of Distribution
History and Future of the Netflix API - Mashery Evolution of DistributionDaniel Jacobson
NPR Presentation at Wolfram Data Summit 2010NPR Presentation at Wolfram Data Summit 2010
NPR Presentation at Wolfram Data Summit 2010Daniel Jacobson
NPR: Digital Distribution Strategy: OSCON2010NPR: Digital Distribution Strategy: OSCON2010
NPR: Digital Distribution Strategy: OSCON2010Daniel Jacobson
NPR's Digital Distribution and Mobile StrategyNPR's Digital Distribution and Mobile Strategy
NPR's Digital Distribution and Mobile StrategyDaniel Jacobson

Recently uploaded

Getting your enterprise ready for Microsoft 365 CopilotGetting your enterprise ready for Microsoft 365 Copilot
Getting your enterprise ready for Microsoft 365 CopilotVignesh Ganesan I Microsoft MVP
Uber Clone Script - Keys to Understanding the Ride Hailing IndustryUber Clone Script - Keys to Understanding the Ride Hailing Industry
Uber Clone Script - Keys to Understanding the Ride Hailing IndustryeSiteWorld TechnoLabs Pvt. Ltd.
Unleashing Innovation: IoT Project with MicroPythonUnleashing Innovation: IoT Project with MicroPython
Unleashing Innovation: IoT Project with MicroPythonVubon Roy
Navigating the FutureNavigating the Future
Navigating the FutureOnBoard
Product Listing Presentation-Maidy Veloso.pptxProduct Listing Presentation-Maidy Veloso.pptx
Product Listing Presentation-Maidy Veloso.pptxMaidyVeloso
Knowledge Graphs and Generative AI_GraphSummit Minneapolis Sept 20.pptxKnowledge Graphs and Generative AI_GraphSummit Minneapolis Sept 20.pptx
Knowledge Graphs and Generative AI_GraphSummit Minneapolis Sept 20.pptxNeo4j

Recently uploaded(20)

Why API? - Business of APIs Conference

Editor's Notes

  1. Simon Sinek is the author of the book, “Start with Why”
  2. He has also given a TED Talk on the concepts from his book. His talk is the 2nd most viewed of all time, exceeding over 12M views at the time of my presentation.
  3. In his talk and book, Simon talks about the “Golden Circle”.
  4. The Golden Circle is designed to describe and prescribe how people communicate their ideas to others. Typically, that communication comprises three constructs: Why, How and What.
  5. And most often, people and companies describe things in this order: What, How, then Why.
  6. Another way of thinking about this is that people start with the clearest idea (What), then move to the less clear (How), towards ultimately the very fuzzy (Why).
  7. For example: WHAT = I have this device (iPhone). It has email, calendars, a browser and a ton of apps. HOW = It helps me manage my work and personal life. WHY = It makes my life easier and more manageable. I don’t have the iPhone because it has email, calendars, apps, etc. I have the iPhone because those things make my life easier. It just happens to be an iPhone that achieves my goal.
  8. But the better way to think about this is from the inside out. Focus on making my life easier, by identifying that which better manages my work and life, which could translate into a device like the iPhone.
  9. But it could be that any of these other devices can achieve my goal of making my life easier. If the iPhone no longer makes my life easier, then I won’t use the iPhone anymore. In other words, it will no longer answer my Why.
  10. So, we are at the Business of APIs Conference…
  11. It is therefore important for us to focus on answering this critical question! This is the most important question when entering this space. All other questions follow from this one.
  12. Or it could be to help you better or more quickly achieve greater device proliferation.
  13. The problem, however, is that when most people start considering APIs, they start with the What.
  14. Here is an example of how the What often is the start of an API program. At the top of an iceberg, above the water line, is the smallest part of the iceberg. This represents the open APIs as both are highly visible. For APIs, this is also what most people are aware of. But the majority of the iceberg’s mass is under the water line, where it is not visible. The larger mass underwater equates to the closed APIs, those that you are most likely not aware of account for the vast majority of the APIs that exist along with the vast majority of the traffic and consumption. Because most people are aware of the public APIs (and not the private ones), this is usually the starting point for the API discussion. That, in itself, limits the thinking around APIs. You are already going down the road of the What without establishing a clear Why.
  15. Instead of starting with the public APIs, start with Why API? Then identify who the audiences are for it. Then that should dictate what you should build.
  16. Start with Why, and move outward.
  17. To demonstrate how the Why impacts everything else, I will use Netflix (my current employer) as an example.
  18. The API product then launched with a full REST API, complete with a developer portal, documentation, key management, terms of use, etc.
  19. And it was targeted to support the 1,000 flowers model. That is, we would plant the seeds in the ground (by providing access to our content) and see what flowers sprout up in the myriad fields throughout the US. The 1,000 flowers are public API developers. At the launch of the public API, the content was fully liberated and the bird was set free to fly around in the open world.
  20. And at launch, the API was exclusively targeted towards and consumed by the 1,000 flowers (i.e.. External developers). So all of the API traffic was coming from them.
  21. Some examples of the flowers…
  22. Our streaming application launched shortly before the public API and started gaining steam…
  23. We started introducing more devices over time.
  24. And the API grew to support, not only the public developers, but also many of these devices (some of which were developed internally and others through partnerships).
  25. So our Why started to shift from “Forming a developer community” to “Supporting a range of different types of developers”.
  26. The API was still a product strategy, but with a growing and diversifying audience.
  27. The REST API was still supporting this ecosystem and strategy.
  28. And the number of devices continued to grow.
  29. As did our traffic…
  30. Meanwhile, the balance of requests by audience had completely flipped. Overwhelmingly, the majority of traffic was coming from Netflix-ready devices and a shrinking percentage was from the 1,000 flowers. As a result, the Why proposition has changed significantly.
  31. The new Why is that the API is no longer a product designed to serve a range of different audiences. Rather, it is now a tactic designed to support the streaming application.
  32. It is a tactic to support our millions of subscribers.
  33. To support the system that handles 33% of the peak Internet traffic in the US.
  34. Our content and growing original content strategy.
  35. And our 1,000+ different device types. This is significant because there is so much diversity in 1,000 different device types!
  36. For example, screen size could significantly affect what the API should deliver to the UI. TVs with bigger screens that can potentially fit more titles and more metadata per title than a mobile phone. Do we need to send all of the extra bits for fields or items that are not needed, requiring the device itself to drop items on the floor? Or can we optimize the deliver of those bits on a per-device basis?
  37. Different devices have different controlling functions as well. For devices with swipe technologies, such as the iPad, do we need to pre-load a lot of extra titles in case a user swipes the row quickly to see the last of 500 titles in their queue? Or for up-down-left-right controllers, would devices be more optimized by fetching a few items at a time when they are needed? Other devices support voice or hand gestures or pointer technologies. How might those impact the user experience and therefore the metadata needed to support them?
  38. The technical specs on these devices differ greatly. Some have significant memory space while others do not, impacting how much data can be handled at a given time. Processing power and hard-drive space could also play a role in how the UI performs, in turn potentially influencing the optimal way for fetching content from the API.
  39. Many UI teams needing metadata means many requests to the API team. In the REST world, we essentially needed to funnel these requests and then prioritize them. That means that some teams would need to wait for API work to be done. It also meant that, because they all shared the same endpoints, we were often adding variations to the endpoints resulting in a more complex system as well as a lot of spaghetti code. Make teams wait due to prioritization was exacerbated by the fact that tasks took longer because the technical debt was increasing, causing time to build and test to increase. Moreover, many of the incoming requests were asking us to do more of the same kinds of customizations. This created a spiral that would be very difficult to break out of…
  40. So, the REST API, which served the original Why perfectly…
  41. No longer works for our new model. As a result, we fundamentally redesigned the API away from the REST model to one that more appropriately supports the new Why. That new architecture is the topic of other talks and blog posts, but will not be discussed here.
  42. With the shifting of the Why for Netflix, that also shifted our How and What in significant ways. Ways that more effectively support our growing streaming business.
  43. For Netflix, our API strategy can be discussed in the form of an iceberg. The public API strategy is the prominent, highly visible part of the iceberg that is above water. It is also the smallest part of the iceberg, in terms of mass. Meanwhile, the large mass of ice underwater that you cannot see is the most critical and biggest part of the iceberg. The visible part of the iceberg represents the public API and the part underwater is the internal strategy. Netflix’s strategy over the years has shifted from public to internal.