Building Netflix Playback with Self-Assembling Components (2014)

http://techblog.netflix.com/2014/06/building-netflix-playback-with-self.html

by coffeedan • 11 years ago

38 16 11 years ago

techblog.netflix.com

trevyn• 11 years ago

I'm too old for this.

omegaworks• 11 years ago

So... Netflix solved SAT?

arjie• 11 years ago

This is a far simpler problem than SAT. There aren't enough details in this post, but one would expect that 'processors' would not impede one another. Then it's dependency resolution, of the sort that package managers do every day.

TD-Linux• 11 years ago

I don't understand what problem is being solved here. Is this just an overly convoluted way to describe load balancing?

fizwhiz• 11 years ago

My understanding from briefly skimming the article was that they have forced a "composition" of service orchestration to get from an input to a particular output. From a product standpoint, a particular "experience" could be broken down into a set orchestration of services (depicted as input/output functions). This lets you "tweak" your experience/product by mixing up the flavor of orchestrations by "stitching" different services (much like assembling lego blocks) via some rule engine. Kinda like "dependency-injection" but from a system architecture point of view as opposed to just an application code architecture.

riwsky• 11 years ago

No. It solves the problem of having to reason about data dependencies between functions at scale, typically in the service of doing the minimum amount of work required to get a certain result. As "Steve Wampler" points out in the comments, it's a bit like Inversion of Control/ Dependency injection, except for transient data between functions as opposed to services, connection pools, etc.

Other systems that solve similar problems, whose explanations might make more sense to you: Prismatic's Graph (http://blog.getprismatic.com/prismatics-graph-at-strange-loo...), Jane Street's Incremental (https://blogs.janestreet.com/introducing-incremental/)—and, though it doesn't nicely cover IO—the general concept of laziness in programming languages (https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...).

markbnj• 11 years ago

I don't think you can expect to gain that understanding from this piece. It's part of a series, and presumably forthcoming posts will explain how the rules engine drives which components are selected to process specific content requests.

zkhalique• 11 years ago

Our whole platform is built from self-assembling components.

But sometimes they have to know about each other :)

twberger2• 11 years ago

So, getters? We need X, so we call getX(). getX needs A and B, so it calls getA() and getB(). And so on, until getSomething() just reads input. Please correct me if I'm reading this wrong.

tadfisher3• 11 years ago

This is the Inversion of Control pattern, where you inject A and B into X via some external mechanism (such as Dependency Injection). The advantage you gain is that you can swap out A and B for objects with different behavior (such as mocks) without needing to change the implementation of X. This leads to an architecture with a high degree of composability and a low degree of coupling, which is great for large systems.

juliangregorian• 11 years ago

But getters and setters aren't inherently associated with IoC nor vice versa.

twberger2• 11 years ago

When besides mocking would you want to swap out a dependency using an overarching dependency provider rather than an intermediary processor/getter with conditional delegation?

sidjoshi• 11 years ago

AWS SimpleWorkflow (SWF) replay mechanism seems close to this. http://docs.aws.amazon.com/amazonswf/latest/awsflowguide/aws...

aalhour• 11 years ago

Can someone recommend a resource for researching scalability solutions like these? Book(s), or video series?

Building Netflix Playback with Self-Assembling Components (2014)

Related Stories