3 ms·

"Anything involving a large framework. What part of "micro" are folks missing? What on earth is a "large" framework? What does the size of a framework (by what

"Anything involving a large framework. What part of "micro" are folks missing? What on earth is a "large" framework? What does the size of a framework (by whatever metric) has to do with the "micro" which refers to a slice of the domain the service is taking care of.

linkdd 6y ago
The author seems to think that a microservice should have as few dependencies as possible. If your business logic is contained in another framework and your microservice just call a subset of those functions, is it really a microservice ?
100011_100001 6y ago
You'll be surprised. A group I work with opted for a microservices approach, a few years later they have 47 tightly coupled "microservices" that have to be deployed all together or they break.
- ryanbrunner 6y ago
  That's unrelated to the framework used to power those things though. You can have perfectly decoupled services running some bloated Java framework or using Go with minimal libraries or whatever. You might prefer one or the other, but it has little do with how much those services fit into the definition of 'microservices'.
- scottious 6y ago
  ah, the dreaded distributed monolith. I hope this is looked at as a terrible anti-pattern someday. "But we can deploy services independently" they say, "we can scale these services independently too!", "We can finally scale our development team!" Years later: no services are scaled independently. Deployments are a mess. Most deploys end up having to be lock-stop deploys. Issues are incredibly hard to track down because of complex network interactions. For some reason 7 of them are written in Rust and only 1 guy knows Rust. Stack traces become almost worthless. You find yourself having to piece together log files across tons of services to track down issues. You have hundreds of Jenkins jobs for deploying services.
sorokod 6y ago
For me framework here is a bunch of software that solves a problem that is othogonal to the business domain: logging, networking, Db access etc. An upstream service is not a framework in this context.
rualca 6y ago
> What on earth is a "large" framework? What does the size of a framework (by whatever metric) has to do with the "micro" which refers to a slice of the domain the service is taking care of. I entirely agree. The framework jab, along with the gratuitous and entirely unrelated assertion regarding containers, just lower the expectation that the article has any point worth reading, specially considering that afterwards the author decided to include "having tests" as a characteristic of his concept.

linkdd 6y ago

The author seems to think that a microservice should have as few dependencies as possible. If your business logic is contained in another framework and your microservice just call a subset of those functions, is it really a microservice ?

100011_100001 6y ago

You'll be surprised. A group I work with opted for a microservices approach, a few years later they have 47 tightly coupled "microservices" that have to be deployed all together or they break.

ryanbrunner 6y ago
That's unrelated to the framework used to power those things though. You can have perfectly decoupled services running some bloated Java framework or using Go with minimal libraries or whatever. You might prefer one or the other, but it has little do with how much those services fit into the definition of 'microservices'.
scottious 6y ago
ah, the dreaded distributed monolith. I hope this is looked at as a terrible anti-pattern someday. "But we can deploy services independently" they say, "we can scale these services independently too!", "We can finally scale our development team!" Years later: no services are scaled independently. Deployments are a mess. Most deploys end up having to be lock-stop deploys. Issues are incredibly hard to track down because of complex network interactions. For some reason 7 of them are written in Rust and only 1 guy knows Rust. Stack traces become almost worthless. You find yourself having to piece together log files across tons of services to track down issues. You have hundreds of Jenkins jobs for deploying services.

sorokod 6y ago

For me framework here is a bunch of software that solves a problem that is othogonal to the business domain: logging, networking, Db access etc. An upstream service is not a framework in this context.

rualca 6y ago

> What on earth is a "large" framework? What does the size of a framework (by whatever metric) has to do with the "micro" which refers to a slice of the domain the service is taking care of. I entirely agree. The framework jab, along with the gratuitous and entirely unrelated assertion regarding containers, just lower the expectation that the article has any point worth reading, specially considering that afterwards the author decided to include "having tests" as a characteristic of his concept.