Netflix has entered the final stages of shuttering its public API last week. Its been coming for a while now, starting in June of 2012, and now is official with the platform no longer accepting new API registrations.
After reading about the changes to the Netflix Public API program on their blog, and hearing much of the news in response, everyone seems to file this away, along with the Twitter API--just another API platform screwing over its developers.
As I do, I wanted to take a step back, look at the bigger picture and try understand what happened. On October 1st 2008, Netflix launched their public API, and they appear to have done everything right. They had a blog, solicited code samples from developers, accepted application submissions and even showcased the developers apps in the gallery. Netflix would even help promote your app to Netflix subscribers and threw hackathons. The Netflix API team worked to improve API performance, communicate regularly, but really nothing that amazing happened.
There were applications like InstaWatcher and WhichFlicks (among others) developed on the API, but as Daniel Jacobson puts it, a thousand flowers didn’t bloom. In these situations its easy to blame the API provider, but developers didn’t really step up and build anything that innovative and cool. So is this a failure of Netflix? A failure of developers to innovate? Or could it possibly be a third: failure of the API vision?
I would say the demise of the Netflix public API is equal part Netflix and the developer, and just the nature of the industry it exists in. It didn’t take me long to look through the Netflix API blog, so I can tell they didn’t put alot into evangelizing the API. But I really can’t find any innovation that occurred by developers as part of it, so I think us devs have to share some of the responsibility as well.
Several of the blog posts covering the news last week, compared this to Twitter which I think for the untrained eye of the mainstream tech blogosphere, this is easy to do. But Twitter is user generated content, via one of the newest types of content platforms, and Netflix is heavily licensed and policed content from one of the oldest content platforms. I think expecting public API success from Netflix and / or developers was a lot to ask.
I love and believe in APIs, but I’m not delusional enough to think they will work magically everywhere they are applied. However, even with the closing of the public Netflix API, I consider Netflix is an API success story. Look what they’ve done with their internal and partner APIs. They’ve managed to scale not just from the data center to the cloud, but globally and across 800+ devices--while also sharing this knowledge and wisdom with the public via their blog:
- Public Continuous Integration Builds for our OSS Projects
- Introducing the first NetflixOSS Recipe: RSS Reader
- Karyon: The nucleus of a Composable Web Service
- Denominator: A Multi-Vendor Interface for DNS
- Announcing EVCache: Distributed in-memory datastore for Cloud
- Netflix Queue: Data migration for a high volume web application
- Functional Reactive in the Netflix API with RxJava
- Announcing Ribbon: Tying the Netflix Mid-Tier Services Together
- NetflixGraph Metadata Library: An Optimization Case Study
- Optimizing the Netflix API
If that wasn't enough, they are also open sourcing much of the technology behind their approach:
- eureka - AWS Service registry for resilient mid-tier load balancing and failover
- RxJava - a library for composing asynchronous and event-based programs using observable sequences for the Java VM
- Governator - A library of extensions and utilities that enhance Google Guice to provide: classpath scanning and automatic binding, lifecycle management, configuration to field mapping, field validation and parallelized object warmup
- Priam - Co-Process for backup/recovery, Token Management, and Centralized Configuration management for Cassandra
- edda - Service to track changes in your cloud recipes-rss - RSS Reader Recipes that uses several of the Netflix OSS components
- astyanax - Cassandra Java Client
- karyon - The nucleus or the base container for Applications and Services built using the NetflixOSS ecosystem
- netflix-graph - Compact in-memory representation of directed graph data
- asgard - Web interface for application deployments and cloud management in Amazon Web Services (AWS)
- Hystrix - Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable
- servo - Netflix Application Monitoring Library
- frigga - Utilities for working with Asgard named objects
When measuring the success or failures of API initatives, we can't use the same yardstick in all scenarios. When you look at the knowledge, wisdom and code that has come out of Netflix, there is no way you can say their API initiative is anything but a success. I don’t see see Netflix as a case study in how to stream movies over the web via public APIs, but a deeply important experiment in how to deliver licensed content to over 800 devices, via the next generation of APIs. Something that probably isn't an edge case, it actually represents where we all might be headed in the near future.
Let’s not get caught up in the recent deprecation of the Netflix public API. There is so much going on! Let's get studying some of the knowledge and technology coming out of Netflix. I know its my motivation for writing this post, and doing this research.
