Comments
Hacker News
I’ve been building a lot on cloudflare workers recently and I feel like microservice works pretty well there.
Sometimes you want to have some shared infra abstracted behind a single interface and a single auth model.
Having a service gives you that single isolated unit/abstraction.
In practice it’s always a scale. Some services will be bigger and some will naturally be split out.
I think also having the right server platform that makes it trivial to deploy/standup infra quickly makes this much easier.
by aleksiy123
A "real" microservice (according to some definitions) might be only really necessary for organizational reasons.
But the services in a distributed monolith are also often called microservices (at least in my company).
And for them I believe there is another good reason that I do not hear about in these discussions: robustness.
In our software project, we have had many issues with OOM and golang panics in a goroutine killing our critical endpoint even though the fault was most times caused in the administrational endpoints. By separating the critical endpoint from our administrational ones in two separate services, we reduced the criticality of those issues and therefore also the number of hotfixes we needed.
by linbaato
I decided to take a career break and build an open source project to manage services better. Feedbacks are welcome, product is too early for adoption.
https://github.com/GoPlasmatic/Orion
Design principles: * Isolate business logic from service framework using declarative coding * Make the logic representation machine-writable so AI is a first-class author * Treat business logic as versioned data, not compiled services * Ship governance with the platform, not with each service * Invoke services in-process, not over the network * Modular monolith — export and scale a service independently when needed * Push integrations into declarative connectors, keep logic pure
by codetiger
Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding.
Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.
by dspillett
I feel like the discussion between "monolith" and "microservices" is a false dichotomy.
For a big software company, you don't have to ship a single behemoth monolith, but you don't have have microservices so small that a team of 3 has to manage 10 services.
You can have "right size" services. I don't like to call them micro because they can be fairly big and do multiple things, as long as it makes sense to have them in a single service.
by eloisant
> Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain.
I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.
In a microservice, I publish an interface, and I'm free to tear up all the carpet behind it as long as it keeps doing its job as advertised. Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.
by mrkeen
In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems)
There are two things monoliths can't easily offer:
* Using different frameworks, languages, etc. But in my experience, it's pretty rare for a team to use many programming languages at once. Usually, it's just a few highly performance-sensitive services that need to be written in another language (say, a proxy in Rust while the rest is in Python). For that, I prefer an architecture with one main monolith plus a few high-performance satellite services. No problem there.
* More optimized scaling in certain scenarios. Say I have a module that processes files and can use all available CPU. I might want to put it in a separate container on another node so that the processing doesn't destabilize the core web server. Technically, monoliths support this too, just run the monolith in a different mode (say, behind an `--image-process` flag of sorts), and you can schedule it on another node in the same way. The only downside is that it may use more RAM than necessary for the extra binaries or scripts that won't be used
What else am I missing?
by kgeist
This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries.
by turnersauce
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I’ve been building a lot on cloudflare workers recently and I feel like microservice works pretty well there.
Sometimes you want to have some shared infra abstracted behind a single interface and a single auth model.
Having a service gives you that single isolated unit/abstraction.
In practice it’s always a scale. Some services will be bigger and some will naturally be split out.
I think also having the right server platform that makes it trivial to deploy/standup infra quickly makes this much easier.
by aleksiy123 - A "real" microservice (according to some definitions) might be only really necessary for organizational reasons. But the services in a distributed monolith are also often called microservices (at least in my company). And for them I believe there is another good reason that I do not hear about in these discussions: robustness.
In our software project, we have had many issues with OOM and golang panics in a goroutine killing our critical endpoint even though the fault was most times caused in the administrational endpoints. By separating the critical endpoint from our administrational ones in two separate services, we reduced the criticality of those issues and therefore also the number of hotfixes we needed.
by linbaato - I decided to take a career break and build an open source project to manage services better. Feedbacks are welcome, product is too early for adoption.
https://github.com/GoPlasmatic/Orion
Design principles: * Isolate business logic from service framework using declarative coding * Make the logic representation machine-writable so AI is a first-class author * Treat business logic as versioned data, not compiled services * Ship governance with the platform, not with each service * Invoke services in-process, not over the network * Modular monolith — export and scale a service independently when needed * Push integrations into declarative connectors, keep logic pure
by codetiger - Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding.
Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.
by dspillett - I feel like the discussion between "monolith" and "microservices" is a false dichotomy.
For a big software company, you don't have to ship a single behemoth monolith, but you don't have have microservices so small that a team of 3 has to manage 10 services.
You can have "right size" services. I don't like to call them micro because they can be fairly big and do multiple things, as long as it makes sense to have them in a single service.
by eloisant - > Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain.
I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.
In a microservice, I publish an interface, and I'm free to tear up all the carpet behind it as long as it keeps doing its job as advertised. Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.
by mrkeen - In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems)
There are two things monoliths can't easily offer:
* Using different frameworks, languages, etc. But in my experience, it's pretty rare for a team to use many programming languages at once. Usually, it's just a few highly performance-sensitive services that need to be written in another language (say, a proxy in Rust while the rest is in Python). For that, I prefer an architecture with one main monolith plus a few high-performance satellite services. No problem there.
* More optimized scaling in certain scenarios. Say I have a module that processes files and can use all available CPU. I might want to put it in a separate container on another node so that the processing doesn't destabilize the core web server. Technically, monoliths support this too, just run the monolith in a different mode (say, behind an `--image-process` flag of sorts), and you can schedule it on another node in the same way. The only downside is that it may use more RAM than necessary for the extra binaries or scripts that won't be used
What else am I missing?
by kgeist - This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries.by turnersauce