6 ms·

> Wonder if we will see a full circle back to monoliths. For global-scale web applications? Obviously you won't. High-availability, low latency, resilience, sc

> Wonder if we will see a full circle back to monoliths. For global-scale web applications? Obviously you won't. High-availability, low latency, resilience, scalability, performance. You don't get any of that by running your app on a single box. That ship has sailed two or three decades ago. Physics establishes all the limits, not software architects. Distributed system critics, where they fixate on trendy microservices architectures or poopoo other suggestions like DOMA, should take a step back and look at themselves and what they are actually complaining about. Yes, a solution with no moving parts is simpler than a solution with some moving parts. But have you really noticed what problems are being solved by adding these pieces?

inopinatus 6y ago
Monoliths don't run on a single box. My entire current business runs on a single monolithic application, and it's running across multiple AZs with five different instance roles (consumer site, API endpoint, admin site, background jobs, and reporting), sized by memory demand and contention efficiency, then scaled horizontally according to workload demand. They are all, however, running exactly the same code, just in different configuration. I'd say it's roughly speaking 80% core libraries and the remaining 20% varies by role. I have a command-line control & observation tool that comes in bin/ of the same repository, and it is again wrapped around the same code besides. That's the modern monolith in production.
- rumanator 6y ago
  It seems you should revise your concept of monolith because your description is anything but it. I mean, you yourself talk about "different instance roles". You should pay attention to your own claims: if you have a distributed deployment comprised of different nodes, and you have specialized nodes that you yourself state that are ran to handle limited and very specific responsibilities, then just because you decided, for any reason that only you can think about, to bundle everything in a single project... That doesn't make it a monolith, does it? Just to be absolutely clear, "monolith" is not a reference to how you chose to organize your source tree. Monolith is a software architecture concept that defines how your whole application is organized and deployed. A distributed system comprised of multiple specialized processeses running independently is not a monolith, even if you somehow believed it was a good idea to pick which role you run through configuration.
  - inopinatus 6y ago
    > you should > you yourself > You should pay attention > you decided > you yourself state > even if you somehow believed it was a good idea This isn't language anyone should respond to, and not merely because it's staking out a fine example of the No True Scotsman fallacy. > you yourself state that are ran to handle limited and very specific responsibilities I didn't. > Just to be absolutely clear, "monolith" is not a reference to how you chose to organize your source tree Again, that's a straw man - I never said it was. Although I can certainly see how someone who was absolutely determined to make an unnecessarily bitter remonstration as personal as possible might - through either branch of Hanlon's razor - misconstrue the words "the same repository" adversarially for the purposes of their ego trip. It's a monolithic application because any of the instances could perform any of the roles, and they're all running exactly the same code. They're distinguished in production for the purposes of operational sanity, because only a flaming idiot would, say, run reporting workloads on the API host. But when I stand up a demo / showcase environment, for example, it has exactly one instance that does everything, and we can (and do) develop with the whole thing running single process on our laptops. I shouldn't need to clarify any of this, because the point being made was a rebuttal to the "single box" thesis, not whether I met some gatekeeper's opinion about my standing to discuss the topic.
  - mytailorisrich 6y ago
    Absolutely. Having a single binary that runs different services depending on the configuration and is deployed as such creates a distributed system, not a "monolith". I am not clear about the advantages of doing that.
- mytailorisrich 6y ago
  A monolith does run on a single box. If you split it in order to run on several boxes you have by definition turned your monolith into a distributed system.
  - inopinatus 6y ago
    Deployment architecture does not define monolithic. The empirical example is that, say, Shopify and Basecamp both described their applications as monolithic. However, there's a more comprehensive demonstration, in that we can't define "box" without contradiction. When you consider the many shells of virtualisation we use, the fact that any web application is by definition accessed over a network (and therefore distributed), and the internal architecture of a modern server, which is practically a distributed federation, or even the coordination between threads in a single process, it leads inevitably to contradiction (if you're careful) or just a messy quagmire of conflicting definitions. The final nail in this dichotomous coffin is that the converse is also untrue, since any microservice-based application can be deployed on one box. Whichever way you look through the scope, deployment model turns out orthogonal to the taxonomy of software architecture.
    - mytailorisrich 6y ago
      There is no conflicting definition and I'm not quite sure what your reply is about. Quite obviously the point is not whether a microservice-based app can be deployed on a single box. It obviously can. The point is that you split your app in order to deploy different pieces to different boxes then you have a distributed system and no longer a monolith.
      - inopinatus 6y ago
        My point is that this definition has nothing to do with software, and in fact would mean that the last monolithic system was a Burroughs mainframe ca. 1960. This either invalidates the definition reductio ad absurdum, or confirms it but renders the term basically unusable.
pjmlp 6y ago
Yes, doing distributed systems programming since around 1996. List of stacks I have used in some form since then, raw TCP/IP for in-house RPC protocol, SUN RPC, RMI, COM/DCOM, XML-RPC, SOAP, CORBA, REST, WCF and apparently gRPC is the new fashion. At the same time, I also done modular development with teams responsible for modules, where the language features for creating modules, defining interfaces, and use binary dependencies are taken into use. What I usually see with most "distributed systems" is that they are used as a physical solution for teams that never written a proper module in their life. If monoliths with total lack of modularity are hard to debug, spaghetti network calls are even less fun.

inopinatus 6y ago

Monoliths don't run on a single box. My entire current business runs on a single monolithic application, and it's running across multiple AZs with five different instance roles (consumer site, API endpoint, admin site, background jobs, and reporting), sized by memory demand and contention efficiency, then scaled horizontally according to workload demand. They are all, however, running exactly the same code, just in different configuration. I'd say it's roughly speaking 80% core libraries and the remaining 20% varies by role. I have a command-line control & observation tool that comes in bin/ of the same repository, and it is again wrapped around the same code besides. That's the modern monolith in production.

rumanator 6y ago
It seems you should revise your concept of monolith because your description is anything but it. I mean, you yourself talk about "different instance roles". You should pay attention to your own claims: if you have a distributed deployment comprised of different nodes, and you have specialized nodes that you yourself state that are ran to handle limited and very specific responsibilities, then just because you decided, for any reason that only you can think about, to bundle everything in a single project... That doesn't make it a monolith, does it? Just to be absolutely clear, "monolith" is not a reference to how you chose to organize your source tree. Monolith is a software architecture concept that defines how your whole application is organized and deployed. A distributed system comprised of multiple specialized processeses running independently is not a monolith, even if you somehow believed it was a good idea to pick which role you run through configuration.
- inopinatus 6y ago
  > you should > you yourself > You should pay attention > you decided > you yourself state > even if you somehow believed it was a good idea This isn't language anyone should respond to, and not merely because it's staking out a fine example of the No True Scotsman fallacy. > you yourself state that are ran to handle limited and very specific responsibilities I didn't. > Just to be absolutely clear, "monolith" is not a reference to how you chose to organize your source tree Again, that's a straw man - I never said it was. Although I can certainly see how someone who was absolutely determined to make an unnecessarily bitter remonstration as personal as possible might - through either branch of Hanlon's razor - misconstrue the words "the same repository" adversarially for the purposes of their ego trip. It's a monolithic application because any of the instances could perform any of the roles, and they're all running exactly the same code. They're distinguished in production for the purposes of operational sanity, because only a flaming idiot would, say, run reporting workloads on the API host. But when I stand up a demo / showcase environment, for example, it has exactly one instance that does everything, and we can (and do) develop with the whole thing running single process on our laptops. I shouldn't need to clarify any of this, because the point being made was a rebuttal to the "single box" thesis, not whether I met some gatekeeper's opinion about my standing to discuss the topic.
- mytailorisrich 6y ago
  Absolutely. Having a single binary that runs different services depending on the configuration and is deployed as such creates a distributed system, not a "monolith". I am not clear about the advantages of doing that.
mytailorisrich 6y ago
A monolith does run on a single box. If you split it in order to run on several boxes you have by definition turned your monolith into a distributed system.
- inopinatus 6y ago
  Deployment architecture does not define monolithic. The empirical example is that, say, Shopify and Basecamp both described their applications as monolithic. However, there's a more comprehensive demonstration, in that we can't define "box" without contradiction. When you consider the many shells of virtualisation we use, the fact that any web application is by definition accessed over a network (and therefore distributed), and the internal architecture of a modern server, which is practically a distributed federation, or even the coordination between threads in a single process, it leads inevitably to contradiction (if you're careful) or just a messy quagmire of conflicting definitions. The final nail in this dichotomous coffin is that the converse is also untrue, since any microservice-based application can be deployed on one box. Whichever way you look through the scope, deployment model turns out orthogonal to the taxonomy of software architecture.
  - mytailorisrich 6y ago
    There is no conflicting definition and I'm not quite sure what your reply is about. Quite obviously the point is not whether a microservice-based app can be deployed on a single box. It obviously can. The point is that you split your app in order to deploy different pieces to different boxes then you have a distributed system and no longer a monolith.
    - inopinatus 6y ago
      My point is that this definition has nothing to do with software, and in fact would mean that the last monolithic system was a Burroughs mainframe ca. 1960. This either invalidates the definition reductio ad absurdum, or confirms it but renders the term basically unusable.

pjmlp 6y ago

Yes, doing distributed systems programming since around 1996. List of stacks I have used in some form since then, raw TCP/IP for in-house RPC protocol, SUN RPC, RMI, COM/DCOM, XML-RPC, SOAP, CORBA, REST, WCF and apparently gRPC is the new fashion. At the same time, I also done modular development with teams responsible for modules, where the language features for creating modules, defining interfaces, and use binary dependencies are taken into use. What I usually see with most "distributed systems" is that they are used as a physical solution for teams that never written a proper module in their life. If monoliths with total lack of modularity are hard to debug, spaghetti network calls are even less fun.