3 ms·

Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertak

Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop"). A monolith can be quite scalable and portable.

coding123 6y ago
Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.
- cameronbrown 6y ago
  Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.
  - coding123 6y ago
    The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).
hvidgaard 6y ago
My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later. By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.
- linkdd 6y ago
  Not doing microservice does not mean doing monolith. There is an in-between that you can aim for.
100011_100001 6y ago
But you don't have to recreate the entire stack, that's the whole point.

coding123 6y ago

Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.

cameronbrown 6y ago
Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.
- coding123 6y ago
  The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).

hvidgaard 6y ago

My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later. By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.

linkdd 6y ago
Not doing microservice does not mean doing monolith. There is an in-between that you can aim for.

100011_100001 6y ago

But you don't have to recreate the entire stack, that's the whole point.