Netflix Offers Comprehensive Insight into Its Microservices Approach

Over on the Netflix blog which we strongly encourage you to bookmark or add to your feedreader, Netflix's Katharina Probst and Justin Becker have penned a fascinating post that offers critical insight into how they think about their microservices architecture in terms of structure and orchestration. Any company considering a move towards microservices will benefit from reading this post given the pioneering work that Netflix has done in the area of microservices and the degree to which its experimentation has led the company to where it is so far in that journey. It's written a way that we most of us can relate to Netflix's workflows because of how many of us have actually experienced the Netflix user interface. 

Of particular interest is how the company has layered services upon services, using its primary "front-door" API has the initiation point for invoking and orchestrating other services. Reflecting on what happens when a Netflix user finds their way to video content with their mobile phone and presses the play button, the post says "the mobile phone sends a 'play' request to the API. The API in turn calls several microservices under the hood. Some of these calls can be made in parallel, because they don’t depend on each other. Others have to be sequenced in a specific order. The API contains all the logic to sequence and parallelize the calls as necessary. The device, in turn, doesn’t need to know anything about the orchestration that goes on under the hood when the customer clicks play."

The post also discusses how Netflix functionally divided its services into three primary buckets that sounds strikingly similar to how Netflix's businesspeople probably think about visitors; "non-member (sign-up, billing, free trial, etc.), discovery (recommended shows and movies, search, etc.) and playback."

But most interesting is how Netflix uses the post to openly deliberate over the next steps the company needs to take is it looks to lay the foundation for it's next plateau of scale and reliability. Should the company stay with one primary front-door API that, depending on entry context (non-member, discovery, and playback), follows a particular fork of orchestration? Or, is it time to create another more purpose-built front door? (hint: Netflix is leaning towards the latter!) And what are the implications of these decisions for developers? In this respect, the post is remarkably transparent regarding technology issues that ultimately factor into its competitive advantage, especially given the degree to which Netflix now has competitors. 

Original Article

Engineering Trade-Offs and The Netflix API Re-Architecture

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.

Comments