Why API? - Business of APIs Conference
•Descargar como PPTX, PDF•
17 recomendaciones•4,903 vistas
Many API programs get launched without a clear understanding as to WHY the API should exist. Rather, many are focused on WHAT the API consists of and HOW it should be targeted, implemented and leveraged. This presentation focuses on establishing the need for a clear WHY proposition behind the decision. The HOW and then WHAT will follow from that. This presentation also uses the history of the Netflix API to demonstrate the power, utility and importance of knowing WHY you are building an API.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (16)
Similar a Why API? - Business of APIs Conference
Similar a Why API? - Business of APIs Conference (20)
Más de Daniel Jacobson
Más de Daniel Jacobson (9)
Último
Último (20)
Why API? - Business of APIs Conference
- 2. This presentation has notes, in the Notes field below, detailing what I spoke when giving this presentation.
- 6. HOW WHAT WHY
- 7. HOW WHAT WHY
- 12. The WHAT is a tactical manifestation that answers the WHY
- 14. Why build an API?
- 15. Why are you building APIs? Developer Community New Revenue Stream Business Partnerships Development Efficiency Device Proliferation
- 16. HOW WHAT WHY
- 18. How will it be used? What should be built? Why API?
- 19. How will it be used? What should be built? Why API?
- 21. Netflix API Strategy : 2009 • Build a developer community • Enable them to reach new potential subscribers • Offer bounty for each new trial as incentive • Potentially improve subscriber experience, increasing retention
- 22. Netflix API Strategy : 2009 • Build a developer community • Enable them to reach new potential subscribers • Offer bounty for each new trial as incentive • Potentially improve subscriber experience, increasing retention
- 23. 2009
- 24. Image courtesy of Jay Mac 3 on Flickr
- 25. Netflix API Requests by Audience 2009 External Developers
- 27. 2007
- 30. Netflix API Strategy : 2010 • Support the existing developer community • Support partner integrations • Enable device proliferation strategy • Support internal UI teams
- 31. Netflix API Strategy : 2010 • Support the existing developer community • Enable device proliferation strategy • Support internal UI teams • Support partner integrations
- 34. Growth of Netflix API Requests 0.6 20.7 41.7 - 5 10 15 20 25 30 35 40 45 Jan-10 Jan-11 Jan-12 RequestinBillions 70x growth in two years
- 35. Netflix API Requests by Audience External Developers 2B daily < 1M daily It takes nearly three years of public API requests to equal one day’s worth of private API requests
- 36. Netflix API Approach : Today • Maximize efficiency in internal development • Optimize system for rapid innovation and improved product experience • Ensure system reliability and resiliency • Scale system with the business
- 37. Netflix API Approach : Today • Maximize efficiency in internal development • Optimize system for rapid rapid innovation rate and product experience • Ensure system reliability and resiliency • Scale system with the business
- 38. Nearly 38 Million Subscribers More than 40 Countries
- 39. Netflix Accounts for 33% of Peak Internet Traffic in North America Netflix subscribers are watching more than 1 billion hours a month
- 43. Controller
- 48. How will it be used? What should be built? Why API?
- 49. So, why are you building an API?
Notas del editor
- Simon Sinek is the author of the book, “Start with Why”
- 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.
- In his talk and book, Simon talks about the “Golden Circle”.
- 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.
- And most often, people and companies describe things in this order: What, How, then Why.
- 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).
- 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.
- 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.
- 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.
- So, we are at the Business of APIs Conference…
- 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.
- Or it could be to help you better or more quickly achieve greater device proliferation.
- The problem, however, is that when most people start considering APIs, they start with the What.
- 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.
- 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.
- Start with Why, and move outward.
- To demonstrate how the Why impacts everything else, I will use Netflix (my current employer) as an example.
- The API product then launched with a full REST API, complete with a developer portal, documentation, key management, terms of use, etc.
- 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.
- 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.
- Some examples of the flowers…
- Our streaming application launched shortly before the public API and started gaining steam…
- We started introducing more devices over time.
- 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).
- So our Why started to shift from “Forming a developer community” to “Supporting a range of different types of developers”.
- The API was still a product strategy, but with a growing and diversifying audience.
- The REST API was still supporting this ecosystem and strategy.
- And the number of devices continued to grow.
- As did our traffic…
- 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.
- 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.
- It is a tactic to support our millions of subscribers.
- To support the system that handles 33% of the peak Internet traffic in the US.
- Our content and growing original content strategy.
- And our 1,000+ different device types. This is significant because there is so much diversity in 1,000 different device types!
- 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?
- 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?
- 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.
- 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…
- So, the REST API, which served the original Why perfectly…
- 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.
- 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.
- 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.