15 ms·

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going to go well_.

avelis 3y ago
Sounds like a SISP (solution in search of a problem). Or throwing a solution at a problem not understanding the root issue of it.
jeffbee 3y ago
I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example.
- pjc50 3y ago
  DNS resolution is genuninely reusable, though. Perhaps that's the test: is this something that could concievably be used by others, as a product in itself, or is it tied very heavily to the business and the rest of the "microservices"? Remember this is how AWS was born, as a set of "microservices" which could start being sold to external customers, like "storage".
  - jeffbee 3y ago
    What about a mailer that's divided into the SMTP server and the local delivery agent?
    - pjc50 3y ago
      qmail probably counts as "microservices" as well, yes. In that case, for security separation of authority in a multi-user environment. Nowadays we don't really do multi-user environments and separation would be by container.
- deleted 3y ago
  [deleted]
- Scarblac 3y ago
  _Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web server). _Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.
  - xnorswap 3y ago
    That may be true, but the article describes a services architecture and labels it microservices, indeed goes onto to say: > The term micro can be misleading, though - there doesn’t have to be anything micro about the services
    - Scarblac 3y ago
      Yes, but the "widespread meme" as I see it is about microservices, not services in general.
      - butlerm 3y ago
        The smaller the service, the more likely that the overhead of having a separate service exceeds the benefit of doing so. It isn't at all normal for a service to have its own database unless it provides a substantial piece of functionality, for example, and there are non-trivial costs to splitting databases unnecessarily. If you are not very careful, it is a good way to make certain things a dozen times slower and a dozen times more expensive to develop.
  - mjr00 3y ago
    It's funny because the term "microservices" picked up in popularity because previously, most "service-oriented architecture" (the old term) implementations in large companies had services that were worked on by dozens or hundreds of developers, at least in my experience. So going from that to services that were worked on by a single development team of ~10 people was indeed a "microservice" relatively speaking. Now, thanks to massive changes in how software is built (cloud, containers et al) it's a lot more standard for a normal "service" with no prefix to be built by a small team of developers, no micro- prefix needed.
- mjr00 3y ago
  > I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. There's a few things in play IMO. One is lack of definition -- what's a "microservice" anyhow? Netflix popularized the idea of microservices literally being a few hundred lines of code maintained by a single developer, and some people believe that's what a microservice is. Others are more lax and see microservices as being maintained by small (4-10 person) development teams. Another is that most people have not worked at a place where microservices were done well, because they were implemented by CTOs and "software architects" with no experience at companies with 10 developers. There are a lot of problems that come from doing microservices poorly, particularly around building distributed monoliths and operational overhead. It's definitely preferable to have a poorly-built monolith than poorly-built microservice architectures. I've been at 4 companies that did microservices (in my definition, which is essentially one service per dev team). Three were a great development experience and dev/deploy velocity was excellent. One was a total clusterfuck.
  - insanitybit 3y ago
    It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". > It's definitely preferable to have a poorly-built monolith than poorly-built microservice architectures. I don't know about "definitely" at all. Having worked with some horrible monoliths, I really don't think I agree. Microservices can be done poorly but at minimum there's a fundamental isolation of components. If you don't have any isolation of components it was never even close to microservices/SoA, at which point, is it really a fair criticism?
    - mjr00 3y ago
      > It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". How small is small? Even within this comment section there are people talking about a single developer being the sole maintainer of multiple microservices. I'm a strong advocate of (micro?)service architecture but I would never recommend doing the "all behavior is 100-line lambda functions" approach. A horrible monolith vs horrible microservices is subjective, of course, but IMO having everything self-contained to one repository, one collection of app servers, etc. at least gives you some hope of salvation, often by building new functionality in separate services, ironically. Horrible microservices that violate data boundaries, i.e. multiple services sharing a database which is a sadly common mistake, is a much harder problem to solve. (both are bad, of course!)
- nevinera 3y ago
  You're certainly misunderstanding me. Microservices are definitely justifiable in plenty of cases, and _services_ even more often. But they _need to be technically justified_ - that's the point I'm making. The majority of SOA adoption in small-to-medium tech companies is driven by the wrong type of pain, by technical leaders that can see that if they had their domains already split out into services, their problems would not exist, but don't understand that reaching that point involves _solving their problems first_.
  - foobiekr 3y ago
    Whenever someone on the projects, I’m attached to tries to create a new service, first I asked them what data it works with, and then I ask them what the alternative to making this a service would be. Usually, by the time we start answering the second question, they realize that, actually, adding the service is just more work. To me, what’s amazing is that in almost no organization is there a requirement to justify technically the addition of a new service, despite the cost and administrative and cognitive overhead of doing so.
- mdekkers 3y ago
  > I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. Many HN patrons are actually working where the rubber meets the road. DNS is a poor comparison. Pretty much everything, related to your application or not, needs DNS. On the other hand, the only thing WNGMAN[0]may or may not do, is help with finding the user’s DOB. https://m.youtube.com/watch?v=y8OnoxKotPQ https://m.youtube.com/watch?v=y8OnoxKotPQ
- rqtwteye 3y ago
  "I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified" I think the problem is the word "micro". At my company I see a lot of projects that are run by three devs that and have 13 microservices. They are easy to develop but the maintenance overhead is enormous. And they never get shared between projects so you have 5 services that do basically the same.
- manicennui 3y ago
  I rarely see anyone claiming that microservices are never justified. I think the general attitude toward them is due to the amount of Resume Driven Development that happens in the real world.
  - nevinera 3y ago
    Eh, I think a lot more of it is caused by optimism than RDD - people who haven't _tried to do it_ look at the mess they've got, and they can see that if it were divided into domain-based services it would be less of a mess. And the process seems almost straightforward until you _actually try to do it_, and find out that it's actually fractally difficult - by that point you've committed your organization and your reputation to the task, and "hey, that was a mistake, oops" _after_ you've sunk that kind of organizational resources into such a project is a kind of professional suicide.
- bcrosby95 3y ago
  Can you point to a comment on HN saying microservices are never justified?
arzke 3y ago
"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it." Quoted from: https://www.oreilly.com/library/view/software-architects-handbook/9781788624060/a844b94f-be9e-456d-8ef0-cd9b46b41c33.xhtml https://www.oreilly.com/library/view/software-architects-han...
- deleted 3y ago
  [deleted]
- TeMPOraL 3y ago
  Still trying to unlearn that one. Turns out, most decisions are cheap to revert or backtrack on, while delaying them until Last Responsible Moment often ends in shooting past that moment.
  - jlundberg 3y ago
    Interesting term and I am curious to learn a few examples on overshooting here! My experience is that the new data available when postponing decisions can be very very valuable.
    - TeMPOraL 3y ago
      We're moving out of business context and to more general one, as I have more experience there - I learned the idea of postponing decisions from software design, and mistakenly started to apply it to my life in general :). It's absolutely true that postponing a decision lets you take advantage of more data and experience. But making a decision now also generates new data - and often does it better and faster: you're directly observing how your choice plays out in the real world. For cheaply reversible decisions it means that, when things go bad, you can go back and make a new decision, this time informed by knowledge of what went wrong with your previous choice. If you squint, it almost looks like time travel :). Not every decision is going to be like that, but e.g. in software design, I would often delay deciding between several possible approaches to seek out more information (and/or wait for it to come from customer side), only to later realize that in that time, I could've prototyped most or all of the options, or I could've picked one and made progress and undo it fast when more information came - and that either of those two approaches would've let me to gain the missing data faster, while also keeping forward momentum. There's a reason many programmers (myself included) need to repeatedly hear the mantra that goes: "make it work, then make it right, then make it fast". In my case, postponing decisions is often a kind of analysis paralysis, and I'm slowly learning that in many cases, it's better to just pick any option, "make it work" in the dumbest, most straightforward way possible, and then reevaluate. But as I said, I am learning this slowly. My mind knows better, but my heart still wants to delay by default :).
insanitybit 3y ago
> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.
- vrosas 3y ago
  The other problem is that these self-imposed roadblocks are so engrained in the modern SDLC that developers literally cannot imagine a world where they do not exist. I got _reamed_ by some "senior" engineers for merging a small PR without an approval recently. And we're not some megacorp, we're a 12 person engineering startup! We can make our own rules! We don't even have any customers...
  - insanitybit 3y ago
    Indeed, dogmatic adherence to arbitrary patterns is a huge problem in our field. People have strong beliefs, "X good" or "X bad", with almost no idea of what X even is, what the alternatives are, why X was something people did or did not like, etc.
    - jacquesm 3y ago
      Another problem is people making decisions with potentially far reaching consequences well above their paygrade without authorization.
      - insanitybit 3y ago
        I don't think that problem is nearly as significant.
        jacquesm 3y ago
        What you think is usually the limit of your experience, which effectively makes it anecdata. I've looked at enough companies and dealt with the aftermath of enough such instances that I beg to differ. It's possible that due to the nature of my business my experience is skewed in the other direction which makes that anecdata as well. But it is probably more important than you think (and less important than I think).
mike_ivanov 3y ago
I want this printed and neatly framed. Where to order?
smrtinsert 3y ago
I've always thought of this as the best example of deferred execution. It's surprising how often businesses get it wrong. I think the problem is most "good" workers are over eager to demonstrate value. They do that by over engineering and that leads to hell etc...

avelis 3y ago

Sounds like a SISP (solution in search of a problem). Or throwing a solution at a problem not understanding the root issue of it.

jeffbee 3y ago

I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example.

pjc50 3y ago
DNS resolution is genuninely reusable, though. Perhaps that's the test: is this something that could concievably be used by others, as a product in itself, or is it tied very heavily to the business and the rest of the "microservices"? Remember this is how AWS was born, as a set of "microservices" which could start being sold to external customers, like "storage".
- jeffbee 3y ago
  What about a mailer that's divided into the SMTP server and the local delivery agent?
  - pjc50 3y ago
    qmail probably counts as "microservices" as well, yes. In that case, for security separation of authority in a multi-user environment. Nowadays we don't really do multi-user environments and separation would be by container.
deleted 3y ago
[deleted]
Scarblac 3y ago
_Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web server). _Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.
- xnorswap 3y ago
  That may be true, but the article describes a services architecture and labels it microservices, indeed goes onto to say: > The term micro can be misleading, though - there doesn’t have to be anything micro about the services
  - Scarblac 3y ago
    Yes, but the "widespread meme" as I see it is about microservices, not services in general.
    - butlerm 3y ago
      The smaller the service, the more likely that the overhead of having a separate service exceeds the benefit of doing so. It isn't at all normal for a service to have its own database unless it provides a substantial piece of functionality, for example, and there are non-trivial costs to splitting databases unnecessarily. If you are not very careful, it is a good way to make certain things a dozen times slower and a dozen times more expensive to develop.
- mjr00 3y ago
  It's funny because the term "microservices" picked up in popularity because previously, most "service-oriented architecture" (the old term) implementations in large companies had services that were worked on by dozens or hundreds of developers, at least in my experience. So going from that to services that were worked on by a single development team of ~10 people was indeed a "microservice" relatively speaking. Now, thanks to massive changes in how software is built (cloud, containers et al) it's a lot more standard for a normal "service" with no prefix to be built by a small team of developers, no micro- prefix needed.
mjr00 3y ago
> I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. There's a few things in play IMO. One is lack of definition -- what's a "microservice" anyhow? Netflix popularized the idea of microservices literally being a few hundred lines of code maintained by a single developer, and some people believe that's what a microservice is. Others are more lax and see microservices as being maintained by small (4-10 person) development teams. Another is that most people have not worked at a place where microservices were done well, because they were implemented by CTOs and "software architects" with no experience at companies with 10 developers. There are a lot of problems that come from doing microservices poorly, particularly around building distributed monoliths and operational overhead. It's definitely preferable to have a poorly-built monolith than poorly-built microservice architectures. I've been at 4 companies that did microservices (in my definition, which is essentially one service per dev team). Three were a great development experience and dev/deploy velocity was excellent. One was a total clusterfuck.
- insanitybit 3y ago
  It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". > It's definitely preferable to have a poorly-built monolith than poorly-built microservice architectures. I don't know about "definitely" at all. Having worked with some horrible monoliths, I really don't think I agree. Microservices can be done poorly but at minimum there's a fundamental isolation of components. If you don't have any isolation of components it was never even close to microservices/SoA, at which point, is it really a fair criticism?
  - mjr00 3y ago
    > It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". How small is small? Even within this comment section there are people talking about a single developer being the sole maintainer of multiple microservices. I'm a strong advocate of (micro?)service architecture but I would never recommend doing the "all behavior is 100-line lambda functions" approach. A horrible monolith vs horrible microservices is subjective, of course, but IMO having everything self-contained to one repository, one collection of app servers, etc. at least gives you some hope of salvation, often by building new functionality in separate services, ironically. Horrible microservices that violate data boundaries, i.e. multiple services sharing a database which is a sadly common mistake, is a much harder problem to solve. (both are bad, of course!)
nevinera 3y ago
You're certainly misunderstanding me. Microservices are definitely justifiable in plenty of cases, and _services_ even more often. But they _need to be technically justified_ - that's the point I'm making. The majority of SOA adoption in small-to-medium tech companies is driven by the wrong type of pain, by technical leaders that can see that if they had their domains already split out into services, their problems would not exist, but don't understand that reaching that point involves _solving their problems first_.
- foobiekr 3y ago
  Whenever someone on the projects, I’m attached to tries to create a new service, first I asked them what data it works with, and then I ask them what the alternative to making this a service would be. Usually, by the time we start answering the second question, they realize that, actually, adding the service is just more work. To me, what’s amazing is that in almost no organization is there a requirement to justify technically the addition of a new service, despite the cost and administrative and cognitive overhead of doing so.
mdekkers 3y ago
> I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. Many HN patrons are actually working where the rubber meets the road. DNS is a poor comparison. Pretty much everything, related to your application or not, needs DNS. On the other hand, the only thing WNGMAN[0]may or may not do, is help with finding the user’s DOB. https://m.youtube.com/watch?v=y8OnoxKotPQ https://m.youtube.com/watch?v=y8OnoxKotPQ
rqtwteye 3y ago
"I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified" I think the problem is the word "micro". At my company I see a lot of projects that are run by three devs that and have 13 microservices. They are easy to develop but the maintenance overhead is enormous. And they never get shared between projects so you have 5 services that do basically the same.
manicennui 3y ago
I rarely see anyone claiming that microservices are never justified. I think the general attitude toward them is due to the amount of Resume Driven Development that happens in the real world.
- nevinera 3y ago
  Eh, I think a lot more of it is caused by optimism than RDD - people who haven't _tried to do it_ look at the mess they've got, and they can see that if it were divided into domain-based services it would be less of a mess. And the process seems almost straightforward until you _actually try to do it_, and find out that it's actually fractally difficult - by that point you've committed your organization and your reputation to the task, and "hey, that was a mistake, oops" _after_ you've sunk that kind of organizational resources into such a project is a kind of professional suicide.
bcrosby95 3y ago
Can you point to a comment on HN saying microservices are never justified?

arzke 3y ago

"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it." Quoted from: https://www.oreilly.com/library/view/software-architects-handbook/9781788624060/a844b94f-be9e-456d-8ef0-cd9b46b41c33.xhtml https://www.oreilly.com/library/view/software-architects-han...

deleted 3y ago
[deleted]
TeMPOraL 3y ago
Still trying to unlearn that one. Turns out, most decisions are cheap to revert or backtrack on, while delaying them until Last Responsible Moment often ends in shooting past that moment.
- jlundberg 3y ago
  Interesting term and I am curious to learn a few examples on overshooting here! My experience is that the new data available when postponing decisions can be very very valuable.
  - TeMPOraL 3y ago
    We're moving out of business context and to more general one, as I have more experience there - I learned the idea of postponing decisions from software design, and mistakenly started to apply it to my life in general :). It's absolutely true that postponing a decision lets you take advantage of more data and experience. But making a decision now also generates new data - and often does it better and faster: you're directly observing how your choice plays out in the real world. For cheaply reversible decisions it means that, when things go bad, you can go back and make a new decision, this time informed by knowledge of what went wrong with your previous choice. If you squint, it almost looks like time travel :). Not every decision is going to be like that, but e.g. in software design, I would often delay deciding between several possible approaches to seek out more information (and/or wait for it to come from customer side), only to later realize that in that time, I could've prototyped most or all of the options, or I could've picked one and made progress and undo it fast when more information came - and that either of those two approaches would've let me to gain the missing data faster, while also keeping forward momentum. There's a reason many programmers (myself included) need to repeatedly hear the mantra that goes: "make it work, then make it right, then make it fast". In my case, postponing decisions is often a kind of analysis paralysis, and I'm slowly learning that in many cases, it's better to just pick any option, "make it work" in the dumbest, most straightforward way possible, and then reevaluate. But as I said, I am learning this slowly. My mind knows better, but my heart still wants to delay by default :).

insanitybit 3y ago

> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.

vrosas 3y ago
The other problem is that these self-imposed roadblocks are so engrained in the modern SDLC that developers literally cannot imagine a world where they do not exist. I got _reamed_ by some "senior" engineers for merging a small PR without an approval recently. And we're not some megacorp, we're a 12 person engineering startup! We can make our own rules! We don't even have any customers...
- insanitybit 3y ago
  Indeed, dogmatic adherence to arbitrary patterns is a huge problem in our field. People have strong beliefs, "X good" or "X bad", with almost no idea of what X even is, what the alternatives are, why X was something people did or did not like, etc.
  - jacquesm 3y ago
    Another problem is people making decisions with potentially far reaching consequences well above their paygrade without authorization.
    - insanitybit 3y ago
      I don't think that problem is nearly as significant.
      - jacquesm 3y ago
        What you think is usually the limit of your experience, which effectively makes it anecdata. I've looked at enough companies and dealt with the aftermath of enough such instances that I beg to differ. It's possible that due to the nature of my business my experience is skewed in the other direction which makes that anecdata as well. But it is probably more important than you think (and less important than I think).

mike_ivanov 3y ago

I want this printed and neatly framed. Where to order?

smrtinsert 3y ago

I've always thought of this as the best example of deferred execution. It's surprising how often businesses get it wrong. I think the problem is most "good" workers are over eager to demonstrate value. They do that by over engineering and that leads to hell etc...