4 ms·
Author here. The "monolith" I'm describing is an application-level characteristic. The deployment container, whether it's a bare metal server, a VM, or a Docker
by DVassallo 7y ago
Author here. The "monolith" I'm describing is an application-level characteristic. The deployment container, whether it's a bare metal server, a VM, or a Docker container doesn't matter.
I admit that my definition is not necessarily universal, but IMO the characteristics I listed are all highly desirable. I pushed for this model when I worked at Amazon (an AWS service as 1 monolith) and I've seen it work great even at large scale (close to 10K hosts, millions of requests per second, etc).
- mlthoughts2018 7y agoI’d say most of the properties you mention are highly undesirable, especially monorepo and single executable. But regardless, I think monolith has to be defined at the behavioral level: does one system perform multiple completely independent behaviors? Must you change the same singleton codebase/artifact to effect two totally separate concerns? And indeed this is basically why all types of “mono” workflows (monorepo/monoapp, whatever) are intrinsically bad designs. That you can solve problems in spite of this through intense extra scaffolding bolted into the mono stuff is not any type of endorsement that it’s a good way.
- badrabbit 7y agoInteresting,thanks for clarifying.