5 ms·

I agree, my intuition would put it to 1% vs. 99% (difficult to quantify of course). I haven't yet seen a project/product which would need microservice architec

I agree, my intuition would put it to 1% vs. 99% (difficult to quantify of course). I haven't yet seen a project/product which would need microservice architecture for technical reasons. If you need to scale, you can just scale monoliths (perhaps serving in different roles). The use case for microservice architecture is IMHO an organizational / high level architecture driven. I've worked in a big company (20K employees) which was completely redesigning its back-office IT solution which ended up as a mesh of various microservices serving various needs (typically consumed by purpose built frontends), worked on by different teams. There monolith didn't make sense, because there was no single purpose, no single product. But if I'm building a product, I will choose monolith every time. Maaaaybe in some very special cases, I will build some auxiliary services serving the monolith, but there needs to be a very good reason to do so.

suction 4y ago
[dead]
rostos 4y ago
That organizational/architecture benefit is strong though.
- citrin_ru 4y ago
  It’s depends on how you slice services. For one micro-service per a team I see benefits. On another end of the spectrum a single team managing 10-20 micro-services with more than one service per developer. IMHO it creates more problems than solves. Also it is usually a waste of HW resources because a library call it is cheaper then a network request.
  - whstl 4y ago
    I think it depends on more than that. A single team managing 10 microservices that actually make sense to be microservices (like the PDF renderer example above [1]) is kinda good and perfectly manageable. A team with one single microservice that would actually work better if it was part of a monolith is already in the "creates more problems than it solves" territory. [1] https://news.ycombinator.com/item?id=35812294 https://news.ycombinator.com/item?id=35812294
- The_Colonel 4y ago
  I would frame it as a necessity rather than a benefit. Having siloed teams (services) is usually a problem which is better to avoid as much as you can.
  - dtech 4y ago
    Having autonomous teams is great for scaling and allowing everyone to go fast, without teams constantly blocking each other. Having hundreds of engineers work in a single monolith in a single repo without any kind of (enforced) boundaries is a one way ticket to a big ball of mud. You need to invest heavily in tooling to make it work, and e.g. Google does so. Having a network in between teams is a relatively easy way to enforce boundaries.
    - The_Colonel 4y ago
      It allows everyone to go fast as long as the work is constrained within one service. It goes very slow once service / team coordination needs to happen and one team alone is not able to deliver the feature. This then often leads to services duplicating logic, amassing responsibilities in order to do as much as possible within "my" service to avoid this coordination bottleneck.
      - dtech 4y ago
        Then you're either not setting up your team responsibilities right, or you're not allowing cross-team contribution, both are fixable mistakes.
henry_bone 4y ago
Seems like Conway's law applies:- "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." -- Melvin E. Conway https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- pjc50 4y ago
  Came here to say this - and it applies in the other direction. Microservices allow you to split work between teams without having to coordinate deployment and iteration cadence quite so tightly. If you have a single team, you shouldn't be doing microservices.
  - baobabKoodaa 4y ago
    I mostly see organizations with multiple internal dev teams who all have shared responsibility over all of the microservices (e.g. no-one is responsible for any service). The worst of both worlds: all of the complexity of microservices architecture, without the benefit of specialization and splitting work between teams.
- mwcampbell 4y ago
  The organizational structure doesn't have to be reflected in the built artifact(s), though. Just look at Chrome. It has who knows how many teams working on it, but gets built into a single giant DLL (or executable, depending on your platform). And newer languages like Go and Rust make it easier to link everything into one big artifact like this.
boxed 4y ago
I built a little microservice on the side of my monolith for PDF creation. It used headless chrome and ghostscript to render html to a nice PDF. The problem I had with having that code inside the monolith was that it increased my docker image creation for deploys by a lot. And that code pretty much never changed anyway. I did feel a bit embarrassed having to make a microservice after having argued against them so much over the years. Hopefully I can stop producing PDFs soon so I can delete the entire thing :P
- The_Colonel 4y ago
  That honestly seems like a reasonable use case for (what I call) auxiliary services serving the monolith. As I imagine, there's no real business logic, no data storage / transactions, no authentication/authorization (besides the service being hidden in the private network probably).
- foepys 4y ago
  That's exactly what my team did at a former company. We generated reports through a legacy document engine because some customers cannot switch/update their report templates and so we moved the logic out of the monolith into a service to get rid of a large portion of our dependencies. Moved the monolith to .NET Core, kept the report service on .NET Framework. A win for everybody.
- jon-wood 4y ago
  This is absolutely the way to go in my experience. Keep related functionality together, that'll probably result in a big monolith, with maybe a few smaller services orbiting it with very specific roles, or dramatically different traffic patterns. One project I worked on consisted of two monoliths, because we were at the intersection of two business domains, and it didn't make sense to attempt to slap those radically different concepts into one model.
- mike_hearn 4y ago
  Doesn't Docker use cached image layers to solve that? Your PDF rendering could be in one layer that never changes, and the rest goes on top.
12907835202 4y ago
Depends if you're counting all the WordPress level projects. Then it'd be 0.01% Vs 99.99% I'd imagine. But that just puts into perspective how silly this argument is because I have no idea what a project means to other people.
golergka 4y ago
I'm developing an ML based sideproject. All the modern ML tools are written in python, which is a reality good language for it. However, it is an abysmal project for writing business logic and third party integrations, and if I have some free time I will split the whole thing into one Python and one Typescript service.
Cthulhu_ 4y ago
There's also developer push from two sides; developers want to do microservices because it gives them gratification (new problems to solve! new architectures! Rewrite!), and employers want to attract developers (we do microservices! Blockchain! IoT!). So much in software development these days is hype and self-gratification.
pjmlp 4y ago
The problem is that we are now in the golden age of Web services, where everything is headless and controlled via API, so the business logic plugging all those APIs need to live somewhere. Naturally it could be a single container taking care of all those integrations.

suction 4y ago

[dead]

rostos 4y ago

That organizational/architecture benefit is strong though.

citrin_ru 4y ago
It’s depends on how you slice services. For one micro-service per a team I see benefits. On another end of the spectrum a single team managing 10-20 micro-services with more than one service per developer. IMHO it creates more problems than solves. Also it is usually a waste of HW resources because a library call it is cheaper then a network request.
- whstl 4y ago
  I think it depends on more than that. A single team managing 10 microservices that actually make sense to be microservices (like the PDF renderer example above [1]) is kinda good and perfectly manageable. A team with one single microservice that would actually work better if it was part of a monolith is already in the "creates more problems than it solves" territory. [1] https://news.ycombinator.com/item?id=35812294 https://news.ycombinator.com/item?id=35812294
The_Colonel 4y ago
I would frame it as a necessity rather than a benefit. Having siloed teams (services) is usually a problem which is better to avoid as much as you can.
- dtech 4y ago
  Having autonomous teams is great for scaling and allowing everyone to go fast, without teams constantly blocking each other. Having hundreds of engineers work in a single monolith in a single repo without any kind of (enforced) boundaries is a one way ticket to a big ball of mud. You need to invest heavily in tooling to make it work, and e.g. Google does so. Having a network in between teams is a relatively easy way to enforce boundaries.
  - The_Colonel 4y ago
    It allows everyone to go fast as long as the work is constrained within one service. It goes very slow once service / team coordination needs to happen and one team alone is not able to deliver the feature. This then often leads to services duplicating logic, amassing responsibilities in order to do as much as possible within "my" service to avoid this coordination bottleneck.
    - dtech 4y ago
      Then you're either not setting up your team responsibilities right, or you're not allowing cross-team contribution, both are fixable mistakes.

henry_bone 4y ago

Seems like Conway's law applies:- "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." -- Melvin E. Conway https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

pjc50 4y ago
Came here to say this - and it applies in the other direction. Microservices allow you to split work between teams without having to coordinate deployment and iteration cadence quite so tightly. If you have a single team, you shouldn't be doing microservices.
- baobabKoodaa 4y ago
  I mostly see organizations with multiple internal dev teams who all have shared responsibility over all of the microservices (e.g. no-one is responsible for any service). The worst of both worlds: all of the complexity of microservices architecture, without the benefit of specialization and splitting work between teams.
mwcampbell 4y ago
The organizational structure doesn't have to be reflected in the built artifact(s), though. Just look at Chrome. It has who knows how many teams working on it, but gets built into a single giant DLL (or executable, depending on your platform). And newer languages like Go and Rust make it easier to link everything into one big artifact like this.

boxed 4y ago

I built a little microservice on the side of my monolith for PDF creation. It used headless chrome and ghostscript to render html to a nice PDF. The problem I had with having that code inside the monolith was that it increased my docker image creation for deploys by a lot. And that code pretty much never changed anyway. I did feel a bit embarrassed having to make a microservice after having argued against them so much over the years. Hopefully I can stop producing PDFs soon so I can delete the entire thing :P

The_Colonel 4y ago
That honestly seems like a reasonable use case for (what I call) auxiliary services serving the monolith. As I imagine, there's no real business logic, no data storage / transactions, no authentication/authorization (besides the service being hidden in the private network probably).
foepys 4y ago
That's exactly what my team did at a former company. We generated reports through a legacy document engine because some customers cannot switch/update their report templates and so we moved the logic out of the monolith into a service to get rid of a large portion of our dependencies. Moved the monolith to .NET Core, kept the report service on .NET Framework. A win for everybody.
jon-wood 4y ago
This is absolutely the way to go in my experience. Keep related functionality together, that'll probably result in a big monolith, with maybe a few smaller services orbiting it with very specific roles, or dramatically different traffic patterns. One project I worked on consisted of two monoliths, because we were at the intersection of two business domains, and it didn't make sense to attempt to slap those radically different concepts into one model.
mike_hearn 4y ago
Doesn't Docker use cached image layers to solve that? Your PDF rendering could be in one layer that never changes, and the rest goes on top.

12907835202 4y ago

Depends if you're counting all the WordPress level projects. Then it'd be 0.01% Vs 99.99% I'd imagine. But that just puts into perspective how silly this argument is because I have no idea what a project means to other people.

golergka 4y ago

I'm developing an ML based sideproject. All the modern ML tools are written in python, which is a reality good language for it. However, it is an abysmal project for writing business logic and third party integrations, and if I have some free time I will split the whole thing into one Python and one Typescript service.

Cthulhu_ 4y ago

There's also developer push from two sides; developers want to do microservices because it gives them gratification (new problems to solve! new architectures! Rewrite!), and employers want to attract developers (we do microservices! Blockchain! IoT!). So much in software development these days is hype and self-gratification.

pjmlp 4y ago

The problem is that we are now in the golden age of Web services, where everything is headless and controlled via API, so the business logic plugging all those APIs need to live somewhere. Naturally it could be a single container taking care of all those integrations.