News for hackers. Stuff that matters.
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by AtNightWeCode on Friday August 19, 2022 @01:13PM (#32523636)
Scaling streaming for a company at the size of Netflix is very easy. You can use any edge cache solution, even homemade. The complexity at N seems to stem from other things.
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by n0tth3dro1ds on Friday August 19, 2022 @01:27PM (#32523817)
>You can use any edge cache solution

Umm, those solutions exist (from places like AWS and Azure) because Netflix was able to do it without them. The cloud platforms recognized that others would want to build their own streaming services, so they built video streaming offerings.

You have the cart in front of the horse. The out-of-the-box solutions of today don’t exist without Netflix (and YouTube) building a planet scale video solution first.

Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by AtNightWeCode on Friday August 19, 2022 @01:51PM (#32524088)
N had problems in US because they served data from CA. Today, N uses edge caching and the data for me in Europe is sent less than 10km to my home. And it should be cheap. We are talking about serving static content here. It is not very difficult.
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by jedberg on Friday August 19, 2022 @02:23PM (#32524448)
Why do you think Netflix served out of California? They only did that for the first few months, until they adopted Akamai, Limelight, and L3 CDNs. That was long before Netflix launched in Europe.
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by AtNightWeCode on Friday August 19, 2022 @03:16PM (#32524970)
Well they use to, they tried to bully various ISPs into increasing their throughput before they jumped the edge cache wagon, long time after competitors. Akamai is a stellar company. Don’t think N uses A services today. At the end of the day. N mostly serves static content to users and I highly doubt that hardware costs is a very relevant parameter.
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by jedberg on Friday August 19, 2022 @03:25PM (#32525066)
With all due respect, you have no idea what you're talking about. I worked there during the transition from 3rd party CDNs to OpenConnect. We got off 3rd party CDNs in 2013/4 and operated solely out of OpenConnect, in large part because no 3rd party CDN was capable of serving our amount of video at any price, including Akamai. We weren't even streaming out of our own datacenter anymore by the time I started, and that was when streaming was still free with your DVD plan.

And your timeline is all wrong too. Netflix didn't even engage with the ISPs about bandwidth until long after moving out of our own datacenter. We started the OpenConnect program specifically to make it easier for ISPs, there was no bullying. The spat you're thinking of is that Comcast didn't want to adopt the OpenConnect but also didn't want to appropriately peer with other networks to give their customers the advertised speeds.

And hardware cost is a hugely relevant parameter. Being efficient with hardware is the difference between profitable streaming at that scale and not profitable.

Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by AtNightWeCode on Friday August 19, 2022 @04:13PM (#32525464)
You mean all the heat maps provided by Comcast and so on from 2014(?) are incorrect? That they lied about all the traffic from CA caused by N?
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by jedberg on Friday August 19, 2022 @04:16PM (#32525507)
Please link those heat maps. I think you're reading them wrong.
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by 0x457 on Friday August 19, 2022 @01:34PM (#32523890)
> any edge cache solution

Someone still has to do the R&D for edge cache? These slides are about Open Connect - their own edge cache solution that gets installed in partners racks (i.e. ISPs and Exchanges). Before things that Netflix and Nginx implemented in FreeBSD, hardware compute power was wasted on various things they discuss in slides.

Yes, you can throw money at the problem and buy more hardware.

Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by AtNightWeCode on Friday August 19, 2022 @02:03PM (#32524243)
Fair. Point taken. I answered the comment not the article.
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by yibg on Friday August 19, 2022 @04:59PM (#32525842)
This is exactly the type of comment OP is referring to. Have you build a steaming service at this scale? Do you actually know what’s involved? Or are you just looking at the surface level, making a bunch of assumptions and reaching a gut feel conclusion?
Re:Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] by AtNightWeCode on Wednesday August 24, 2022 @12:00PM (#32581210)
The gut feeling is that you basically need a file share that serves static files that are 5-50MB in size that are joined together on client side.

How do you think this compares in complexity with real time distributed transactions that spans across several financial partners across the globe?