This is mere kilobytes of data over the length of the entire movie, and can tolerate hours of latency for most aspects (e.g.: analysis, charge-back, ML, etc...).
A lot of the time I look at "modern cloud architectures" and I see a firehose of raw data being spewed out in hideously inefficient formats. Think 1 kilobyte of JSON to represent a metric, often a single number or data point. It's not just NetFlix, this is the default for most of Azure Monitor and its agents as an example that would affect a lot of people.
The write amplification is just insanity. Orders of magnitude of overhead, not data.
It's as if the entire world forgot that binary formats exist. Google in no small part benefits from remembering this lost art -- they default to gRPC and similar packed binary formats. One reason Kubernetes (written mostly by ex-Googlers) is so fast is because internally it's all compiled code and gRPC. Compared to, say, Azure itself it is ludicrously faster. Literally hundreds of times lower latencies for common operations.
This should be on the front page. We could always have had good fast metrics but the extremely inefficient data formats have made everything slow and expensive. It probably has a measurable ecological impact too.
> One reason Kubernetes (written mostly by ex-Googlers) is so fast is because internally it's all compiled code and gRPC. Compared to, say, Azure itself it is ludicrously faster.
Are you saying Azure, as a single entity, is not mostly "compiled code and (binary wire format)"? And that's why "Azure" is hundreds of times slower than "Kubernetes"? How does this make any sense?
C# as well as Python are compiled at build time. Python is a hot garbage for other reasons (just look at how dog slow the OpenStack CLI is, which is written in Python), but there's no need to pile on C#.
C# itself is actually pretty resource efficient - just look at StackOverflow, they use ridiculously few resources.
All of kubernetes external APIs are JSON over HTTPS as well, FYI. Like Azure, AWS and GCP internal communication is done via different protocols.
I hoped to convey the fact that you’re comparing apples to oranges. Of course a 3-master k8s setup with a pretty hard ~500 node cap is faster to make scheduling decisions than “Azure”, and it’s not anything to do with the data format the external API uses.
Or anything for that matter. Write amplification or giving the computer "unnecessary, mandatory work" is one of the two big causes of poor performance despite ludicrously high performance hardware.
The other is latency. It's a metric that may as well not exist in the minds of 99% of developers or architects, but is the most important one by far.
If you ever wondered how it's possible to have 100 physical servers hosting an application that's glacially slow while no single part of the entire thing is running at more than 5% utilisation, these two are sufficient explanations most of the time:
Work amplification + ignoring network latency.
Have you not ever wondered why something like Jira takes 10-30 seconds of wall clock time to display an empty form with less than 1 KB of text displayed on the screen?
It's burning through 100 million CPU cycles per byte that it's showing you! That's how.
That... or its server is twiddling its thumbs waiting for the network 29.99 seconds out of 30.00 seconds.
It's one or the other: There are no other options!
A lot of the time I look at "modern cloud architectures" and I see a firehose of raw data being spewed out in hideously inefficient formats. Think 1 kilobyte of JSON to represent a metric, often a single number or data point. It's not just NetFlix, this is the default for most of Azure Monitor and its agents as an example that would affect a lot of people.
The write amplification is just insanity. Orders of magnitude of overhead, not data.
It's as if the entire world forgot that binary formats exist. Google in no small part benefits from remembering this lost art -- they default to gRPC and similar packed binary formats. One reason Kubernetes (written mostly by ex-Googlers) is so fast is because internally it's all compiled code and gRPC. Compared to, say, Azure itself it is ludicrously faster. Literally hundreds of times lower latencies for common operations.