SlideShare a Scribd company logo
1 of 101
API Strategy : Know Your
                        Audience
                         Daniel Jacobson
               Director of Engineering, Netflix API

          djacobson@netflix.com
             @daniel_jacobson
http://www.linkedin.com/in/danieljacobson
 http://www.slideshare.net/danieljacobson
Quick Note
Here is the basic outline for this presenation. Feel free to
bounce to the sections that are most interesting to
you, especially if you have seen some of this before:

•   Introduction (slides 3 - 9)
•   Netflix API background (10 – 23)
•   Netflix Product Engineering Organization (24 – 27)
•   Netflix API Resiliency (28 – 52)
•   Netflix API Scaling (53 – 66)
•   Supporting Innovation and API Design Principles (67 – 100)
•   Netflix API Team is Hiring – Contact Information (101)
Who Am I?
• Director of Engineering, Netflix API

• Previously: Director of App Dev, NPR
  – Responsible for and built custom CMS and API
    among other things


• Co-Author of O’Reilly’s “APIs: A Strategy
  Guide”
Who is Netflix?
• Focus is to become the best at streaming TV
  shows and movies internationally
• Netflix is responsible for 30+% of US internet
  traffic at peak times
• Netflix streaming can be enjoyed on more
  than 800 different device types
Key to API Strategy…
Know your audience!
Netflix API - Presentation to PayPal
Netflix API - Presentation to PayPal
Understanding Your Target
  Audience(s) should be the #1
Influence to API Design Decisions
The Netflix API - Background
Netflix
 API
          More than 80,000 flowers
Netflix API Requests by Audience
          At Launch In 2008




                              Netflix Devices
                              Open API Developers
Netflix API - Presentation to PayPal
Netflix API - Presentation to PayPal
Netflix
More than 800          API
unique device types             More than 80,000 flowers
Netflix API Requests by Audience
             From 2011




                         Netflix Devices
                         Open API Developers
Current Emphasis of Netflix API




                         Netflix Devices
Public API




             Internal API
API Focus:
Build the Best Global Streaming Product

    Two aspects of the Streaming Product:
    • Discovery
    • Streaming
Discovery
Discovery
Streaming
Netflix API Powers Discovery on
   Virtually All 800+ Devices
Netflix API - Presentation to PayPal
800+ Device Types
Dozens of Dependencies

Personaliz
                            Movie     Movie     Similar             A/B Test
  ation      User Info                                    Reviews
 Engine
                           Metadata   Ratings   Movies               Engine
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
Netflix API Goals for Internal Audience
• Resiliency in a Distributed Environment

• Scaling with the Demands of the System

• Support Device and UI Innovation
Netflix API Goals for Internal Audience
• Resiliency in a Distributed Environment

• Scaling with the Demands of the System

• Support Device and UI Innovation
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
Circuit Breaker Dashboard
Netflix API - Presentation to PayPal
Call Volume and Health / Last 10 Seconds
Call Volume / Last 2 Minutes
Successful Requests
Successful, But Slower Than Expected
Short-Circuited Requests, Delivering Fallbacks
Timeouts, Delivering Fallbacks
Thread Pool & Task Queue Full, Delivering Fallbacks
Exceptions, Delivering Fallbacks
# + # + # + # / (# + # + # + # + #) = Error Rate
                                                   Error Rate
Status of Fallback Circuit
Requests per Second, Over Last 10 Seconds
SLA Information
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
API




Personaliz
                          Movie     Movie     Similar             A/B Test
  ation      User Info                                  Reviews
 Engine
                         Metadata   Ratings   Movies               Engine
API




                         Fallback


Personaliz
                                Movie     Movie     Similar             A/B Test
  ation      User Info                                        Reviews
 Engine
                               Metadata   Ratings   Movies               Engine
API




                         Fallback


Personaliz
                                Movie     Movie     Similar             A/B Test
  ation      User Info                                        Reviews
 Engine
                               Metadata   Ratings   Movies               Engine
Netflix API Goals for Internal Audience
• Resiliency in a Distributed Environment

• Scaling with the Demands of the System

• Support Device and UI Innovation
800+ Device Types
Netflix API - Presentation to PayPal
Discovery
Growth of Netflix API Requests
                      45
                                                                 41.7

                      40
                                   70x growth in two years!
                      35
Request in Billions




                      30

                      25
                                                        20.7
                      20

                      15

                      10

                       5
                                 0.6
                      -
                                Jan-10                 Jan-11   Jan-12
API




Personaliz
                           Movie        Movie         Similar                   A/B Test
  ation      User Info                                             Reviews
 Engine
                          Metadata      Ratings       Movies                     Engine

             Each API request translates into 5-6 dependency calls on average
                That is about 8-9 billion outgoing calls per day for the API
AWS Cloud
Netflix API - Presentation to PayPal
Netflix API - Presentation to PayPal
Autoscaling
Autoscaling
Netflix API : Requests Per Month
                       35




                       30




                       25
Requests in Billions




                       20




                       15




                       10




                        5




                       -
Netflix API : Requests Per Month
                       35




                       30




                       25
Requests in Billions




                       20




                       15




                       10




                        5




                       -
Netflix API - Presentation to PayPal
Netflix API Goals for Internal Audience
• Resiliency in a Distributed Environment

• Scaling with the Demands of the System

• Support Device and UI Innovation
Netflix device teams are
    constantly running
   multivariate tests and
experimenting with new UIs
Netflix API must support
metadata needs for innovation
    on all devices and UIs
So, what does this mean for API
             design?

 And what does this mean for the
more popular debates in API design?
Debate: XML vs. JSON
Debate: XML vs. JSON
XML vs. JSON - Who Cares?!?!
Debate: XML vs. JSON
• This debate is over-simplified! Increased
  variability in device capabilities and requirements
  means increased approaches to interface with
  them
   – Some devices perform better with hierarchical JSON
     and others with flat object models
   – Different devices may require different XML schemas
   – Some devices prefer full document delivery and
     others prefer streaming bits
   – Etc.
Debate: XML vs. JSON
• Moreover, this should be a non-issue from an
  architectural perspective
  – Design the API to separate out the concepts of
    data gathering from data formatting and delivery
  – Rendering new output formats should be easy
  – This will help tremendously with device
    proliferation
Debate: OAuth vs. Other
• Oauth is the de facto standard
    –   Excellent for unknown developers
    –   Somewhat difficult to deal with
    –   Chatty
    –   (Netflix’s original approach)
• Cookie-based auth
    –   Excellent for device implementations under your control
    –   Significantly less chatty and complicated
    –   Not a good option for unknown developers
    –   (Netflix’s new approach)
• Query-based auth
    – Easy to implement
    – Easy to use
    – Not secure
• Etc…
OAuth vs. Other - Who Cares?!?!
Debate: REST vs. SOAP
REST vs. SOAP - Who Cares?!?!
Debate: Versioning
• Directory structure for version number
  – developer.paypal.com/v1/getPaymentOptions



• Query string for version number
  – developer.paypal.com/getPaymentOptions?version=1



• Versionless API
Who Cares?!?!
Well, actually, I care about this one
Average Life of a TV : About 7-10 Years
Versioning for APIs
                                    1.0

                                      1.5

                                          2.0

                                                3.0?

                                                  4.0?

                                                       5.0?



                     Today

2008   2009   2010   2011    2012     2013      2014    2015   2016   2017   2018   2019   2020
Eliminate Versioning?
                                    1.0

                                      1.5

                                          2.0




                                    New API

                     Today

2008   2009   2010   2011    2012     2013      2014   2015   2016   2017   2018   2019   2020
Benefit to Thinking Versionless
• If you can achieve it, maintenance will be MUCH
  simpler
• If you cannot, it instills better practices
  – Reduces lazy programming
  – Results in fewer versions
  – Results in a cleaner, less brittle system

• And keep in mind, adding new features typically
  does not require a new version…
  – Schematic or structural changes, however, do
So, why don’t I care about most
      of these debates?
Traditional REST-ful Model

REST-ful   REST-ful      REST-ful       REST-ful   REST-ful
Endpoint   Endpoint      Endpoint       Endpoint   Endpoint




                      API Application




                      Data Repository
Comparing just these two devices…
• XBox has Kinect features like voice commands and
  gestures (iPhone does not)
• iPhone has touch features (XBox does not)
• iPhone has small real estate, XBox has a full sized TV
   – different metadata needs
• XBox has more powerful hard drive with better
  memory capacity than the iPhone
• iPhone has different connection rates, XBox is
  connected to stable home wi-fi
• Etc…
Growth of Netflix API Requests
                      45
                                                                 41.7

                      40
                                   70x growth in two years!
                      35
Request in Billions




                      30

                      25
                                                        20.7
                      20

                      15

                      10

                       5
                                 0.6
                      -
                                Jan-10                 Jan-11   Jan-12
What if the API request growth rate
                                looks like this???
                      160


                      140
                              Is this good for the long run???
                      120
Request is Billions




                      100


                       80


                       60


                       40


                       20


                       -
Growth of the Netflix API




  1.5 billion requests per day
  Exploding out to 8-9 billion outgoing calls per day
Netflix API - Presentation to PayPal
<catalog_titles>
 <number_of_results>1140</number_of_results>
 <start_index>0</start_index>
 <results_per_page>10</results_per_page>
 <catalog_title>
 <id>http://api.netflix.com/catalog/titles/movies/60021896</id><title short="Star" regular="Star"></title>
 <box_art small="http://alien2.netflix.com/us/boxshots/tiny/60021896.jpg"
          medium="http://alien2.netflix.com/us/boxshots/small/60021896.jpg"
          large="http://alien2.netflix.com/us/boxshots/large/60021896.jpg"></box_art>
 <link href="http://api.netflix.com/catalog/titles/movies/60021896/synopsis"
          rel="http://schemas.netflix.com/catalog/titles/synopsis" title="synopsis"></link>
 <release_year>2001</release_year>
 <category scheme="http://api.netflix.com/catalog/titles/mpaa_ratings" label="NR"></category>
 <category scheme="http://api.netflix.com/categories/genres" label="Foreign"></category>
 <link href="http://api.netflix.com/catalog/titles/movies/60021896/cast"
          rel="http://schemas.netflix.com/catalog/people.cast" title="cast"></link>
<link href="http://api.netflix.com/catalog/titles/movies/60021896/screen_formats" rel="http://schemas.netflix.com/catalog/titles/screen_formats" title="screen
formats"></link
 <link href="http://api.netflix.com/catalog/titles/movies/60021896/languages_and_audio" rel="http://schemas.netflix.com/catalog/titles/languages_and_audio"
title="languages and audio"></link>
 <average_rating>1.9</average_rating>
 <link href="http://api.netflix.com/catalog/titles/movies/60021896/similars" rel="http://schemas.netflix.com/catalog/titles.similars" title="similars"></link>
 <link href="http://www.netflix.com/Movie/Star/60021896" rel="alternate" title="webpage"></link>
 </catalog_title>
 <catalog_title>
 <id>http://api.netflix.com/catalog/titles/movies/17985448</id><title short="Lone Star" regular="Lone Star"></title>
 <box_art small="http://alien2.netflix.com/us/boxshots/tiny/17985448.jpg" medium="http://alien2.netflix.com/us/boxshots/small/17985448.jpg" large=""></box_art>
 <link href="http://api.netflix.com/catalog/titles/movies/17985448/synopsis" rel="http://schemas.netflix.com/catalog/titles/synopsis" title="synopsis"></link>
 <release_year>1996</release_year>
 <category scheme="http://api.netflix.com/catalog/titles/mpaa_ratings" label="R"></category>
 <category scheme="http://api.netflix.com/categories/genres" label="Drama"></category>
<link href="http://api.netflix.com/catalog/titles/movies/17985448/awards" rel="http://schemas.netflix.com/catalog/titles/awards" title="awards"></link>
 <link href="http://api.netflix.com/catalog/titles/movies/17985448/format_availability" rel="http://schemas.netflix.com/catalog/titles/format_availability"
title="formats"></link>
 <link href="http://api.netflix.com/catalog/titles/movies/17985448/screen_formats" rel="http://schemas.netflix.com/catalog/titles/screen_formats" title="screen
formats"></link>
 <link href="http://api.netflix.com/catalog/titles/movies/17985448/languages_and_audio" rel="http://schemas.netflix.com/catalog/titles/languages_and_audio"
title="languages and audio"></link>
 <average_rating>3.7</average_rating>
 <link href="http://api.netflix.com/catalog/titles/movies/17985448/previews" rel="http://schemas.netflix.com/catalog/titles/previews" title="previews"></link>
 <link href="http://api.netflix.com/catalog/titles/movies/17985448/similars" rel="http://schemas.netflix.com/catalog/titles.similars" title="similars"></link>
 <link href="http://www.netflix.com/Movie/Lone_Star/17985448" rel="alternate" title="webpage"></link>
 </catalog_title>
</catalog_titles>
{"catalog_title":
{"id":"http://api.netflix.com/catalog/titles/movies/60034967",
"title":{"title_short":"Rosencrantz and Guildenstern Are Dead",
"regular":"Rosencrantz and Guildenstern Are Dead"},
"maturity_level":60,
"release_year":"1990",
"average_rating":3.7,
"box_art":{"284pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/ghd/60034967.jpg",
"110pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/large/60034967.jpg",
"38pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/tiny/60034967.jpg",
"64pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/small/60034967.jpg",
"150pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/150/60034967.jpg",
"88pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/88/60034967.jpg",
"124pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/124/60034967.jpg"},
"language":"en",
"web_page":"http://www.netflix.com/Movie/Rosencrantz_and_Guildenstern_Are_Dead/60034967",
"tiny_url":"http://movi.es/ApUP9"},
"meta":{
"expand":["@directors","@bonus_materials","@cast","@awards","@short_synopsis","@synopsis","@box_art","@screen_formats","
@"links":{"id":"http://api.netflix.com/catalog/titles/movies/60034967",
"languages_and_audio":"http://api.netflix.com/catalog/titles/movies/60034967/languages_and_audio",
"title":"http://api.netflix.com/catalog/titles/movies/60034967/title",
"screen_formats":"http://api.netflix.com/catalog/titles/movies/60034967/screen_formats",
"cast":"http://api.netflix.com/catalog/titles/movies/60034967/cast",
"awards":"http://api.netflix.com/catalog/titles/movies/60034967/awards",
"short_synopsis":"http://api.netflix.com/catalog/titles/movies/60034967/short_synopsis",
"box_art":"http://api.netflix.com/catalog/titles/movies/60034967/box_art",
"synopsis":"http://api.netflix.com/catalog/titles/movies/60034967/synopsis",
"directors":"http://api.netflix.com/catalog/titles/movies/60034967/directors",
"similars":"http://api.netflix.com/catalog/titles/movies/60034967/similars",
"format_availability":"http://api.netflix.com/catalog/titles/movies/60034967/format_availability"}
}}
Improve Efficiency of API Requests




Could it have been 300 million requests per day? Or less?
             (Assuming everything else remained the same)
There is a better tool for the job than
   the One-Size-Fits-All REST API
Netflix API - Presentation to PayPal
SQL-Like APIs
+ Much more flexibility than traditional REST
models
+ Allows for a one-size-fits-all dev approach for API
- Still has the server teams dictating the rules
   (although the rules are much more flexible)
----------------------------------------------------------------
= Substantially better for the device world
= May hit scaling problems for increasing number
of device types (due to the increasing variability
across devices)
Netflix API - Presentation to PayPal
We Are Hiring!




If you are interested in helping us solve
these problems, you can contact me at:
                 djacobson@netflix.com
                    @daniel_jacobson
       http://www.linkedin.com/in/danieljacobson
        http://www.slideshare.net/danieljacobson

More Related Content

What's hot

Digital banking on AWS
Digital banking on AWSDigital banking on AWS
Digital banking on AWSPham Anh Vu
 
What i-wish-i-knew-about-aws-certification
What i-wish-i-knew-about-aws-certificationWhat i-wish-i-knew-about-aws-certification
What i-wish-i-knew-about-aws-certificationAndrew Brown
 
Getting Started With ThousandEyes Proof of Concepts: End User Digital Experience
Getting Started With ThousandEyes Proof of Concepts: End User Digital ExperienceGetting Started With ThousandEyes Proof of Concepts: End User Digital Experience
Getting Started With ThousandEyes Proof of Concepts: End User Digital ExperienceThousandEyes
 
Introduction to ibm cloud paks concept license and minimum config public
Introduction to ibm cloud paks concept license and minimum config publicIntroduction to ibm cloud paks concept license and minimum config public
Introduction to ibm cloud paks concept license and minimum config publicPetchpaitoon Krungwong
 
AWS Architecture Case Study: Real-Time Bidding
AWS Architecture Case Study: Real-Time BiddingAWS Architecture Case Study: Real-Time Bidding
AWS Architecture Case Study: Real-Time BiddingAmazon Web Services
 
Microsoft Azure Rights Management
Microsoft Azure Rights ManagementMicrosoft Azure Rights Management
Microsoft Azure Rights ManagementDavid J Rosenthal
 
Microservices - it's déjà vu all over again
Microservices  - it's déjà vu all over againMicroservices  - it's déjà vu all over again
Microservices - it's déjà vu all over againArnon Rotem-Gal-Oz
 
Building High Availability Apps on Lightsail: Load Balancing and Block Storag...
Building High Availability Apps on Lightsail: Load Balancing and Block Storag...Building High Availability Apps on Lightsail: Load Balancing and Block Storag...
Building High Availability Apps on Lightsail: Load Balancing and Block Storag...Amazon Web Services
 
Multi-Cloud Global Server Load Balancing (GSLB)
Multi-Cloud Global Server Load Balancing (GSLB)Multi-Cloud Global Server Load Balancing (GSLB)
Multi-Cloud Global Server Load Balancing (GSLB)Avi Networks
 
Presentation on amazon web servises(aws), by gaurav raturi
Presentation on amazon web servises(aws), by  gaurav raturiPresentation on amazon web servises(aws), by  gaurav raturi
Presentation on amazon web servises(aws), by gaurav raturiGaurav577170
 
K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트
K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트
K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트Amazon Web Services Korea
 

What's hot (20)

Serverless Microservices
Serverless MicroservicesServerless Microservices
Serverless Microservices
 
Digital banking on AWS
Digital banking on AWSDigital banking on AWS
Digital banking on AWS
 
Fury devops conf (1)
Fury devops conf (1)Fury devops conf (1)
Fury devops conf (1)
 
What i-wish-i-knew-about-aws-certification
What i-wish-i-knew-about-aws-certificationWhat i-wish-i-knew-about-aws-certification
What i-wish-i-knew-about-aws-certification
 
Getting Started With ThousandEyes Proof of Concepts: End User Digital Experience
Getting Started With ThousandEyes Proof of Concepts: End User Digital ExperienceGetting Started With ThousandEyes Proof of Concepts: End User Digital Experience
Getting Started With ThousandEyes Proof of Concepts: End User Digital Experience
 
Introduction to ibm cloud paks concept license and minimum config public
Introduction to ibm cloud paks concept license and minimum config publicIntroduction to ibm cloud paks concept license and minimum config public
Introduction to ibm cloud paks concept license and minimum config public
 
SaaS.pptx
SaaS.pptxSaaS.pptx
SaaS.pptx
 
AWS-Data-Migration-module3
AWS-Data-Migration-module3AWS-Data-Migration-module3
AWS-Data-Migration-module3
 
Scaling the Netflix API
Scaling the Netflix APIScaling the Netflix API
Scaling the Netflix API
 
AWS Architecture Case Study: Real-Time Bidding
AWS Architecture Case Study: Real-Time BiddingAWS Architecture Case Study: Real-Time Bidding
AWS Architecture Case Study: Real-Time Bidding
 
Microsoft Azure Rights Management
Microsoft Azure Rights ManagementMicrosoft Azure Rights Management
Microsoft Azure Rights Management
 
Azure camp
Azure campAzure camp
Azure camp
 
Cloud & GCP 101
Cloud & GCP 101Cloud & GCP 101
Cloud & GCP 101
 
Microservices - it's déjà vu all over again
Microservices  - it's déjà vu all over againMicroservices  - it's déjà vu all over again
Microservices - it's déjà vu all over again
 
Introduction to AWS Security
Introduction to AWS SecurityIntroduction to AWS Security
Introduction to AWS Security
 
Building High Availability Apps on Lightsail: Load Balancing and Block Storag...
Building High Availability Apps on Lightsail: Load Balancing and Block Storag...Building High Availability Apps on Lightsail: Load Balancing and Block Storag...
Building High Availability Apps on Lightsail: Load Balancing and Block Storag...
 
Multi-Cloud Global Server Load Balancing (GSLB)
Multi-Cloud Global Server Load Balancing (GSLB)Multi-Cloud Global Server Load Balancing (GSLB)
Multi-Cloud Global Server Load Balancing (GSLB)
 
From Mainframe to Microservices
From Mainframe to MicroservicesFrom Mainframe to Microservices
From Mainframe to Microservices
 
Presentation on amazon web servises(aws), by gaurav raturi
Presentation on amazon web servises(aws), by  gaurav raturiPresentation on amazon web servises(aws), by  gaurav raturi
Presentation on amazon web servises(aws), by gaurav raturi
 
K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트
K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트
K8s, Amazon EKS - 유재석, AWS 솔루션즈 아키텍트
 

Viewers also liked

Top 10 Lessons Learned from the Netflix API - OSCON 2014
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
 
Api Versioning
Api VersioningApi Versioning
Api VersioningBen Ramsey
 
Netflix - Presentation
Netflix - PresentationNetflix - Presentation
Netflix - Presentationtobiasb191
 
Maintaining the Netflix Front Door - Presentation at Intuit Meetup
Maintaining the Netflix Front Door - Presentation at Intuit MeetupMaintaining the Netflix Front Door - Presentation at Intuit Meetup
Maintaining the Netflix Front Door - Presentation at Intuit MeetupDaniel Jacobson
 
Netflix API: Keynote at Disney Tech Conference
Netflix API: Keynote at Disney Tech ConferenceNetflix API: Keynote at Disney Tech Conference
Netflix API: Keynote at Disney Tech ConferenceDaniel Jacobson
 
Франшиза Hobby Games
Франшиза Hobby GamesФраншиза Hobby Games
Франшиза Hobby GamesFranchay
 
Netflix API - Separation of Concerns
Netflix API - Separation of ConcernsNetflix API - Separation of Concerns
Netflix API - Separation of ConcernsDaniel Jacobson
 
The Netflix API for a global service
The Netflix API for a global serviceThe Netflix API for a global service
The Netflix API for a global serviceKatharina Probst
 
Women in tech leadership (Oscon 2016)
Women in tech leadership (Oscon 2016)Women in tech leadership (Oscon 2016)
Women in tech leadership (Oscon 2016)Katharina Probst
 
Punctuated Equilibrium, Celestial Navigation, and APIs
Punctuated Equilibrium, Celestial Navigation, and APIsPunctuated Equilibrium, Celestial Navigation, and APIs
Punctuated Equilibrium, Celestial Navigation, and APIsSam Ramji
 
Set Your Content Free! : Case Studies from Netflix and NPR
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
 
API Revolutions : Netflix's API Redesign
API Revolutions : Netflix's API RedesignAPI Revolutions : Netflix's API Redesign
API Revolutions : Netflix's API RedesignDaniel Jacobson
 
The Netflix API Platform for Server-Side Scripting
The Netflix API Platform for Server-Side ScriptingThe Netflix API Platform for Server-Side Scripting
The Netflix API Platform for Server-Side ScriptingKatharina Probst
 
Netflix Edge Engineering Open House Presentations - June 9, 2016
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
 
Best Practices for Architecting a Pragmatic Web API.
Best Practices for Architecting a Pragmatic Web API.Best Practices for Architecting a Pragmatic Web API.
Best Practices for Architecting a Pragmatic Web API.Mario Cardinal
 
PayPal Digital Marketing Strategy
PayPal Digital Marketing StrategyPayPal Digital Marketing Strategy
PayPal Digital Marketing StrategyShalee Blackmer
 

Viewers also liked (20)

Top 10 Lessons Learned from the Netflix API - OSCON 2014
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 2014
 
Culture
CultureCulture
Culture
 
Netflix presentation
Netflix presentationNetflix presentation
Netflix presentation
 
Api Versioning
Api VersioningApi Versioning
Api Versioning
 
Netflix - Presentation
Netflix - PresentationNetflix - Presentation
Netflix - Presentation
 
Maintaining the Netflix Front Door - Presentation at Intuit Meetup
Maintaining the Netflix Front Door - Presentation at Intuit MeetupMaintaining the Netflix Front Door - Presentation at Intuit Meetup
Maintaining the Netflix Front Door - Presentation at Intuit Meetup
 
Netflix API: Keynote at Disney Tech Conference
Netflix API: Keynote at Disney Tech ConferenceNetflix API: Keynote at Disney Tech Conference
Netflix API: Keynote at Disney Tech Conference
 
Франшиза Hobby Games
Франшиза Hobby GamesФраншиза Hobby Games
Франшиза Hobby Games
 
Evolving the Netflix API
Evolving the Netflix APIEvolving the Netflix API
Evolving the Netflix API
 
Netflix API - Separation of Concerns
Netflix API - Separation of ConcernsNetflix API - Separation of Concerns
Netflix API - Separation of Concerns
 
The Netflix API for a global service
The Netflix API for a global serviceThe Netflix API for a global service
The Netflix API for a global service
 
Women in tech leadership (Oscon 2016)
Women in tech leadership (Oscon 2016)Women in tech leadership (Oscon 2016)
Women in tech leadership (Oscon 2016)
 
Punctuated Equilibrium, Celestial Navigation, and APIs
Punctuated Equilibrium, Celestial Navigation, and APIsPunctuated Equilibrium, Celestial Navigation, and APIs
Punctuated Equilibrium, Celestial Navigation, and APIs
 
Set Your Content Free! : Case Studies from Netflix and NPR
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 NPR
 
Microservices at Netflix
Microservices at NetflixMicroservices at Netflix
Microservices at Netflix
 
API Revolutions : Netflix's API Redesign
API Revolutions : Netflix's API RedesignAPI Revolutions : Netflix's API Redesign
API Revolutions : Netflix's API Redesign
 
The Netflix API Platform for Server-Side Scripting
The Netflix API Platform for Server-Side ScriptingThe Netflix API Platform for Server-Side Scripting
The Netflix API Platform for Server-Side Scripting
 
Netflix Edge Engineering Open House Presentations - June 9, 2016
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, 2016
 
Best Practices for Architecting a Pragmatic Web API.
Best Practices for Architecting a Pragmatic Web API.Best Practices for Architecting a Pragmatic Web API.
Best Practices for Architecting a Pragmatic Web API.
 
PayPal Digital Marketing Strategy
PayPal Digital Marketing StrategyPayPal Digital Marketing Strategy
PayPal Digital Marketing Strategy
 

Similar to Netflix API - Presentation to PayPal

Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SFTechniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SFDaniel Jacobson
 
APIs for Internal Audiences - Netflix - App Dev Conference
APIs for Internal Audiences - Netflix - App Dev ConferenceAPIs for Internal Audiences - Netflix - App Dev Conference
APIs for Internal Audiences - Netflix - App Dev ConferenceDaniel Jacobson
 
Scaling the Netflix API - OSCON
Scaling the Netflix API - OSCONScaling the Netflix API - OSCON
Scaling the Netflix API - OSCONDaniel Jacobson
 
Scaling the Netflix API - From Atlassian Dev Den
Scaling the Netflix API - From Atlassian Dev DenScaling the Netflix API - From Atlassian Dev Den
Scaling the Netflix API - From Atlassian Dev DenDaniel Jacobson
 
Maintaining the Front Door to Netflix : The Netflix API
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
 
Maintaining the Front Door to Netflix
Maintaining the Front Door to NetflixMaintaining the Front Door to Netflix
Maintaining the Front Door to NetflixBenjamin Schmaus
 
API Design - When to buck the trend (Webcast)
API Design - When to buck the trend (Webcast)API Design - When to buck the trend (Webcast)
API Design - When to buck the trend (Webcast)Apigee | Google Cloud
 
AWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian Army
AWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian ArmyAWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian Army
AWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian ArmyAriel Tseitlin
 
Evaluating and Testing Web APIs
Evaluating and Testing Web APIsEvaluating and Testing Web APIs
Evaluating and Testing Web APIsSmartBear
 
Netflix API : BAPI 2011 Presentation : SF
Netflix API : BAPI 2011 Presentation : SFNetflix API : BAPI 2011 Presentation : SF
Netflix API : BAPI 2011 Presentation : SFDaniel Jacobson
 
The future-of-netflix-api
The future-of-netflix-apiThe future-of-netflix-api
The future-of-netflix-apiDaniel Jacobson
 
Presentation to ESPN about the Netflix API
Presentation to ESPN about the Netflix APIPresentation to ESPN about the Netflix API
Presentation to ESPN about the Netflix APIDaniel Jacobson
 
Bringing the App Economy to Enterprise IT
Bringing the App Economy to Enterprise ITBringing the App Economy to Enterprise IT
Bringing the App Economy to Enterprise ITApigee | Google Cloud
 
A Service-Based Architecture for Multi-domain Search on the Web
A Service-Based Architecture for Multi-domain Search on the WebA Service-Based Architecture for Multi-domain Search on the Web
A Service-Based Architecture for Multi-domain Search on the WebAlessandro Bozzon
 
Clickslide Datadipity Beta V1
Clickslide Datadipity Beta V1Clickslide Datadipity Beta V1
Clickslide Datadipity Beta V1Gabriel Ortiz
 
戦う情シス!全社 API で社内アプリ開発を加速させよう
戦う情シス!全社 API で社内アプリ開発を加速させよう戦う情シス!全社 API で社内アプリ開発を加速させよう
戦う情シス!全社 API で社内アプリ開発を加速させようYuki Hattori
 
App Engine overview (Android meetup 06-10)
App Engine overview (Android meetup 06-10)App Engine overview (Android meetup 06-10)
App Engine overview (Android meetup 06-10)jasonacooper
 

Similar to Netflix API - Presentation to PayPal (20)

Techniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SFTechniques for Scaling the Netflix API - QCon SF
Techniques for Scaling the Netflix API - QCon SF
 
APIs for Internal Audiences - Netflix - App Dev Conference
APIs for Internal Audiences - Netflix - App Dev ConferenceAPIs for Internal Audiences - Netflix - App Dev Conference
APIs for Internal Audiences - Netflix - App Dev Conference
 
Scaling the Netflix API - OSCON
Scaling the Netflix API - OSCONScaling the Netflix API - OSCON
Scaling the Netflix API - OSCON
 
Scaling the Netflix API - From Atlassian Dev Den
Scaling the Netflix API - From Atlassian Dev DenScaling the Netflix API - From Atlassian Dev Den
Scaling the Netflix API - From Atlassian Dev Den
 
Maintaining the Front Door to Netflix : The Netflix API
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 API
 
Maintaining the Front Door to Netflix
Maintaining the Front Door to NetflixMaintaining the Front Door to Netflix
Maintaining the Front Door to Netflix
 
API Design - When to buck the trend (Webcast)
API Design - When to buck the trend (Webcast)API Design - When to buck the trend (Webcast)
API Design - When to buck the trend (Webcast)
 
AWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian Army
AWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian ArmyAWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian Army
AWS Re:Invent 2012 - Chaos Monkey & The Netflix Simian Army
 
Evaluating and Testing Web APIs
Evaluating and Testing Web APIsEvaluating and Testing Web APIs
Evaluating and Testing Web APIs
 
Huge: Running an API at Scale
Huge: Running an API at ScaleHuge: Running an API at Scale
Huge: Running an API at Scale
 
Netflix API : BAPI 2011 Presentation : SF
Netflix API : BAPI 2011 Presentation : SFNetflix API : BAPI 2011 Presentation : SF
Netflix API : BAPI 2011 Presentation : SF
 
The future-of-netflix-api
The future-of-netflix-apiThe future-of-netflix-api
The future-of-netflix-api
 
Presentation to ESPN about the Netflix API
Presentation to ESPN about the Netflix APIPresentation to ESPN about the Netflix API
Presentation to ESPN about the Netflix API
 
Samepoint API
Samepoint APISamepoint API
Samepoint API
 
Bringing the App Economy to Enterprise IT
Bringing the App Economy to Enterprise ITBringing the App Economy to Enterprise IT
Bringing the App Economy to Enterprise IT
 
A Service-Based Architecture for Multi-domain Search on the Web
A Service-Based Architecture for Multi-domain Search on the WebA Service-Based Architecture for Multi-domain Search on the Web
A Service-Based Architecture for Multi-domain Search on the Web
 
Clickslide Datadipity Beta V1
Clickslide Datadipity Beta V1Clickslide Datadipity Beta V1
Clickslide Datadipity Beta V1
 
Your API is not a Website!
Your API is not a Website!Your API is not a Website!
Your API is not a Website!
 
戦う情シス!全社 API で社内アプリ開発を加速させよう
戦う情シス!全社 API で社内アプリ開発を加速させよう戦う情シス!全社 API で社内アプリ開発を加速させよう
戦う情シス!全社 API で社内アプリ開発を加速させよう
 
App Engine overview (Android meetup 06-10)
App Engine overview (Android meetup 06-10)App Engine overview (Android meetup 06-10)
App Engine overview (Android meetup 06-10)
 

More from Daniel Jacobson

Why API? - Business of APIs Conference
Why API? - Business of APIs ConferenceWhy API? - Business of APIs Conference
Why API? - Business of APIs ConferenceDaniel Jacobson
 
Redesigning the Netflix API - OSCON
Redesigning the Netflix API - OSCONRedesigning the Netflix API - OSCON
Redesigning the Netflix API - OSCONDaniel Jacobson
 
History and Future of the Netflix API - Mashery Evolution of Distribution
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 2010
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: OSCON2010
NPR: Digital Distribution Strategy: OSCON2010NPR: Digital Distribution Strategy: OSCON2010
NPR: Digital Distribution Strategy: OSCON2010Daniel Jacobson
 
NPR's Digital Distribution and Mobile Strategy
NPR's Digital Distribution and Mobile StrategyNPR's Digital Distribution and Mobile Strategy
NPR's Digital Distribution and Mobile StrategyDaniel Jacobson
 
NPR API Usage and Metrics
NPR API Usage and MetricsNPR API Usage and Metrics
NPR API Usage and MetricsDaniel Jacobson
 
OpenID Adoption UX Summit
OpenID Adoption UX SummitOpenID Adoption UX Summit
OpenID Adoption UX SummitDaniel Jacobson
 

More from Daniel Jacobson (10)

Why API? - Business of APIs Conference
Why API? - Business of APIs ConferenceWhy API? - Business of APIs Conference
Why API? - Business of APIs Conference
 
Netflix API
Netflix APINetflix API
Netflix API
 
Redesigning the Netflix API - OSCON
Redesigning the Netflix API - OSCONRedesigning the Netflix API - OSCON
Redesigning the Netflix API - OSCON
 
History and Future of the Netflix API - Mashery Evolution of Distribution
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 Distribution
 
NPR Presentation at Wolfram Data Summit 2010
NPR Presentation at Wolfram Data Summit 2010NPR Presentation at Wolfram Data Summit 2010
NPR Presentation at Wolfram Data Summit 2010
 
NPR: Digital Distribution Strategy: OSCON2010
NPR: Digital Distribution Strategy: OSCON2010NPR: Digital Distribution Strategy: OSCON2010
NPR: Digital Distribution Strategy: OSCON2010
 
NPR's Digital Distribution and Mobile Strategy
NPR's Digital Distribution and Mobile StrategyNPR's Digital Distribution and Mobile Strategy
NPR's Digital Distribution and Mobile Strategy
 
NPR API Usage and Metrics
NPR API Usage and MetricsNPR API Usage and Metrics
NPR API Usage and Metrics
 
OpenID Adoption UX Summit
OpenID Adoption UX SummitOpenID Adoption UX Summit
OpenID Adoption UX Summit
 
NPR : Examples of COPE
NPR : Examples of COPENPR : Examples of COPE
NPR : Examples of COPE
 

Recently uploaded

Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarPrecisely
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 

Recently uploaded (20)

201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity Webinar
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 

Netflix API - Presentation to PayPal

  • 1. API Strategy : Know Your Audience Daniel Jacobson Director of Engineering, Netflix API djacobson@netflix.com @daniel_jacobson http://www.linkedin.com/in/danieljacobson http://www.slideshare.net/danieljacobson
  • 2. Quick Note Here is the basic outline for this presenation. Feel free to bounce to the sections that are most interesting to you, especially if you have seen some of this before: • Introduction (slides 3 - 9) • Netflix API background (10 – 23) • Netflix Product Engineering Organization (24 – 27) • Netflix API Resiliency (28 – 52) • Netflix API Scaling (53 – 66) • Supporting Innovation and API Design Principles (67 – 100) • Netflix API Team is Hiring – Contact Information (101)
  • 3. Who Am I? • Director of Engineering, Netflix API • Previously: Director of App Dev, NPR – Responsible for and built custom CMS and API among other things • Co-Author of O’Reilly’s “APIs: A Strategy Guide”
  • 4. Who is Netflix? • Focus is to become the best at streaming TV shows and movies internationally • Netflix is responsible for 30+% of US internet traffic at peak times • Netflix streaming can be enjoyed on more than 800 different device types
  • 5. Key to API Strategy…
  • 9. Understanding Your Target Audience(s) should be the #1 Influence to API Design Decisions
  • 10. The Netflix API - Background
  • 11. Netflix API More than 80,000 flowers
  • 12. Netflix API Requests by Audience At Launch In 2008 Netflix Devices Open API Developers
  • 15. Netflix More than 800 API unique device types More than 80,000 flowers
  • 16. Netflix API Requests by Audience From 2011 Netflix Devices Open API Developers
  • 17. Current Emphasis of Netflix API Netflix Devices
  • 18. Public API Internal API
  • 19. API Focus: Build the Best Global Streaming Product Two aspects of the Streaming Product: • Discovery • Streaming
  • 23. Netflix API Powers Discovery on Virtually All 800+ Devices
  • 26. Dozens of Dependencies Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 27. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 28. Netflix API Goals for Internal Audience • Resiliency in a Distributed Environment • Scaling with the Demands of the System • Support Device and UI Innovation
  • 29. Netflix API Goals for Internal Audience • Resiliency in a Distributed Environment • Scaling with the Demands of the System • Support Device and UI Innovation
  • 30. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 31. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 32. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 33. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 36. Call Volume and Health / Last 10 Seconds
  • 37. Call Volume / Last 2 Minutes
  • 39. Successful, But Slower Than Expected
  • 42. Thread Pool & Task Queue Full, Delivering Fallbacks
  • 44. # + # + # + # / (# + # + # + # + #) = Error Rate Error Rate
  • 46. Requests per Second, Over Last 10 Seconds
  • 48. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 49. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 50. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 51. API Fallback Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 52. API Fallback Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine
  • 53. Netflix API Goals for Internal Audience • Resiliency in a Distributed Environment • Scaling with the Demands of the System • Support Device and UI Innovation
  • 57. Growth of Netflix API Requests 45 41.7 40 70x growth in two years! 35 Request in Billions 30 25 20.7 20 15 10 5 0.6 - Jan-10 Jan-11 Jan-12
  • 58. API Personaliz Movie Movie Similar A/B Test ation User Info Reviews Engine Metadata Ratings Movies Engine Each API request translates into 5-6 dependency calls on average That is about 8-9 billion outgoing calls per day for the API
  • 64. Netflix API : Requests Per Month 35 30 25 Requests in Billions 20 15 10 5 -
  • 65. Netflix API : Requests Per Month 35 30 25 Requests in Billions 20 15 10 5 -
  • 67. Netflix API Goals for Internal Audience • Resiliency in a Distributed Environment • Scaling with the Demands of the System • Support Device and UI Innovation
  • 68. Netflix device teams are constantly running multivariate tests and experimenting with new UIs
  • 69. Netflix API must support metadata needs for innovation on all devices and UIs
  • 70. So, what does this mean for API design? And what does this mean for the more popular debates in API design?
  • 73. XML vs. JSON - Who Cares?!?!
  • 74. Debate: XML vs. JSON • This debate is over-simplified! Increased variability in device capabilities and requirements means increased approaches to interface with them – Some devices perform better with hierarchical JSON and others with flat object models – Different devices may require different XML schemas – Some devices prefer full document delivery and others prefer streaming bits – Etc.
  • 75. Debate: XML vs. JSON • Moreover, this should be a non-issue from an architectural perspective – Design the API to separate out the concepts of data gathering from data formatting and delivery – Rendering new output formats should be easy – This will help tremendously with device proliferation
  • 76. Debate: OAuth vs. Other • Oauth is the de facto standard – Excellent for unknown developers – Somewhat difficult to deal with – Chatty – (Netflix’s original approach) • Cookie-based auth – Excellent for device implementations under your control – Significantly less chatty and complicated – Not a good option for unknown developers – (Netflix’s new approach) • Query-based auth – Easy to implement – Easy to use – Not secure • Etc…
  • 77. OAuth vs. Other - Who Cares?!?!
  • 79. REST vs. SOAP - Who Cares?!?!
  • 80. Debate: Versioning • Directory structure for version number – developer.paypal.com/v1/getPaymentOptions • Query string for version number – developer.paypal.com/getPaymentOptions?version=1 • Versionless API
  • 82. Well, actually, I care about this one
  • 83. Average Life of a TV : About 7-10 Years
  • 84. Versioning for APIs 1.0 1.5 2.0 3.0? 4.0? 5.0? Today 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
  • 85. Eliminate Versioning? 1.0 1.5 2.0 New API Today 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
  • 86. Benefit to Thinking Versionless • If you can achieve it, maintenance will be MUCH simpler • If you cannot, it instills better practices – Reduces lazy programming – Results in fewer versions – Results in a cleaner, less brittle system • And keep in mind, adding new features typically does not require a new version… – Schematic or structural changes, however, do
  • 87. So, why don’t I care about most of these debates?
  • 88. Traditional REST-ful Model REST-ful REST-ful REST-ful REST-ful REST-ful Endpoint Endpoint Endpoint Endpoint Endpoint API Application Data Repository
  • 89. Comparing just these two devices… • XBox has Kinect features like voice commands and gestures (iPhone does not) • iPhone has touch features (XBox does not) • iPhone has small real estate, XBox has a full sized TV – different metadata needs • XBox has more powerful hard drive with better memory capacity than the iPhone • iPhone has different connection rates, XBox is connected to stable home wi-fi • Etc…
  • 90. Growth of Netflix API Requests 45 41.7 40 70x growth in two years! 35 Request in Billions 30 25 20.7 20 15 10 5 0.6 - Jan-10 Jan-11 Jan-12
  • 91. What if the API request growth rate looks like this??? 160 140 Is this good for the long run??? 120 Request is Billions 100 80 60 40 20 -
  • 92. Growth of the Netflix API 1.5 billion requests per day Exploding out to 8-9 billion outgoing calls per day
  • 94. <catalog_titles> <number_of_results>1140</number_of_results> <start_index>0</start_index> <results_per_page>10</results_per_page> <catalog_title> <id>http://api.netflix.com/catalog/titles/movies/60021896</id><title short="Star" regular="Star"></title> <box_art small="http://alien2.netflix.com/us/boxshots/tiny/60021896.jpg" medium="http://alien2.netflix.com/us/boxshots/small/60021896.jpg" large="http://alien2.netflix.com/us/boxshots/large/60021896.jpg"></box_art> <link href="http://api.netflix.com/catalog/titles/movies/60021896/synopsis" rel="http://schemas.netflix.com/catalog/titles/synopsis" title="synopsis"></link> <release_year>2001</release_year> <category scheme="http://api.netflix.com/catalog/titles/mpaa_ratings" label="NR"></category> <category scheme="http://api.netflix.com/categories/genres" label="Foreign"></category> <link href="http://api.netflix.com/catalog/titles/movies/60021896/cast" rel="http://schemas.netflix.com/catalog/people.cast" title="cast"></link> <link href="http://api.netflix.com/catalog/titles/movies/60021896/screen_formats" rel="http://schemas.netflix.com/catalog/titles/screen_formats" title="screen formats"></link <link href="http://api.netflix.com/catalog/titles/movies/60021896/languages_and_audio" rel="http://schemas.netflix.com/catalog/titles/languages_and_audio" title="languages and audio"></link> <average_rating>1.9</average_rating> <link href="http://api.netflix.com/catalog/titles/movies/60021896/similars" rel="http://schemas.netflix.com/catalog/titles.similars" title="similars"></link> <link href="http://www.netflix.com/Movie/Star/60021896" rel="alternate" title="webpage"></link> </catalog_title> <catalog_title> <id>http://api.netflix.com/catalog/titles/movies/17985448</id><title short="Lone Star" regular="Lone Star"></title> <box_art small="http://alien2.netflix.com/us/boxshots/tiny/17985448.jpg" medium="http://alien2.netflix.com/us/boxshots/small/17985448.jpg" large=""></box_art> <link href="http://api.netflix.com/catalog/titles/movies/17985448/synopsis" rel="http://schemas.netflix.com/catalog/titles/synopsis" title="synopsis"></link> <release_year>1996</release_year> <category scheme="http://api.netflix.com/catalog/titles/mpaa_ratings" label="R"></category> <category scheme="http://api.netflix.com/categories/genres" label="Drama"></category> <link href="http://api.netflix.com/catalog/titles/movies/17985448/awards" rel="http://schemas.netflix.com/catalog/titles/awards" title="awards"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/format_availability" rel="http://schemas.netflix.com/catalog/titles/format_availability" title="formats"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/screen_formats" rel="http://schemas.netflix.com/catalog/titles/screen_formats" title="screen formats"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/languages_and_audio" rel="http://schemas.netflix.com/catalog/titles/languages_and_audio" title="languages and audio"></link> <average_rating>3.7</average_rating> <link href="http://api.netflix.com/catalog/titles/movies/17985448/previews" rel="http://schemas.netflix.com/catalog/titles/previews" title="previews"></link> <link href="http://api.netflix.com/catalog/titles/movies/17985448/similars" rel="http://schemas.netflix.com/catalog/titles.similars" title="similars"></link> <link href="http://www.netflix.com/Movie/Lone_Star/17985448" rel="alternate" title="webpage"></link> </catalog_title> </catalog_titles>
  • 95. {"catalog_title": {"id":"http://api.netflix.com/catalog/titles/movies/60034967", "title":{"title_short":"Rosencrantz and Guildenstern Are Dead", "regular":"Rosencrantz and Guildenstern Are Dead"}, "maturity_level":60, "release_year":"1990", "average_rating":3.7, "box_art":{"284pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/ghd/60034967.jpg", "110pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/large/60034967.jpg", "38pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/tiny/60034967.jpg", "64pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/small/60034967.jpg", "150pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/150/60034967.jpg", "88pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/88/60034967.jpg", "124pix_w":"http://cdn-7.nflximg.com/en_US/boxshots/124/60034967.jpg"}, "language":"en", "web_page":"http://www.netflix.com/Movie/Rosencrantz_and_Guildenstern_Are_Dead/60034967", "tiny_url":"http://movi.es/ApUP9"}, "meta":{ "expand":["@directors","@bonus_materials","@cast","@awards","@short_synopsis","@synopsis","@box_art","@screen_formats"," @"links":{"id":"http://api.netflix.com/catalog/titles/movies/60034967", "languages_and_audio":"http://api.netflix.com/catalog/titles/movies/60034967/languages_and_audio", "title":"http://api.netflix.com/catalog/titles/movies/60034967/title", "screen_formats":"http://api.netflix.com/catalog/titles/movies/60034967/screen_formats", "cast":"http://api.netflix.com/catalog/titles/movies/60034967/cast", "awards":"http://api.netflix.com/catalog/titles/movies/60034967/awards", "short_synopsis":"http://api.netflix.com/catalog/titles/movies/60034967/short_synopsis", "box_art":"http://api.netflix.com/catalog/titles/movies/60034967/box_art", "synopsis":"http://api.netflix.com/catalog/titles/movies/60034967/synopsis", "directors":"http://api.netflix.com/catalog/titles/movies/60034967/directors", "similars":"http://api.netflix.com/catalog/titles/movies/60034967/similars", "format_availability":"http://api.netflix.com/catalog/titles/movies/60034967/format_availability"} }}
  • 96. Improve Efficiency of API Requests Could it have been 300 million requests per day? Or less? (Assuming everything else remained the same)
  • 97. There is a better tool for the job than the One-Size-Fits-All REST API
  • 99. SQL-Like APIs + Much more flexibility than traditional REST models + Allows for a one-size-fits-all dev approach for API - Still has the server teams dictating the rules (although the rules are much more flexible) ---------------------------------------------------------------- = Substantially better for the device world = May hit scaling problems for increasing number of device types (due to the increasing variability across devices)
  • 101. We Are Hiring! If you are interested in helping us solve these problems, you can contact me at: djacobson@netflix.com @daniel_jacobson http://www.linkedin.com/in/danieljacobson http://www.slideshare.net/danieljacobson

Editor's Notes

  1. Whether your audience is a bunch of programmers at a Hackday event,
  2. Or a huge population of users who consume your APIs through a range of applications…
  3. Understanding Your Target Audience(s) should be the #1 Influence to API Design Decisions!
  4. To better understand how target audiences influenced the Netflix API, the following slides will provide background on the Netflix API history.
  5. When the Netflix API launched three years ago, it was to “let 1,000 flowers bloom”. It was exclusively a public API.Today, that API still exists with about 80,000 flowers.
  6. At the time of launch, it was exclusively a public API, with all of the traffic coming in from third-party developers.
  7. These are some examples of the various flowers that have bloomed from this program.
  8. Then streaming started taking off for Netflix, first with computer-based streaming…
  9. And now the model looks more like this, with hundreds of Netflix-branded device implementations running off of the API. The third-party developers are just one of the many consumers of the API.
  10. In this new model, however, the public API represents only about .3% of the total API traffic!
  11. As a result, the emphasis around the API for Netflix is innovation and support for the Netflix-branded device implementations.
  12. 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.
  13. To better understand the strategy, I should explain the basics of what the Netflix API supports. There are basically two types of interactions between Netflix customers and our streaming application… Discovery and Streaming.
  14. Discovery is basically any event with a title other than streaming it. That includes browsing titles, looking for something watch, etc.
  15. It also includes actions such as rating the title, adding it to your instant queue, etc.
  16. Once the customer has identified a title to watch through the Discovery experience, the user can then play that title. Once the Play button is selected, the customer is sent to a different internal service that focuses on handling the streaming. That streaming service also interacts with our CDNs to actually deliver the streaming bits to the device for playback.
  17. The API powers the Discovery experience. The rest of these slides will only focus on Discovery, not Streaming.
  18. I like to think of the Netflix engineering teams that support development and innovation for Discovery as being shaped like an hourglass…
  19. In the top end of the hourglass, we have our device and UI teams who build out great user experiences on Netflix-branded devices. There are currently more than 800 different device types that we support. To put that into perspective, there are a few hundred more device types that we support than engineers at Netflix.
  20. At the bottom end of the hourglass, there are several dozen dependency teams who focus on things like metadata, algorithms, authentication services, A/B test engines, etc.
  21. The API is in the skinny part of the hourglass, brokering content and algorithmic output from the dependency layers to the UIs. In this model, each team specializes in solving specific problems for the product pipeline, making each team (and each engineer) highly impactful for the success of the company.
  22. With respect to product resiliency, the API plays a key role. None of our dependency services have SLAs of 100%. Given our unique position in the stack as being the last point just before delivery to our users, the API can serve a critical role in protecting our customers from various failures throughout the system.
  23. In the old world, the system was vulnerable to such failures. For example, if one of our dependency services fails…
  24. Such an outage could have resulted in an outage in the API.
  25. And if that outage likely would have cascaded to have some kind of substantive impact on the devices. The challenge for the API team is to be resilient against dependency outages, to ultimately insulate Netflix customers from low level system problems.
  26. To achieve this, we implemented a series of circuit breakers for each library that we depend on. Each circuit breaker controls the interaction between the API and that dependency. This image is a view of the dependency monitor that allows us to view the health and activity of each dependency. This dashboard is designed to give a real-time view of what is happening with these dependencies (over the last two minutes). We have other dashboards that provide insight into longer-term trends, day-over-day views, etc.
  27. This is a view of asingle circuit.
  28. This circle represents the call volume and health of the dependency over the last 10 seconds. This circle is meant to be a visual indicator for health. The circle is green for healthy, yellow for borderline, and red for unhealthy. Moreover, the size of the circle represents the call volumes, where bigger circles mean more traffic.
  29. The blue line represents the traffic trends over the last two minutes for this dependency.
  30. The green number shows the number of successful calls to this dependency over the last two minutes.
  31. The yellow number shows the number of latent calls into the dependency. These calls ultimately return successful responses, but slower than expected.
  32. The blue number shows the number of calls that were handled by the short-circuited fallback mechanisms. That is, if the circuit gets tripped, the blue number will start to go up.
  33. The orange number shows the number of calls that have timed out, resulting in fallback responses.
  34. The purple number shows the number of calls that fail due to queuing issues, resulting in fallback responses.
  35. The red number shows the number of exceptions, resulting in fallback responses.
  36. The error rate is calculated from the total number of error and fallback responses divided by the total number calls handled.
  37. If the error rate exceeds a certain number, the circuit to the fallback scenario is automatically opened. When it returns below that threshold, the circuit is closed again.
  38. The dashboard also shows host and cluster information for the dependency.
  39. As well as information about our SLAs.
  40. So, going back to the engineering diagram…
  41. If that same service fails today…
  42. We simply disconnect from that service.
  43. And replace it with an appropriate fallback.
  44. Keeping our customers happy, even if the experience may be slightly degraded. It is important to note that different dependency libraries have different fallback scenarios. And some are more resilient than others. But the overall sentiment here is accurate at a high level.
  45. From a scalability perspective, let’s go back to the devices… We have a growing number of devices…
  46. And a huge population of users who consume your APIs through a range of applications…
  47. We are continually create richer experiences on these various devices. And our users are spending lots of time on such experiences.
  48. As a result, the API traffic (in terms of incoming requests) is growing at a very high rate. In the last two years, the API requests has grown by 70x, going from 600 million requests a month to about 42 billion a month. Scaling a system in those conditions is not a trivial task.
  49. At our current scale, we are support more than 1.5 billion incoming requests per day. Each of those requests actually explodes out to an average of 5-6 dependency calls. That means that the API makes about 8-9 billion outgoing calls per day.
  50. Of course, we are using Amazon Web Services (EC2) to host our systems, which goes a long way to helping us scale (although it is not, in itself, a silver bullet).
  51. So, rather than having systems team spending a ton of time trying build new servers, patch and upgrade existing ones, etc., in server rooms such as this one…
  52. We spend time in tools such as this one, created by Netflix staff, to help us manage our instance types and counts.
  53. Another feature afforded to us through AWS to help us scale is Autoscaling. This is the Netflix API request rates over a span of time. The red line represents a potential capacity needed in a data center to ensure that the spikes could be handled without spending a ton more than is needed for the really unlikely scenarios.
  54. The Autoscaling, instead of buying new servers based on projected spikes in traffic and having systems administrators add them to the farm, the cloud can dynamically and automatically add and remove servers based on need.
  55. Similarly, as our overall traffic grows over time…
  56. Our overall server counts can increase as well, commensurate with that growth.
  57. Finally, as we continue to expand internationally, we can easily scale up in new regions, closer to the customer base that we are trying to serve, as long as Amazon has a location near there.
  58. Finally, the API team needs to support innovation. This is the most important goal, although if the other two don’t have a good foundation, then this one is not possible.
  59. One of the more common debates in the API marketplace is whether or the API should support XML or JSON (or both). Here is ProgrammableWeb’s breakdown of the format war. About a third of the APIs they are aware of use JSON and two-thirds use XML.
  60. The migration to JSON is mostly due to improved language support and the slenderness of JSON’s payload. As a result, the debate seems to be shifting pretty quickly towards JSON.
  61. My thought on this debate is… WHO CARES about the debate itself? Ultimately, it will come down to knowing the audiences of the API and making sure that the API supports those audiences effectively.
  62. Another prominent debate is how to authenticate users, with OAuth being the de facto standard.
  63. My thought on that debate is… WHO CARES about the debate. Again, know your audiences for the API and that will go a far way to making the right decisions. Netflix, for example, started out using OAuth exclusively for the third-party developers. Now, for the streaming device support, many of them use cookie-based authentication because the API team has a different relationship with the device teams than we do with the third-party developers (who still use OAuth).
  64. Another populate debate around APIs is on REST vs. SOAP. According to ProgrammableWeb, over the last half-year, REST (which had already gained prominence) has become even more dominant, representing about ¾ of every API.
  65. My thought on that debate is… WHO CARES?!?! Again, the right implementation will be based on you audience. I will a little more about this particular debate later in the presentation.
  66. The next debate, Versioning!
  67. WHO CARES about this one?
  68. I do care about the bigger question about the need for versioning. If implemented, however, I don’t have a strong stance on how it gets implemented. Ultimately, those questions need to be addressed on an implementation-to-implementation basis, based on the audience needs and the architectural sensibilities for the API team.
  69. The problem with versioning, particularly in supporting as many devices at Netflix does, is that many of these devices cannot be updated. And in the case of TVs, for example, they sit on people’s walls for 7-10 years with limited (if even possible) options for updating the app. As a result, any API version that is published that a TV app calls needs to be supported for that long duration.
  70. Ultimately, you may end up supporting a large, and growing, number of API versions. The more you support, the tougher it is to maintain and the greater the burden it places on your innovation. Right now, Netflix has a 1.0, 1.5 and 2.0 API. You can quickly imagine in the next 10 years the possibility of a 3.0, 4.0, 5.0, 6.0, etc., making the codebase daunting, ugly and brittle.
  71. This is not often possible, but thinking about a versionless API has many benefits, solving many of the problems discussed in the previous slide. It introduces some other problems, but if done right, the benefits could outweigh the challenges.
  72. In typical one-size-fits-all REST-ful APIs, the model is quite simple. A backend repository (or distributed repositories) stores data leveraged by an API application that exposes such data through REST-ful endpoints. Those REST-ful endpoints are typically managed in a highly vertical, resource-oriented way, treating the resources as granular normalized data access points. Problems start to surface with this model, however, when you sit 800+ different device types on top of it. The degree of variability across such a breadth of devices really starts to expose weaknesses in this model.
  73. Another issue that gets exposed in REST-ful models is in its chattiness. The Netflix API growth rate is a result of several factors, including more users, more device types, richer UI experiences, more time spent by users, etc.
  74. If this same growth rate continues, the request numbers could start to get very large resulting in corresponding demands in the infrastructure, etc.
  75. Metrics like 1.5B requests per day sound great, don’t they? The reality is that this number is concerning…
  76. For web sites, like NPR, where page views create ad impressions and ad impressions generate revenue, 1.5B requests per day would be amazing.
  77. But for systems that yield output that looks like this...
  78. Or this… 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.
  79. We are challenging ourselves to redesign the API to see if those same 1.5B requests could have been 300 million a 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.
  80. As a result, our REST API is no longer the right tool for the job. We need a new API, designed to handle the same degree of variability that is present in the 800+ device types that Netflix supports (and that many other companies aspire to be on).
  81. Some other solutions have tried to address this issue, including OData, YQL and most recently, eBay’s ql.io. These are query-based APIs that allow the requester to have much more control over the queries to the backend which will control a much more flexible response.
  82. The SQL-like, or query-based, APIs are considerable better for large number of devices. They still seem to potentially weaken when dealing with the massive variability of the devices. The issue is that, like the REST APIs, SQL-like APIs are also set up so the server team (or the team providing the API) defines the request and response model. Granted, the SQL-like API offers much more flexibility than the REST API, but at the end of the day, device teams still need to adhere to the server-side rules.
  83. From the Netflix perspective, we are putting the days of the “one API to rule them all” approach behind us. Rather, our API, to support the growing number of devices, needs to let the device teams define their own rules. And the API platform needs to be able to support them, even if they are divergent from each other in format, delivery method, etc.