TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Rebuilding Netflix's video processing pipeline with microservices

197 点作者 samaysharma超过 1 年前

16 条评论

trunnell超过 1 年前
Amazing to read about the continued re-invention of this part of Netflix&#x27;s internal systems.<p>I worked with this team (and its predecessors) during my time at Netflix. They achieved several &quot;holy grails&quot; of video encoding: a perceptual quality metric (VMAF), optimal bitrate selection per 2 second video chunk, and then optimal video chunking to be scene based rather than a fixed 2 seconds. Doing any of that in a research lab would be a challenge, but pulling it off at Netflix&#x27;s scale is epic.<p>You might need some background on how adaptive video streaming works to fully grok this article.<p>But this is also just a story about a massive refactoring of a large, critical system. How many companies have you worked for that aggressively pursued refactoring&#x2F;re-engineering their central systems? At most other places, I&#x27;ve seen risk aversion, fear, and mismanagement conspire to kill innovation. Not so at Netflix.
评论 #39320010 未加载
评论 #39319880 未加载
评论 #39321803 未加载
评论 #39324487 未加载
评论 #39319158 未加载
bjornlouser超过 1 年前
&#x27;Long release cycles: The joint deployment meant that there was increased fear of unintended production outages as debugging and rollback can be difficult for a deployment of this size. This drove the approach of the “release train”. Every two weeks, a “snapshot” of all modules was taken, and promoted to be a “release candidate”. This release candidate then went through exhaustive testing which attempted to cover as large a surface area as possible. This testing stage took about two weeks. Thus, depending on when the code change was merged, it could take anywhere between two and four weeks to reach production.&#x27;<p>I guess I&#x27;m just old, but I prefer the delay with a couple of weeks of testing versus pushing to prod and having the customer test the code.
评论 #39317917 未加载
评论 #39316802 未加载
highspeedbus超过 1 年前
Besides the debate about microservices being good or bad, it&#x27;s clear that netflix developers are very passionate about what they do. To me this seems to play a big role in the success of a software product.
评论 #39320118 未加载
b33j0r超过 1 年前
It’s not full-circle, as much as industry maturity.<p>More stories lately are about “why we went pack to monoliths and building with borland C++”<p>Not long ago it was more likely “how microservices solved everything at our company, and why only morons disagree.”<p>So are we moving towards or away from microservices? Both. We’re maturing to use the right tools for the system.
评论 #39320396 未加载
评论 #39322767 未加载
devit超过 1 年前
I can&#x27;t understand the article.<p>If you want to encode video, use ffmpeg. Netflix serves static movies, so encoding is going to be relatively rare and can probably be done on whatever computing resources are already available. Quality-wise, the ffmpeg&#x2F;x264&#x2F;x265 people probably are doing a good job already.<p>If you want to serve video, serve it with HLS or similar from static files stored on a CDN with a bunch of bitrate profiles. Here the problem is more creating or finding the CDN that anything to do with video.<p>Can&#x27;t quite figure out what the purpose of all the stuff in the article could be (maybe to justify the jobs of the people doing the work?)
评论 #39323886 未加载
评论 #39324171 未加载
评论 #39324508 未加载
Zetobal超过 1 年前
You know I read articles like that all the time but the user experience of all these app gets worse. The time to first video frame on Netflix is not great to say the least. The rich metadata seems also only to be used internally...
评论 #39314170 未加载
评论 #39314819 未加载
评论 #39314263 未加载
评论 #39314644 未加载
eterpstra超过 1 年前
Wait, who am I supposed to believe here?!? Prime Video tore down their micro services in favor of a monolith just last year! Which trillion dollar globocorp is my tiny, insignificant company supposed to emulate?<p><a href="https:&#x2F;&#x2F;thenewstack.io&#x2F;return-of-the-monolith-amazon-dumps-microservices-for-video-monitoring&#x2F;" rel="nofollow">https:&#x2F;&#x2F;thenewstack.io&#x2F;return-of-the-monolith-amazon-dumps-m...</a>
评论 #39314943 未加载
评论 #39314878 未加载
评论 #39315717 未加载
评论 #39318991 未加载
评论 #39314386 未加载
评论 #39316105 未加载
评论 #39319151 未加载
评论 #39314910 未加载
评论 #39314757 未加载
评论 #39314931 未加载
评论 #39314638 未加载
评论 #39316056 未加载
评论 #39317049 未加载
评论 #39314274 未加载
SebFender超过 1 年前
These are conversations just like talking about code editors and so on. No one is right or wrong. But if I had to choose - micro services hard harder to control and secure. And vi? not for me ;)
cletus超过 1 年前
Story time: I worked at Facebook and had to work with someone who came from Netflix. He was one of those people who, when he went to a new company, simply tried to reinvent everything he came from with no care or consideration given to what&#x27;s already there.<p>FB very much does not use microservices. The closest is in infra but the www layer is very much a massive monolith, probably too massive but that&#x27;s another story. They&#x27;ve done some excellent engineering to make the developer experience pretty good, like you can commit to www and have it just push to prod within a few hours automatically (unless someone breaks trunk, which happens).<p>Anyway, this person tried to reinvent everything as microservices and it pretty much just confirmed every preconceived notion (and hatred) or microservices that I already had.<p>You create a whole bunch of issues with orchestration, versioning and deployment that you otherwise don&#x27;t have. That&#x27;s fine if you gain a huge benefit but often you just don&#x27;t get any benefit at all. You simply get way more headaches in trying to debug why things aren&#x27;t working.<p>One of the key assumptions built into FB code that was broken is RYW (read your write). FB uses an in-memory write-through grraph database. On any given www request any writes you make will be consistent when you read them within that request. Every part of FB assumes this is true.<p>This isn&#x27;t true as soon as you cross an RPC boundary... much like you will with any microservices. So this caused no end of problems and the person just wouldn&#x27;t hear this when it was identified as an issue before anything was done. So th enet effect was 2 years spent on a migration that ultimately was cancelled.<p>Don&#x27;t be that guy. When you go into a code base, realize that things are the way they are for a reason. It might not be a good reason. But there&#x27;ll be a reason. Breaking things for the sake of reinventing the world how you think it should&#x27;ve been done were you starting from zero is just going to be a giant waste of everybody&#x27;s time.<p>As for Netflix video processing, they&#x27;re basically encoding several thousand videos and deploying those segments to a VPN. This is nothing compared to, say, the video encoding needed for FB (let alone Youtube). Also, Netflix video processing is offline. This... isn&#x27;t a hard problem. Netflix does do some cool stuff like AI scene detection to optimize encoding. But microservices feels like complete overkill.
评论 #39315549 未加载
评论 #39320341 未加载
评论 #39315627 未加载
dmillar超过 1 年前
Would be interested to also know how they handle per-title audio. With stereo -&gt; 5.1 -&gt; 7.1 and the sides and wide layout variants, how do they think about this during the inspection and encoding process? Being completely naive to Netflix&#x27;s source media, and assuming it comes in a variety for formats and media, it seems like there are decision to make there. Though audio obviously has a much lower bandwidth burden, one would think there could still be QoE gains (and bandwidth savings) by doing things that AV1 can do with different scenes in something like OPUS.
jiggawatts超过 1 年前
Okay, now that that&#x27;s done, can someone at Netflix please figure out how to use their multiple data centres worth of distributed clusters to serve more than 4 or 5 subtitle languages please?<p>If anyone at Netflix would like some assistance, I&#x27;ve previously consulted in the areas of large-scale compression optimisation, and I&#x27;m sure we can get those 100KB text files down to under 20KB!<p>I&#x27;ll help build distributed Kubernetes buzzword-compliant architectures, if that helps anyone get internal promotions as a part of this pan-cultural effort of inclusivity.
VyseofArcadia超过 1 年前
Does anyone have any reading material on the reliability of systems that use microservices? I&#x27;ve had a bit of basic probability rattling around in the back of my head that makes me suspect microservices are in general less reliable. I&#x27;d be interested in seeing a real-world analysis.<p>My thinking goes like this, with some simplifying assumptions. Let&#x27;s say you have a monolith with 99% uptime that you rearchitect into 5 microservices, each with 99% uptime, and if any one of those services goes down your whole system is down. Let&#x27;s also assume for the sake of simplicity that these microservices are completely independent, although they are almost assuredly not.<p>From basic probability, 99% uptime means there is some chunk of time t for which P(monolith goes down) = 1%. But<p>P(microservice system goes down) = P(service A down or service B down or...) = P(service A down) + P(service B down) + ... = 5%<p>In reality P(microservice system goes down) &lt; 5% because they aren&#x27;t independent and the chunk of time in which service A can go down will overlap that of service B. But still, that means the upper bound of the whole system going down is higher than for a monolith.<p>But microservices are pretty popular, and I&#x27;m sure someone has thought along these lines before. One potential rebuttal is that each microservice is in fact more reliable than the monolith, although from what I&#x27;ve seen in my career I am skeptical that&#x27;s truly the case.<p>Where&#x27;s the hole in my reasoning? (Or maybe I&#x27;m right. That would be fine too.)
评论 #39315454 未加载
评论 #39319344 未加载
评论 #39315577 未加载
评论 #39315471 未加载
评论 #39315498 未加载
评论 #39318097 未加载
评论 #39315495 未加载
评论 #39319171 未加载
ksec超过 1 年前
I am much more looking forward to Serving Netflix Video Traffic at 1600Gb&#x2F;s and Beyond. Hoping drewg123 will share something soon :)
belval超过 1 年前
&gt; Processing Ad creatives posed some new challenges: media formats of Ads are quite different from movie and TV mezzanines that the team was familiar with, and there was a new set of media processing requirements related to the business needs of Ads.<p>Nice to see them rearchitecture their service around enshittification.
zer00eyz超过 1 年前
Did any of this:<p>Make my nextflix better? How about cheaper? Did it deliver better content? Is this the work product of 2000 engineers focused on delivering me the worst content in the best way possible? What exactly am I getting for my 12, 20 ... wait what the hell is netflix charging now for their garbage content...<p>1000? 2000?d engineers at netflix and this is the article we get, this is their flex?<p>I am underwhelmed.
评论 #39315364 未加载
评论 #39315349 未加载
评论 #39316562 未加载
评论 #39315335 未加载
评论 #39317619 未加载
评论 #39316521 未加载
评论 #39315393 未加载
评论 #39315413 未加载
评论 #39317946 未加载
评论 #39315563 未加载
评论 #39316868 未加载
issafram超过 1 年前
It&#x27;s pretty easy, just stream the results of ffmpeg. I could create a Netflix platform in one day.<p>&#x2F;s if anyone took this seriously