Add to compare

Evolve your API into a Platform for API Development

It's well defined that an API strategy is one centrepiece to the Platform Business Model, but it's not so well defined how to go about setting up such an approach. The API development field is still a relatively new one especially for strategic purposes.

A Platform for API Development

This is why Netflix is such a rich goldmine of learning for multiple aspects of next generation Cloud architecture design, including a recipe for such a scenario.

The headline theme is introduced in this blog, where they make the distinction between approaching these two different ways - Develop an API, or - "evolve our API into a platform for API development".

Their motivation for doing so is an especially important one because it's often quoted as 'the right way to do things', the use of REST and open standards for the API methods. While they acknowledge the strengths of this approach they also describe how Netflix, as a very advanced user of APIs, came to reach limitations that they characterize through the 'one size fits all' (OSFA) challenge.

When Netflix began their API strategy they were still in the business of shipping DVDs. Since then of course their online global content delivery network approach has expanded exponentially, including across multiple devices as well as geographic markets.

API Platform Blueprint

They describe a specific philosophy blueprint for how to define such a platform:

  • Embrace the Differences of the Devices
  • Separate Content Gathering from Content Formatting/Delivery
  • Redefine the Border Between "Client" and "Server"
  • Distribute Innovation

Embrace the Differences of the Devices

The value of these philosophies is immediately evident when you consider the nature of the challenges they are seeking to address:

The key driver for this redesigned API is the fact that there are a range of differences across the 800+ device types that we support. Most APIs (including the REST API that Netflix has been using since 2008) treat these devices the same, in a generic way, to make the server-side implementations more efficient.

and how

While effective, the problem with the OSFA approach is that its emphasis is to make it convenient for the API provider, not the API consumer.

A market explosion for Netflix has meant they've expanded across multiple strategic dimensions simultaneously: A shift from DVD to online platform, a massive surge in traffic through moving online, an expansion to multiple countries across the world and an enormous expansion of capacity and devices: Broadband, iPads and smartphones have all contributed to an exponential growth factor.

It's the multiple formats of these devices that causes the challenges. Netflix wants to exploit the rich features of each but REST isn't intended for that granularity; it achieves ubuiquity through simple operations only. Therefore to enable exploitation of these rich features for their own content strategy ambitions, they expanded their approach.

In this ProgrammableWeb guest blog Daniel Jacobson, Director of Engineering for the Netflix API, provides a much more detailed analysis explaining this rationale.

Netflix define that the OSFA approach of REST for a Digital strategy of this magnitude can prove inadequate in these terms and is thus a key insight for others planning a similar scale and mode of platform strategy.


They also share their crucial insights learned from implementing the approach, most notably the act of delegating ownership of APIs to the device teams.

As you might imagine the principle challenge that would arise from this type of approach is API complexity, with so many in use. Netflix scales to the challenge through distributing the workload across the end point development teams:

As described above, pushing some of the client code back to the servers and providing custom endpoints gives us the opportunity to distribute the API development to the UI teams. We are able to do this because the consumers of this private API are the Netflix UI and device teams. Given that the UI teams can create and modify their own adapter code (potentially without any intervention or involvement from the API team), they can be much more nimble in their development.

offering architecture benefits:

because these adapters are isolated from each other, this approach also diminishes the risk of harming other device implementations with tactical changes in their device-specific APIs.

but presenting these fundamental challenge:

Of course, one drawback to this is that UI teams are often more skilled in technologies like HTML5, CSS3, JavaScript, etc. In this system, they now need to learn server-side technologies and techniques.

Netflix describe how they address this challenge simply through always recruiting skilled engineers who can cope with these development requirements.

Microservices APIs

As they have advanced their API strategy Netflix have also pioneered a microservices approach to software architecture, and in this blog explore the dynamics of this cutting edge approach:

which they define primarily as:

Best Practices

Microservices Orchestration in the Netflix API

The Netflix API is the “front door” to the Netflix ecosystem of microservices. As requests come from devices, the API provides the logic of composing calls to all services that are required to construct a response. It gathers whatever information it needs from the backend services, in whatever order needed, formats and filters the data as necessary, and returns the response.

So, at its core, the Netflix API is an orchestration service that exposes coarse grained APIs by composing fined grained functionality provided by the microservices.

Continuous Deployment

Additionally in this blog they describe how they factor these new approaches into a process of Continous Deployment, addressig a process lifecycle they describe as "from feature inception to global deployment to production clusters across all of our AWS regions."

They describe the key techniques and Cloud services applied at each step in the cycle:

  • Confidence in the Canary - How to leverage an automated process that compares 1000+ metrics between their baseline and canary code and generates a confidence score that gives a sense for how likely the canary is to be successful in production.
  • Multi-Region Deployment - How they deploy new code updates to multiple regions. (Describes use of Asgard, now superceded by Spinnaker.)

We will be happy to hear your thoughts

Leave a reply

Reset Password
Compare items
  • Total (0)