4 ms·

> 19 microservices ... with a dev team of ... 3 perms and 2 contractors. I thought the main benefit of a microservice architecture is to break up an applicatio

by smadge 8y ago

> 19 microservices ... with a dev team of ... 3 perms and 2 contractors. I thought the main benefit of a microservice architecture is to break up an application into smaller services that are about the size that a small development team can build and maintain on their own. I'm not experienced in this area, but more than one microservice per developer seems like a major "architecture smell."

_pmf_ 8y ago
> I'm not experienced in this area, but more than one microservice per developer seems like a major "architecture smell." It's not a smell; it's a hot, steaming turd.
zimpenfish 8y ago
> more than one microservice per developer seems like a major "architecture smell." Yeah, it's normally that you need N developers per microservice (I've seen N=5 recommended, for example.)
- corpMaverick 8y ago
  The prefix micro in Microservice is very misleading. It is a microservice in the context of a >1,000KLOC monolith. I do like N=5 guideline as a way to make you think twice before making too many little services.
repolfx 8y ago
That's not the main benefit. The reason Google et al split services up into independent servers is for physical reasons. They have large datasets that don't fit on a single machine, so they have to shard the servers that handle it, and they have want to maximise their use of memory and CPU, so running unrelated tasks on the cores is a bad idea - at which point why link in the code? Before you know it you've got "microservices" except they aren't micro, they're machine sized. Somehow this got mangled into "microservices are good because they help teams work together" which isn't what it's about at all. At least at Google the smallest hello world server was something like 50mb when I worked there, just because of the huge dependency graph. It was common for servers to pull in hundreds of modules maintained by nearly as many different teams, all in a single binary. Each server was essentially a "monolith" except for the stuff that had to run in separate backends because of resource constraints.

by smadge 8y ago

_pmf_ 8y ago

> I'm not experienced in this area, but more than one microservice per developer seems like a major "architecture smell." It's not a smell; it's a hot, steaming turd.

zimpenfish 8y ago

> more than one microservice per developer seems like a major "architecture smell." Yeah, it's normally that you need N developers per microservice (I've seen N=5 recommended, for example.)

corpMaverick 8y ago
The prefix micro in Microservice is very misleading. It is a microservice in the context of a >1,000KLOC monolith. I do like N=5 guideline as a way to make you think twice before making too many little services.

repolfx 8y ago

That's not the main benefit. The reason Google et al split services up into independent servers is for physical reasons. They have large datasets that don't fit on a single machine, so they have to shard the servers that handle it, and they have want to maximise their use of memory and CPU, so running unrelated tasks on the cores is a bad idea - at which point why link in the code? Before you know it you've got "microservices" except they aren't micro, they're machine sized. Somehow this got mangled into "microservices are good because they help teams work together" which isn't what it's about at all. At least at Google the smallest hello world server was something like 50mb when I worked there, just because of the huge dependency graph. It was common for servers to pull in hundreds of modules maintained by nearly as many different teams, all in a single binary. Each server was essentially a "monolith" except for the stuff that had to run in separate backends because of resource constraints.