3 ms·

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.

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.