6 ms·

> they went over how they handle a billion requests a day with mostly a Rails monolith 1 day has 246060=86400 seconds. 1bn/86400 is more than 10000 reqs/second

> they went over how they handle a billion requests a day with mostly a Rails monolith 1 day has 246060=86400 seconds. 1bn/86400 is more than 10000 reqs/second, so each request has to be served in less than 100 us. According to [1], random access on an SSD is about 150us. This suggests to me it's likely that most of these are being served cached from a CDN. Are we supposed to be surprised that this can be done by a rails monolith? We don't know how many of those requests are actually hitting the rails app. [1] https://gist.github.com/jboner/2841832 https://gist.github.com/jboner/2841832

ajmurmann 4y ago
There is no limitation that this has to be served by a single server
- sdrwefgfvb 4y ago
  Wait, so in what sense is it a monolith then? :D
  - nkozyra 4y ago
    Not sure how much is sincere here, but a monolith typically means "not microservice architecture" and has very little-to-nothing to do with the ops side.
    - sdrwefgfvb 4y ago
      Well if you're distributing requests over multiple servers, I wouldn't call that a monolith.
      - macksd 4y ago
        Nevertheless, that's a pretty common term when the compute portion of the application is a single tier, but that doesn't mean that the tier can't scale over many stateless compute nodes.
      - aqme28 4y ago
        Monolith refers mostly to the code, not the distribution of app servers. There's one app (a monolith) served multiple times.
      - ancount 4y ago
        Here is some Microsoft documentation describing how a monolith application can be deployed behind a load balancer[0]. HTH [0] https://docs.microsoft.com/en-us/dotnet/architecture/containerized-lifecycle/design-develop-containerized-apps/monolithic-applications https://docs.microsoft.com/en-us/dotnet/architecture/contain...
      - deleted 4y ago
        [deleted]
      - soggybutter 4y ago
        If your definition of a monolith refers to a singular server, then I've never worked on a monolith in my life. Even the crufty old ASP apps I used to work on weren't monoliths. This would also mean that deploying a microservice architecture onto a single server, using docker for example, would be considered a monolith. Or even better, any application that leverages a database on a separate server is no longer a monolith! That's way easier than rearchitecting your whole app. I've never come across a definition for monolith in the context of software that had anything to do with the actual infrastructure employed
      - emaginniss 4y ago
        I believe you're alone in using that definition
      - xeromal 4y ago
        You're mistaken then. Monolith is just project organization. Think microservices and then realize the monolith is on the other end of the spectrum. It's in the name.
      - foobiekr 4y ago
        You keep posting this. A monolith is a software architecture. It says nothing about there being one instance of that monolithic process or a billion any more than "microservice architecture" becomes untrue unless you have k instances of any particular service. It's like saying "this thing says it is built as a suspension bridge, but there are ten of them, so I wouldn't call it a bridge."
  - ajmurmann 4y ago
    You got some good, but short answers. Since you asked me, I'll give you my definition: It means that your app servers are homogenous. They are all running the same server code in similar configuration. How many instances you are running has nothing to do with it being a monolith or not. You need more than one server just to get some fault tolerance. In practice your scalability bottleneck will typically be your database as all servers share that and your servers themselves ideally are stateless (they typically are for Rails apps, as Zendesk is using Rails). Microservices on the other hand in theory have a number of very small services that at most share some libraries, but can be deployed independently and could each even be written in different languages if you want. This mostly is an advantage if you know that different portions of your app are gonna scale very differently from each other and rely on disparate data models as well and only share a small interface. In practice, things frequently don't end up as clear cut as you expected on the outset and you end up having to heavily coordinate many of your deploys across services.
ubertaco 4y ago
This math assumes that the requests are serial (each begins and completes before the next one starts), rather than concurrent.
- sdrwefgfvb 4y ago
  Can you do concurrent reads to a disk? I actually don't know the answer to this. I'm pretty sure you can't on an HDD, but I don't know about an SSD.
  - ekianjo 4y ago
    The requests are not happening on a single server
    - sdrwefgfvb 4y ago
      I wouldn't call that a monolith then.
      - tyre 4y ago
        Monolith refers to the application. It’s in contrast to a services architecture.
      - lolinder 4y ago
        If it's all one codebase that isn't split for deployment, it's still very much a monolith. The distinction between monolith and microservices isn't how many deployments you have, it's how many deployment units. If the app is stateless, replication is strictly an operations concern, so from a developer perspective a single stateless deployment unit is a monolith. An org might deploy a complete copy of the monolith for a single tenant, and it would still be a monolithic architecture.
  - kvirani 4y ago
    Does each web request to an app server have to hit the disk on the same server? And if so, for the entire request duration? Also, what about horizontal scaling which also means that the db is on a different server (likely with secondary / replicated DBs)
hadrien01 4y ago
Rails monoliths (any monolith actually) don't have to be deployed only once, they can still scale if needed.
nkozyra 4y ago
A site that big is clearly distributed and parallelized in addition to the caching.
deleted 4y ago
[deleted]
rfrey 4y ago
Below, you're doubling down on the "monolith == 1 server" point. You should do a bit of research before you continue, the word doesn't mean what you think it means.
- KronisLV 4y ago
  > You should do a bit of research before you continue, the word doesn't mean what you think it means. I'd suggest that the word means whatever the majority of people assume it means - that's also how we get the meaning of "agile" to be so inconsistent, depending on which companies/teams/people you talk to. Essentially, people who've only worked with projects that run as single instances might have a pretty different opinion on what a "monolith" is. I've definitely met a lot of people who'd claim that a single application package across multiple servers is no longer a monolith. The reasoning would probably go along the lines of this: "If a monolith can live on multiple servers, what do you call an application that can only ever live on a single server, with a single instance being launched at the same time?" So essentially, what would be the names best suited to describe: - a single codebase that can only run as a single instance - a single codebase that can be deployed with multiple concurrent instances Personally, I think it might be worthwhile to also answer that, so we have a better idea of what to name things. Otherwise we end up with messes like people taking DDD too far and having a separate microservice per business entity, because they read into the "micro" part of microservices too much. Oh, also, in regards to the definition of "monolith" that is centered around only how the code itself is deployed, personally I think that a modular monolith ("modulith"? heh) is a great architecture that doesn't get explored nearly enough! A single codebase that is easy to reason about, a single executable that is probably scalable but also simple to deploy however you need, with different parts of the functionality (think front end, different types of API, reporting functionality, file upload functionality etc.) being possible to enable/disable in each of the instances based on feature flags. Want everything on a single instance? Flip all of the flags to "on". Multiple instances? Configure whatever modules you want, where ever you need.
  - ajmurmann 4y ago
    > "If a monolith can live on multiple servers, what do you call an application that can only ever live on a single server, with a single instance being launched at the same time?" That exists? Are there examples of this, especially once where there is a good reason for this? I cannot even begin to list all the awful issues with this in my head.

ajmurmann 4y ago

There is no limitation that this has to be served by a single server

sdrwefgfvb 4y ago
Wait, so in what sense is it a monolith then? :D
- nkozyra 4y ago
  Not sure how much is sincere here, but a monolith typically means "not microservice architecture" and has very little-to-nothing to do with the ops side.
  - sdrwefgfvb 4y ago
    Well if you're distributing requests over multiple servers, I wouldn't call that a monolith.
    - macksd 4y ago
      Nevertheless, that's a pretty common term when the compute portion of the application is a single tier, but that doesn't mean that the tier can't scale over many stateless compute nodes.
    - aqme28 4y ago
      Monolith refers mostly to the code, not the distribution of app servers. There's one app (a monolith) served multiple times.
    - ancount 4y ago
      Here is some Microsoft documentation describing how a monolith application can be deployed behind a load balancer[0]. HTH [0] https://docs.microsoft.com/en-us/dotnet/architecture/containerized-lifecycle/design-develop-containerized-apps/monolithic-applications https://docs.microsoft.com/en-us/dotnet/architecture/contain...
    - deleted 4y ago
      [deleted]
    - soggybutter 4y ago
      If your definition of a monolith refers to a singular server, then I've never worked on a monolith in my life. Even the crufty old ASP apps I used to work on weren't monoliths. This would also mean that deploying a microservice architecture onto a single server, using docker for example, would be considered a monolith. Or even better, any application that leverages a database on a separate server is no longer a monolith! That's way easier than rearchitecting your whole app. I've never come across a definition for monolith in the context of software that had anything to do with the actual infrastructure employed
    - emaginniss 4y ago
      I believe you're alone in using that definition
    - xeromal 4y ago
      You're mistaken then. Monolith is just project organization. Think microservices and then realize the monolith is on the other end of the spectrum. It's in the name.
    - foobiekr 4y ago
      You keep posting this. A monolith is a software architecture. It says nothing about there being one instance of that monolithic process or a billion any more than "microservice architecture" becomes untrue unless you have k instances of any particular service. It's like saying "this thing says it is built as a suspension bridge, but there are ten of them, so I wouldn't call it a bridge."
- ajmurmann 4y ago
  You got some good, but short answers. Since you asked me, I'll give you my definition: It means that your app servers are homogenous. They are all running the same server code in similar configuration. How many instances you are running has nothing to do with it being a monolith or not. You need more than one server just to get some fault tolerance. In practice your scalability bottleneck will typically be your database as all servers share that and your servers themselves ideally are stateless (they typically are for Rails apps, as Zendesk is using Rails). Microservices on the other hand in theory have a number of very small services that at most share some libraries, but can be deployed independently and could each even be written in different languages if you want. This mostly is an advantage if you know that different portions of your app are gonna scale very differently from each other and rely on disparate data models as well and only share a small interface. In practice, things frequently don't end up as clear cut as you expected on the outset and you end up having to heavily coordinate many of your deploys across services.

ubertaco 4y ago

This math assumes that the requests are serial (each begins and completes before the next one starts), rather than concurrent.

sdrwefgfvb 4y ago
Can you do concurrent reads to a disk? I actually don't know the answer to this. I'm pretty sure you can't on an HDD, but I don't know about an SSD.
- ekianjo 4y ago
  The requests are not happening on a single server
  - sdrwefgfvb 4y ago
    I wouldn't call that a monolith then.
    - tyre 4y ago
      Monolith refers to the application. It’s in contrast to a services architecture.
    - lolinder 4y ago
      If it's all one codebase that isn't split for deployment, it's still very much a monolith. The distinction between monolith and microservices isn't how many deployments you have, it's how many deployment units. If the app is stateless, replication is strictly an operations concern, so from a developer perspective a single stateless deployment unit is a monolith. An org might deploy a complete copy of the monolith for a single tenant, and it would still be a monolithic architecture.
- kvirani 4y ago
  Does each web request to an app server have to hit the disk on the same server? And if so, for the entire request duration? Also, what about horizontal scaling which also means that the db is on a different server (likely with secondary / replicated DBs)

hadrien01 4y ago

Rails monoliths (any monolith actually) don't have to be deployed only once, they can still scale if needed.

nkozyra 4y ago

A site that big is clearly distributed and parallelized in addition to the caching.

deleted 4y ago

[deleted]

rfrey 4y ago

Below, you're doubling down on the "monolith == 1 server" point. You should do a bit of research before you continue, the word doesn't mean what you think it means.

KronisLV 4y ago
> You should do a bit of research before you continue, the word doesn't mean what you think it means. I'd suggest that the word means whatever the majority of people assume it means - that's also how we get the meaning of "agile" to be so inconsistent, depending on which companies/teams/people you talk to. Essentially, people who've only worked with projects that run as single instances might have a pretty different opinion on what a "monolith" is. I've definitely met a lot of people who'd claim that a single application package across multiple servers is no longer a monolith. The reasoning would probably go along the lines of this: "If a monolith can live on multiple servers, what do you call an application that can only ever live on a single server, with a single instance being launched at the same time?" So essentially, what would be the names best suited to describe: - a single codebase that can only run as a single instance - a single codebase that can be deployed with multiple concurrent instances Personally, I think it might be worthwhile to also answer that, so we have a better idea of what to name things. Otherwise we end up with messes like people taking DDD too far and having a separate microservice per business entity, because they read into the "micro" part of microservices too much. Oh, also, in regards to the definition of "monolith" that is centered around only how the code itself is deployed, personally I think that a modular monolith ("modulith"? heh) is a great architecture that doesn't get explored nearly enough! A single codebase that is easy to reason about, a single executable that is probably scalable but also simple to deploy however you need, with different parts of the functionality (think front end, different types of API, reporting functionality, file upload functionality etc.) being possible to enable/disable in each of the instances based on feature flags. Want everything on a single instance? Flip all of the flags to "on". Multiple instances? Configure whatever modules you want, where ever you need.
- ajmurmann 4y ago
  > "If a monolith can live on multiple servers, what do you call an application that can only ever live on a single server, with a single instance being launched at the same time?" That exists? Are there examples of this, especially once where there is a good reason for this? I cannot even begin to list all the awful issues with this in my head.