6 ms·

I think the key difference here is that there is no network in between components in a componentized monolith, each component runs the entire “monorepo”

by jurre 6y ago

dodobirdlord 6y ago
Whether there’s actually network between components is something a platform team can handle based on their best judgement. Having collections of containers that always run together is a common pattern.
- pbourke 6y ago
  Certainly, but such a system is not a monolith. A core trait of the monolith is that there are no network calls between components.
  - deleted 6y ago
    [deleted]
  - inopinatus 6y ago
    This negative-space definition of "monolith" is unhelpful to the point of irrelevance. It's unreasonable, in the sense that adopting it gives us nothing to reason about, as with the comment above. By such a standard the last monolithic in-service system was a Burroughs mainframe ca. 1975. I've got statically linked binaries that would fail this definition. Even the plainest Rails application depends on network traffic, including to communicate with parts of itself. It cannot function without an operating system, which is also talking to parts of itself via network protocols, and this runs on a server whose internal buses are themselves a distributed system. It's networks, all the way down, and a heads-in-the-sand attitude doesn't help us reason about performance, reliability, scalability, maintainability et cetera. Put this in a "Falsehoods programmers believe ...": calling a stateless function in a stack-based language to compute an immutable result won't lead to a network call. Monolithic applications are defined by something they are, not something they don't do, and what they are is a single unit of code for development and deployment purposes that includes everything necessary to fulfil an entire system's purpose. The issue of intentionally crossing a network boundary, and when, and why, is an dependent topic in comparative systems architecture, but it's analytically orthogonal.
thebean11 6y ago
Is there really that big of an advantage to avoiding the network boundary though?
- gen220 6y ago
  I think there used to be, before "off-the-shelf" RPC frameworks, service discovery, and the like were mature. There still are, for very small companies. In 2020, if you have an eng count of >50: you use gRPC, some sort of service discovery solution (consul, envoy, whatever), and you basically never have to think about the costs of network hops. Opentracing is also pretty mature these days, although in my experience it's never been necessary when I can read the source of the services my code depends on. Network boundaries are really useful for enforcing interface boundaries, because we should trust N>50 programmers to correctly-implement bounded contexts as much as we trust PG&E to maintain the power grid. That being said, if you have a small, crack team, bounded contexts will take you all the way there and you don't need network boundaries to enforce them.
- nthj 6y ago
  Absolutely: * Avoid network and JSON serialization overhead * Perform larger refactorings or renamings without considering deployment staggering or API versioning * testing locally is far easier * Debugging in production is far easier * Useful error stack traces are included for free * Avoid (probable in my experience, at least in larger security software organizations) dependency on SecOps to make network changes to support a refactoring or introducing new components If an organization is or will pursue a FedRAMP certification, as I understand it, that organization must propose and receive approval every time data may hit a network. Avoiding the network in that case may be the difference between a 50-line MR that's merged before lunch and a multi-week process involving multiple people.
  - closeparen 6y ago
    How are you getting around API versioning with independently deployable components?
    - 6y ago
deleted 6y ago
[deleted]

I think the key difference here is that there is no network in between components in a componentized monolith, each component runs the entire “monorepo”

by jurre 6y ago

I think the key difference here is that there is no network in between components in a componentized monolith, each component runs the entire “monorepo”

dodobirdlord 6y ago

Whether there’s actually network between components is something a platform team can handle based on their best judgement. Having collections of containers that always run together is a common pattern.

pbourke 6y ago
Certainly, but such a system is not a monolith. A core trait of the monolith is that there are no network calls between components.
- deleted 6y ago
  [deleted]
- inopinatus 6y ago
  This negative-space definition of "monolith" is unhelpful to the point of irrelevance. It's unreasonable, in the sense that adopting it gives us nothing to reason about, as with the comment above. By such a standard the last monolithic in-service system was a Burroughs mainframe ca. 1975. I've got statically linked binaries that would fail this definition. Even the plainest Rails application depends on network traffic, including to communicate with parts of itself. It cannot function without an operating system, which is also talking to parts of itself via network protocols, and this runs on a server whose internal buses are themselves a distributed system. It's networks, all the way down, and a heads-in-the-sand attitude doesn't help us reason about performance, reliability, scalability, maintainability et cetera. Put this in a "Falsehoods programmers believe ...": calling a stateless function in a stack-based language to compute an immutable result won't lead to a network call. Monolithic applications are defined by something they are, not something they don't do, and what they are is a single unit of code for development and deployment purposes that includes everything necessary to fulfil an entire system's purpose. The issue of intentionally crossing a network boundary, and when, and why, is an dependent topic in comparative systems architecture, but it's analytically orthogonal.

thebean11 6y ago

Is there really that big of an advantage to avoiding the network boundary though?

gen220 6y ago
I think there used to be, before "off-the-shelf" RPC frameworks, service discovery, and the like were mature. There still are, for very small companies. In 2020, if you have an eng count of >50: you use gRPC, some sort of service discovery solution (consul, envoy, whatever), and you basically never have to think about the costs of network hops. Opentracing is also pretty mature these days, although in my experience it's never been necessary when I can read the source of the services my code depends on. Network boundaries are really useful for enforcing interface boundaries, because we should trust N>50 programmers to correctly-implement bounded contexts as much as we trust PG&E to maintain the power grid. That being said, if you have a small, crack team, bounded contexts will take you all the way there and you don't need network boundaries to enforce them.
nthj 6y ago
Absolutely: * Avoid network and JSON serialization overhead * Perform larger refactorings or renamings without considering deployment staggering or API versioning * testing locally is far easier * Debugging in production is far easier * Useful error stack traces are included for free * Avoid (probable in my experience, at least in larger security software organizations) dependency on SecOps to make network changes to support a refactoring or introducing new components If an organization is or will pursue a FedRAMP certification, as I understand it, that organization must propose and receive approval every time data may hit a network. Avoiding the network in that case may be the difference between a 50-line MR that's merged before lunch and a multi-week process involving multiple people.
- closeparen 6y ago
  How are you getting around API versioning with independently deployable components?
  - 6y ago

deleted 6y ago

[deleted]