4 ms·

"To get similar characteristics from a monolith, developers need: Incremental build systems Incremental testing frameworks Branch management tool

"To get similar characteristics from a monolith, developers need: Incremental build systems Incremental testing frameworks Branch management tooling Code isolation enforcement Database isolation enforcement" This sounds a lot like microservices, most of all the last point. Is the only difference that you don't use RPCs?

nine_k 2y ago
> the only difference that you don't use RPCs But it's a huge difference. No RPC overhead. No lost / duplicate PRC messages. All logs can literally go to the same file (via e.g. simple syslog). Local deployment is dead simple, and you can't forget to start any service. Prod deployment never needs to handle a mix of versions among deployed services. Beside that, the build step is much simpler. Common libraries' versions can never diverge, because there's one copy per the whole binary (can be a disadvantage sometimes, too). You can attach a debugger and follow the entire chain, even if it crosses the boundaries of the modules. With that, you can make self-contained modules as small is it makes logical sense. You can pretty cheaply move pieces of functionality from one module to another, if it makes better sense. It's trivially easy to factor out common parts into another self-contained module. Still you have all the advantages of fast incremental / partial builds, contained dependencies, and some of the advantages of isolated / parallel testing. But most importantly, it preserves your sanity by limiting the scope of most changes to a single module.
- paperplatter 2y ago
  There would be a mix of versions, managed via branches. The part about debuggability sounded appealing at first, but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. If these were RPCs, you could use some common prod or staging instance for things you don't want to bother running locally.
  - nine_k 2y ago
    > There would be a mix of versions, managed via branches "We build the image slated for deployment from the release branch which is cut from master daily / weekly at noon." Works for MPOW, and some previous places. It's a monolith, there are rules! > but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. Agreed! Maye that would be a reason to split the thing finally into separate services. Not necessarily micro-services, just into parts that are self-contained enough. But most code bases are not nearly as heavyweight. They can work pretty well as a monolith, run as a whole on a decent laptop, along with a database or two, or even three (typically Postgres, Redis, and Elastic). I know because I did it many times, and a ton of other people did. Worse yet, I ran the whole bunch of microservices, much like production, locally, again, as many a developer here did, too. At the scale this small, the complexity just slows you down. > use some common prod or staging instance for things you don't want to bother running locally. I've seen this in much bigger projects, and there it made complete sense. When you have to move literally a ton, it makes sense to use a forklift. But if the thing is a stack of papers that fits into a backpack, the forklift is an unnecessary bulk and expense. It could sill be a neatly organized stack of papers, not a shapeless wad.
    - paperplatter 2y ago
      I'd avoid having separate services share a DB. Besides the overhead, you get scary hidden dependencies that way. If this approach is considered not micro but rather an in-between, the article should mention it as an option.
      - nine_k 2y ago
        Indeed, they should not share a DB (except maybe Redis as a common cache, with a single writer per item type).. But a single Postgres installation can run multiple schemas / users, so you only need to run one Postgres container locally.
pjmlp 2y ago
Which tends to be available in all major compiled languages. Don't use scripting monkey patching friendly languages for applications.
- paperplatter 2y ago
  If by scripting monkey friendly you mean Javascript or Python, nah I'm going to use that.

nine_k 2y ago

> the only difference that you don't use RPCs But it's a huge difference. No RPC overhead. No lost / duplicate PRC messages. All logs can literally go to the same file (via e.g. simple syslog). Local deployment is dead simple, and you can't forget to start any service. Prod deployment never needs to handle a mix of versions among deployed services. Beside that, the build step is much simpler. Common libraries' versions can never diverge, because there's one copy per the whole binary (can be a disadvantage sometimes, too). You can attach a debugger and follow the entire chain, even if it crosses the boundaries of the modules. With that, you can make self-contained modules as small is it makes logical sense. You can pretty cheaply move pieces of functionality from one module to another, if it makes better sense. It's trivially easy to factor out common parts into another self-contained module. Still you have all the advantages of fast incremental / partial builds, contained dependencies, and some of the advantages of isolated / parallel testing. But most importantly, it preserves your sanity by limiting the scope of most changes to a single module.

paperplatter 2y ago
There would be a mix of versions, managed via branches. The part about debuggability sounded appealing at first, but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. If these were RPCs, you could use some common prod or staging instance for things you don't want to bother running locally.
- nine_k 2y ago
  > There would be a mix of versions, managed via branches "We build the image slated for deployment from the release branch which is cut from master daily / weekly at noon." Works for MPOW, and some previous places. It's a monolith, there are rules! > but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. Agreed! Maye that would be a reason to split the thing finally into separate services. Not necessarily micro-services, just into parts that are self-contained enough. But most code bases are not nearly as heavyweight. They can work pretty well as a monolith, run as a whole on a decent laptop, along with a database or two, or even three (typically Postgres, Redis, and Elastic). I know because I did it many times, and a ton of other people did. Worse yet, I ran the whole bunch of microservices, much like production, locally, again, as many a developer here did, too. At the scale this small, the complexity just slows you down. > use some common prod or staging instance for things you don't want to bother running locally. I've seen this in much bigger projects, and there it made complete sense. When you have to move literally a ton, it makes sense to use a forklift. But if the thing is a stack of papers that fits into a backpack, the forklift is an unnecessary bulk and expense. It could sill be a neatly organized stack of papers, not a shapeless wad.
  - paperplatter 2y ago
    I'd avoid having separate services share a DB. Besides the overhead, you get scary hidden dependencies that way. If this approach is considered not micro but rather an in-between, the article should mention it as an option.
    - nine_k 2y ago
      Indeed, they should not share a DB (except maybe Redis as a common cache, with a single writer per item type).. But a single Postgres installation can run multiple schemas / users, so you only need to run one Postgres container locally.

pjmlp 2y ago

Which tends to be available in all major compiled languages. Don't use scripting monkey patching friendly languages for applications.

paperplatter 2y ago
If by scripting monkey friendly you mean Javascript or Python, nah I'm going to use that.