9 ms·

Am I naive thinking this infra is overblown for a read-only content website? As much as this website could be very trafficked I have the feeling they are overc

Am I naive thinking this infra is overblown for a read-only content website? As much as this website could be very trafficked I have the feeling they are overcomplicating their infra, for little gains. Or at least, I wouldn't expect to end having an article about.

boxed 1y ago
I mean, this is the company that invented microservices so....
- thinkindie 1y ago
  very fair point - but there are valid use cases for microservices.
- moomoo11 1y ago
  Microservices for _organizational_ challenges. Lots of people think microservices = performance gains only. It’s not. It’s mainly for organizational efficiency. You can’t be blocked from deploying fixes or features. Always be shipping. Without breaking someone else’s code.
  - boxed 1y ago
    In fact, it's opposed to performance in many cases. And dev velocity for small teams.
  - williamdclt 1y ago
    > Lots of people think microservices = performance gains only. I don't think I ever heard that. Who claims that microservice architectures are for performance gains?
    - moomoo11 1y ago
      You’d be surprised, a lot during interviews I conducted. I think it’s mostly people that have not worked with them.
rokkamokka 1y ago
From an outsiders perspective Tudum does seem to be an extremely simple site... But maybe they have complicated use cases for it? I'm also not convinced it merits this level of complexity
pram 1y ago
I’m gonna take a wild guess: the actual problem they’re engineering around is the “cloud” part of the diagram (that the “Page Construction Service” talks to) There is probably some hilariously convoluted requirement to get traffic routed/internal API access. So this thing has to run in K8s or whatever, and they needed a shim to distribute the WordPress page content to it.
- piva00 1y ago
  Having to run in k8s doesn't change that much, the description of a whole Cassandra + Kafka stack to deliver the ingestion of articles already says there's a lot more architecture astronaut-ing going on than simply deployment. I cannot imagine why you'd need a reactive pipeline built on top of Kafka and Cassandra to deliver some fanservice articles through a CMS, perhaps some requirement about international teams needing to deliver tailored content to each market but even with that it seems quite overblown. In the end it will be a technical solution to an organisational issue, some parts of their infrastructure might be quite rigid and there are teams working around that instead of with that...
  - pram 1y ago
    Probably because they were available, and now they’ve done the equivalent of throwing redis on their containers. My main point is, the blog content is probably the “easy part” and whatever is consuming it is the “hard part”
- sunrunner 1y ago
  Alternative idea: the actual problem they’re engineering around is their developers CVs
__alexs 1y ago
Doing weird pointlessly complicated stuff on a niche area of your website is a not entirely ridiculous way to try out new things and build new skills I guess.
dakiol 1y ago
Most of the tech infrastructure out there is over engineered. At least based on my experience.
- busterarm 1y ago
  I remember being interested in their architecture when I attended re:Invent in 2018. I went to four separate Netflix talks given by four separate people with wildly different titles, teams and responsibilities. The talks had different titles indicating a variety of topics covered. Two of these talks weren't even obviously/outwardly Netflix-focused from the description -- they were just talks supposedly covering something I was curious about. All four speakers ran the exact same slide deck with a different intro slide. All four speakers claimed the same responsibility for the same part of the architecture. I was livid. I also stopped attending talks in person entirely because of this, outside of smaller more focused events.
  - geodel 1y ago
    I don't know because I have not been to AWS Re:invent. But from what I have seen at workplace is that trip to this event is equivalent of corporate junket for mid-level developers who happened to be manager's favorite.
rvz 1y ago
> As much as this website could be very trafficked I have the feeling they are overcomplicating their infra, That is because they are and it seems that since they're making billions and are already profitable, they're less likely to change / optimize anything.* Netflix is stuck with many Java technologies with all their fundamental issues and limitations. Whenever they need to 'optimize' any bottlenecks, their solution somehow is to continue over-engineering their architecture over the most tiniest offerings (other than their flagship website). There is little reason for any startup to copy this architectural monstrosity just for attention on their engineering blog post for little to no advantage whatsoever. * Unless you are not profitable, costs of infra continues to increase or the quality of service is sluggish or it is urgent to do so.
- gf000 1y ago
  > There is little reason for any startup to copy this architectural monstrosity This is the only reasonable take in your rant, but the reasoning is off for even this. They have little reason, because they will never hit the scale Netflix operates at. In the very very odd chance they do, they will have ample money to care about it.
  - rvz 1y ago
    We've already seen a decade of cargo-culting around the micro-services hype which was popularized by Netflix and we don't need yet another over-engineered solution which given the results of this one, delivers little value or gains to solving the problem. But many startups will die trying it anyway.
Joe8Bit 1y ago
Reading the article I got the impression the big challenge is doing "personalzation" of the content at scale. If it were "just" static pages, served the same to everyone, then it's pretty straightforward to implement even at the >300m users scale Netflix operates at. If you need to serve >300m _different_ pages, each built in real-time with a high-bar p95 SLO then I can see it getting complicated pretty quickly in a way that could conceivably justify this level of "over engineering". To be honest though, I know very little about this problem beyond my intuition, so someone could tell me the above is super easy!
- TYPE_FASTER 1y ago
  Yup. Content that may be read-only from a user's perspective might get updated by internal services. When those updates don't need to be reflected immediately, a CDN or similar works fine for delivering the content to a user. When changes to data are important, a library like Hollow can be pretty magical. Your internal data model is always up to date across all your compute instances, and scaling up horizontally doesn't require additional data/infrastructure work. We were processing a lot of data with different requirements: big data processed by a pipeline - NoSQL, financial/audit/transactional - relational, changes every 24hrs or so but has to be delivered to the browse fast - CDN, low latency - Redis, no latency - Hollow. Of course there are tradeoffs between keeping a centralized database in memory (Redis) and distributing the data in memory on each instance (Hollow). There could be cases where Hollow hasn't sync'd yet, so the data could be different across compute instances. In our case, it didn't matter for the data we kept in Hollow.
  - motorest 1y ago
    > When those updates don't need to be reflected immediately, a CDN or similar works fine for delivering the content to a user. What leads you to believe a CDN is a solution to a problem of delivering personalized content to a specific user?
    - TYPE_FASTER 1y ago
      Personalization could include showing the same cached content to many people. The personalization here could refer to which content is served from the CDN to which users.
motorest 1y ago
> As much as this website could be very trafficked I have the feeling they are overcomplicating their infra, for little gains. This sort of personal opinion reads like a cliche in software development circles: some rando casualy does a drive-by system analysis, cares nothing about requirements or constraints, and proceeds to apply simplistic judgement in broad strokes. And this is then used as a foundation to go on a rant regarding complexity. This adds nothing of value to any conceivable discussion.
- gcr 1y ago
  characterizing netflix as a "read-only" website is incredibly shortsighted. you have: - a constantly changing library across constantly changing licensing regions available in constantly changing languages - collaborative filtering with highly personalized recommendation lists, some of which you just know has gotta be hand-tuned by interns for hyper-demographic-specific region splits - the incredible amounts of logistics and layers upon layers of caching to minimize centralized bandwidth to serve that content across wildly different network profiles i think that even the single-user case has mind boggling complexity, even if most of it boils down to personalization and infra logistics.
  - motorest 1y ago
    > characterizing netflix as a "read-only" website is incredibly shortsighted considering: The people talking about "read-only" didn't even bothered to read the overview of the system they are criticizing. They are literally talking out of wilful ignorance. But here we are.
  - rpsw 1y ago
    This blog about an architecture change is about the Tudum website specifically, not the whole of Netflix.
  - jiggawatts 1y ago
    > constantly changing languages Wouldn't that be nice! NetFlix still only supports 4 or 5 subtitle languages. Their billions of dollars of fancy-pants infrastructure just doesn't scale to more than half a dozen of so text files.
shermantanktop 1y ago
When new people join your team and learn your infrastructure, I bet they often ask ”why is this so complicated? It’s just a <insert simple thing here>.” And your response is surely “Well of course, that would be nice, but it’s not as simple as that. Here are constraints X Y and Z that make a trivial solution infeasible.”
- jiggawatts 1y ago
  > And your response is surely “Well of course, that would be nice, but it’s not as simple as that. Here are constraints X Y and Z that make a trivial solution infeasible.” It's 500 MB of text. A phone could serve that at the scale we're talking about here, which is a PR blog, not netflix.com. They're struggling with "reading" from a database that is also used for "writes", a terribly difficult situation that no commercial database engine has ever solved in the past. Meanwhile they have a complex job engine to perform complex tasks such as joining two strings together to form a complete URL instead of just a relative path. This is pure, unadulterated architecture astronaut arrogance. PS: This forum, right here, supports editing at a much higher level of concurrency. It also has personalised content that is visible to users with low latency. Etc, etc... All implemented without CQRS, Kafka, and so forth.
  - foobarian 1y ago
    Yes but HN is not Yahoo scale
    - yandie 1y ago
      This Netflix blog isn’t yahoo scale either
- motorest 1y ago
  > And your response is surely “Well of course, that would be nice, but it’s not as simple as that. Here are constraints X Y and Z that make a trivial solution infeasible.” All problems are trivial once you ignore all real-world constraints.
- 1y ago
geodel 1y ago
Not naive but perhaps missing that army of enterprise Java developers that Netflix employ do need to justify their large salaries by creating complex architecture to handler future needs.

boxed 1y ago

I mean, this is the company that invented microservices so....

thinkindie 1y ago
very fair point - but there are valid use cases for microservices.
moomoo11 1y ago
Microservices for _organizational_ challenges. Lots of people think microservices = performance gains only. It’s not. It’s mainly for organizational efficiency. You can’t be blocked from deploying fixes or features. Always be shipping. Without breaking someone else’s code.
- boxed 1y ago
  In fact, it's opposed to performance in many cases. And dev velocity for small teams.
- williamdclt 1y ago
  > Lots of people think microservices = performance gains only. I don't think I ever heard that. Who claims that microservice architectures are for performance gains?
  - moomoo11 1y ago
    You’d be surprised, a lot during interviews I conducted. I think it’s mostly people that have not worked with them.

rokkamokka 1y ago

From an outsiders perspective Tudum does seem to be an extremely simple site... But maybe they have complicated use cases for it? I'm also not convinced it merits this level of complexity

pram 1y ago

I’m gonna take a wild guess: the actual problem they’re engineering around is the “cloud” part of the diagram (that the “Page Construction Service” talks to) There is probably some hilariously convoluted requirement to get traffic routed/internal API access. So this thing has to run in K8s or whatever, and they needed a shim to distribute the WordPress page content to it.

piva00 1y ago
Having to run in k8s doesn't change that much, the description of a whole Cassandra + Kafka stack to deliver the ingestion of articles already says there's a lot more architecture astronaut-ing going on than simply deployment. I cannot imagine why you'd need a reactive pipeline built on top of Kafka and Cassandra to deliver some fanservice articles through a CMS, perhaps some requirement about international teams needing to deliver tailored content to each market but even with that it seems quite overblown. In the end it will be a technical solution to an organisational issue, some parts of their infrastructure might be quite rigid and there are teams working around that instead of with that...
- pram 1y ago
  Probably because they were available, and now they’ve done the equivalent of throwing redis on their containers. My main point is, the blog content is probably the “easy part” and whatever is consuming it is the “hard part”
sunrunner 1y ago
Alternative idea: the actual problem they’re engineering around is their developers CVs

__alexs 1y ago

Doing weird pointlessly complicated stuff on a niche area of your website is a not entirely ridiculous way to try out new things and build new skills I guess.

dakiol 1y ago

Most of the tech infrastructure out there is over engineered. At least based on my experience.

busterarm 1y ago
I remember being interested in their architecture when I attended re:Invent in 2018. I went to four separate Netflix talks given by four separate people with wildly different titles, teams and responsibilities. The talks had different titles indicating a variety of topics covered. Two of these talks weren't even obviously/outwardly Netflix-focused from the description -- they were just talks supposedly covering something I was curious about. All four speakers ran the exact same slide deck with a different intro slide. All four speakers claimed the same responsibility for the same part of the architecture. I was livid. I also stopped attending talks in person entirely because of this, outside of smaller more focused events.
- geodel 1y ago
  I don't know because I have not been to AWS Re:invent. But from what I have seen at workplace is that trip to this event is equivalent of corporate junket for mid-level developers who happened to be manager's favorite.

rvz 1y ago

> As much as this website could be very trafficked I have the feeling they are overcomplicating their infra, That is because they are and it seems that since they're making billions and are already profitable, they're less likely to change / optimize anything.* Netflix is stuck with many Java technologies with all their fundamental issues and limitations. Whenever they need to 'optimize' any bottlenecks, their solution somehow is to continue over-engineering their architecture over the most tiniest offerings (other than their flagship website). There is little reason for any startup to copy this architectural monstrosity just for attention on their engineering blog post for little to no advantage whatsoever. * Unless you are not profitable, costs of infra continues to increase or the quality of service is sluggish or it is urgent to do so.

gf000 1y ago
> There is little reason for any startup to copy this architectural monstrosity This is the only reasonable take in your rant, but the reasoning is off for even this. They have little reason, because they will never hit the scale Netflix operates at. In the very very odd chance they do, they will have ample money to care about it.
- rvz 1y ago
  We've already seen a decade of cargo-culting around the micro-services hype which was popularized by Netflix and we don't need yet another over-engineered solution which given the results of this one, delivers little value or gains to solving the problem. But many startups will die trying it anyway.

Joe8Bit 1y ago

Reading the article I got the impression the big challenge is doing "personalzation" of the content at scale. If it were "just" static pages, served the same to everyone, then it's pretty straightforward to implement even at the >300m users scale Netflix operates at. If you need to serve >300m _different_ pages, each built in real-time with a high-bar p95 SLO then I can see it getting complicated pretty quickly in a way that could conceivably justify this level of "over engineering". To be honest though, I know very little about this problem beyond my intuition, so someone could tell me the above is super easy!

TYPE_FASTER 1y ago
Yup. Content that may be read-only from a user's perspective might get updated by internal services. When those updates don't need to be reflected immediately, a CDN or similar works fine for delivering the content to a user. When changes to data are important, a library like Hollow can be pretty magical. Your internal data model is always up to date across all your compute instances, and scaling up horizontally doesn't require additional data/infrastructure work. We were processing a lot of data with different requirements: big data processed by a pipeline - NoSQL, financial/audit/transactional - relational, changes every 24hrs or so but has to be delivered to the browse fast - CDN, low latency - Redis, no latency - Hollow. Of course there are tradeoffs between keeping a centralized database in memory (Redis) and distributing the data in memory on each instance (Hollow). There could be cases where Hollow hasn't sync'd yet, so the data could be different across compute instances. In our case, it didn't matter for the data we kept in Hollow.
- motorest 1y ago
  > When those updates don't need to be reflected immediately, a CDN or similar works fine for delivering the content to a user. What leads you to believe a CDN is a solution to a problem of delivering personalized content to a specific user?
  - TYPE_FASTER 1y ago
    Personalization could include showing the same cached content to many people. The personalization here could refer to which content is served from the CDN to which users.

motorest 1y ago

> As much as this website could be very trafficked I have the feeling they are overcomplicating their infra, for little gains. This sort of personal opinion reads like a cliche in software development circles: some rando casualy does a drive-by system analysis, cares nothing about requirements or constraints, and proceeds to apply simplistic judgement in broad strokes. And this is then used as a foundation to go on a rant regarding complexity. This adds nothing of value to any conceivable discussion.

gcr 1y ago
characterizing netflix as a "read-only" website is incredibly shortsighted. you have: - a constantly changing library across constantly changing licensing regions available in constantly changing languages - collaborative filtering with highly personalized recommendation lists, some of which you just know has gotta be hand-tuned by interns for hyper-demographic-specific region splits - the incredible amounts of logistics and layers upon layers of caching to minimize centralized bandwidth to serve that content across wildly different network profiles i think that even the single-user case has mind boggling complexity, even if most of it boils down to personalization and infra logistics.
- motorest 1y ago
  > characterizing netflix as a "read-only" website is incredibly shortsighted considering: The people talking about "read-only" didn't even bothered to read the overview of the system they are criticizing. They are literally talking out of wilful ignorance. But here we are.
- rpsw 1y ago
  This blog about an architecture change is about the Tudum website specifically, not the whole of Netflix.
- jiggawatts 1y ago
  > constantly changing languages Wouldn't that be nice! NetFlix still only supports 4 or 5 subtitle languages. Their billions of dollars of fancy-pants infrastructure just doesn't scale to more than half a dozen of so text files.

shermantanktop 1y ago

When new people join your team and learn your infrastructure, I bet they often ask ”why is this so complicated? It’s just a <insert simple thing here>.” And your response is surely “Well of course, that would be nice, but it’s not as simple as that. Here are constraints X Y and Z that make a trivial solution infeasible.”

jiggawatts 1y ago
> And your response is surely “Well of course, that would be nice, but it’s not as simple as that. Here are constraints X Y and Z that make a trivial solution infeasible.” It's 500 MB of text. A phone could serve that at the scale we're talking about here, which is a PR blog, not netflix.com. They're struggling with "reading" from a database that is also used for "writes", a terribly difficult situation that no commercial database engine has ever solved in the past. Meanwhile they have a complex job engine to perform complex tasks such as joining two strings together to form a complete URL instead of just a relative path. This is pure, unadulterated architecture astronaut arrogance. PS: This forum, right here, supports editing at a much higher level of concurrency. It also has personalised content that is visible to users with low latency. Etc, etc... All implemented without CQRS, Kafka, and so forth.
- foobarian 1y ago
  Yes but HN is not Yahoo scale
  - yandie 1y ago
    This Netflix blog isn’t yahoo scale either
motorest 1y ago
> And your response is surely “Well of course, that would be nice, but it’s not as simple as that. Here are constraints X Y and Z that make a trivial solution infeasible.” All problems are trivial once you ignore all real-world constraints.
1y ago

geodel 1y ago

Not naive but perhaps missing that army of enterprise Java developers that Netflix employ do need to justify their large salaries by creating complex architecture to handler future needs.