I wonder how this compares with the recently launched AWS Batch.
The Evolution of Container Usage at Netflix
21–30 of 160 posts
Re: The Evolution of Container Usage at Netflix
#22Re: The Evolution of Container Usage at Netflix
#23Netflix Engineering team amazes me a lot. They literally took all the available apis, and build their own platform despite some of the features are already in the AWS offerings. I suppose they did it mainly because the native service isn't flexible and robust enough for their use cases. BTW, their opening positions are always prefixed with "senior" title but I guess that makes sense; Netflix builds pretty much everyt…
I asked that in an interview with Netflix, why they were building their own vs open source. The answer I got was "It doesn't work at the scale that Netflix operates" , not quite sure what that means but I didn't press him further.
Re: The Evolution of Container Usage at Netflix
#24Re: The Evolution of Container Usage at Netflix
#25I would've imagined Netflix had their own hardware, both compute and storage.
At least part of their content delivery network is based on their own hardware/software (see https://openconnect.netflix.com/en/ and the PDF referenced there). It's called "Open Connect Appliance".
They use AWS for video transcoding) (see http://techblog.netflix.com/2015/12/high-quality-video-encod...) and probably other activities (analytics, business)
Re: The Evolution of Container Usage at Netflix
#26Re: The Evolution of Container Usage at Netflix
#27Earlier quoted context omitted.
I've heard they're looking at 'architecture in a box' solutions, which would allow them to abstract designs from specific cloud providers and perform cloud arbitrage; eg, if Cloud Provider X can run the app at 14c/hour, and Cloud Provider Y can run the app at 22c/hour, then they can just deploy the entire architecture on Cloud Provider Y.
Why would they choose the more expensive one?
Because, er, I made a typo and it's too late to edit. Good spot!
Re: The Evolution of Container Usage at Netflix
#28They're killing performance (one of the main reasons to use containers) and adding a massive extra layer of management if they're running containers on EC2. I suspect Netflix are too wedded to AWS (which is weird as Amazon is their biggest threat) but Triton or Red Shift (both of which actually isolate containers using SmartOS and SELinux respectively) make way more sense for other people who want to use the blazing…
It seems they value developer productivity and innovation over machine performance. I find this enlightening.
I value developer productivity over machine performance too, but they're doing the opposite here: developer productivity is not helped with an unnecessary second layer of containment.
With containers on top of VMs, you now have to manage which containers run on which VMs (and the cloud provider worries about physical boxes), with a pure container solution you just spawn containers (and the cloud provider worries about physical boxes)
Re: The Evolution of Container Usage at Netflix
#29Earlier quoted context omitted.
They were fairly early and fairly vocal proponents of moving to cloud based systems. I haven't looked in awhile but last I checked all but their CDN was running on AWS.
I thought their CDN was FreeBSD machines and everything else was on AWS.
I'm not sure why you're being downvoted, as the GP is wrong and your post is on the money.
Netflix runs their OpenConnect appliances at every big ISP that will let them put one there:
https://openconnect.netflix.com/en/
They run Freebsd, and all of the web services (thousands of them) run in AWS on Linux.
https://www.rapidtvnews.com/2016031942170/netflix-moves-all-...
Re: The Evolution of Container Usage at Netflix
#30Earlier quoted context omitted.
Or use something like GKE where the containers should be running directly on hardware, so you only have one layer.
"Bare-metal" means running directly on hardware. But yes, GKE would also join Triton and Red Shift (provided it has similar container isolation capabilities).
Actually, as 0x74696d mentions below, GKE is also not bare metal.
Doing a little research: GKE runs on https://cloud.google.com/container-optimized-os/docs/ which is designed for GCE, which runs on KVM: https://cloud.google.com/compute/docs/faq
So it looks like just Triton and Red Shift.
Disclaimer: I used to work at Red Hat, which means I like the people behind Red Shift, but that also means I hate the people behind Triton as part of the early 2000s Linux/Solaris wars.