4 ms·

When I'm looking at this diagram I'm struck by how much it diverges from the typical entities invoked when we generally describe a tech stack. There's almost n

When I'm looking at this diagram I'm struck by how much it diverges from the typical entities invoked when we generally describe a tech stack. There's almost no discussion of language or framework or "patterns" in the software idiom sense. Instead it's largely a wide variety of data stores and access layers. Bad programmers worry about code, good programmers worry about data structures?

duaneb 11y ago
> Bad programmers worry about code, good programmers worry about data structures? Bingo. At this scale, all that matters are the bounds a service can guarantee. So long as it can comply to the bounds, the underlying algorithm (let along language, patterns, etc) doesn't matter. Facebook's development of the HHVM is a perfect example of this—they took a nearly universally despised language (from an engineering perspective) and tooled it to fit into the necessary constraints. While crucial for explaining their stack, it's not in any way necessary for any of the individual nodes.
endtime 11y ago
I think it's a matter of scale, rather than quality - we obviously use languages and frameworks and patterns at Google.
- wwweston 11y ago
  Scale of operations at Google, or conceptual scale of the diagram? And if you feel like language and framework choice plays a significant enough role at Google that "stack" in the more traditional sense is something that's carefully considered by engineering, I'd love to hear about the details.
  - reagency 11y ago
    This diagram is about services that run o a machine and vend data to other machines, not the libraries or frameworks (GWT, etc) that implement the services. This diagram is more "zoomed out"
  - endtime 11y ago
    The scale of the diagram, though obviously a diagram of that scale can only be drawn for an organization with operations at that scale - so kind of both. I've mostly done backend/data stuff at Google, so I can't speak to traditional web dev decisions, but I've written design docs which discuss the tradeoffs between using Bigtable and Spanner, or Flume vs. Mapreduce, or one serving strategy vs. another, for some specific thing. Maybe those choices are vaguely analogous to choosing between Postgres or Mongo, nginx or Apache, etc. I imagine the guys who write webapps (not Search, obviously, but internal apps or things like our help pages) consider whether to use App Engine, Angular, Django, etc. on a per-app basis.
asuffield 11y ago
(Tedious disclaimer: my opinion, not my employer's. Not representing anybody else. I'm an SRE at Google, and use some of this stuff all the time.) In all honesty, this diagram is missing so much information that you won't learn very much from it about how we do things (and all the things you can't see are confidential). It's more like a map of the relationships between the few bits that have been published. However, I would tend to agree with your final suggestion that data structures are much more interesting than code.
NicoJuicy 11y ago
Everyone worries about code, but on top of code you have architecture. Worrying about code makes other programmers life easier, just like worrying about endpoints or architecture.

duaneb 11y ago

> Bad programmers worry about code, good programmers worry about data structures? Bingo. At this scale, all that matters are the bounds a service can guarantee. So long as it can comply to the bounds, the underlying algorithm (let along language, patterns, etc) doesn't matter. Facebook's development of the HHVM is a perfect example of this—they took a nearly universally despised language (from an engineering perspective) and tooled it to fit into the necessary constraints. While crucial for explaining their stack, it's not in any way necessary for any of the individual nodes.

endtime 11y ago

I think it's a matter of scale, rather than quality - we obviously use languages and frameworks and patterns at Google.

wwweston 11y ago
Scale of operations at Google, or conceptual scale of the diagram? And if you feel like language and framework choice plays a significant enough role at Google that "stack" in the more traditional sense is something that's carefully considered by engineering, I'd love to hear about the details.
- reagency 11y ago
  This diagram is about services that run o a machine and vend data to other machines, not the libraries or frameworks (GWT, etc) that implement the services. This diagram is more "zoomed out"
- endtime 11y ago
  The scale of the diagram, though obviously a diagram of that scale can only be drawn for an organization with operations at that scale - so kind of both. I've mostly done backend/data stuff at Google, so I can't speak to traditional web dev decisions, but I've written design docs which discuss the tradeoffs between using Bigtable and Spanner, or Flume vs. Mapreduce, or one serving strategy vs. another, for some specific thing. Maybe those choices are vaguely analogous to choosing between Postgres or Mongo, nginx or Apache, etc. I imagine the guys who write webapps (not Search, obviously, but internal apps or things like our help pages) consider whether to use App Engine, Angular, Django, etc. on a per-app basis.

asuffield 11y ago

(Tedious disclaimer: my opinion, not my employer's. Not representing anybody else. I'm an SRE at Google, and use some of this stuff all the time.) In all honesty, this diagram is missing so much information that you won't learn very much from it about how we do things (and all the things you can't see are confidential). It's more like a map of the relationships between the few bits that have been published. However, I would tend to agree with your final suggestion that data structures are much more interesting than code.

NicoJuicy 11y ago

Everyone worries about code, but on top of code you have architecture. Worrying about code makes other programmers life easier, just like worrying about endpoints or architecture.