Live data from Hacker News

The costs of microservices (2020)

robertovitillo.com

21–30 of 410 posts

Re: The costs of microservices (2020)

#21
post #15

Earlier quoted context omitted.

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

> Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint. ... followed by howls of anguish from the rest of the business when it turns out they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a l…

another reason why you provide data only over API - don't reach into my tables and lock me into an implementation.

Re: The costs of microservices (2020)

#22
post #9
post #3

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…

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…

> 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.

Re: The costs of microservices (2020)

#23
post #18
post #5

The article sees to take for granted that your development org is completely broken and out of control. They can't decide what to work on during sprints, they furtively introduce third party libraries and unknown languages, they silently ship incompatible changes to prod, etc. I guess microservices are easier if your developers aren't bozos.

Every developer is a bozo for their first few months in a new job, simply because it takes time to absorb all of the information needed to understand how the existing systems work.

Acculturating new developers is one of the main tasks of an organization. I don't think it's very difficult to communicate that some company uses language[s] X[, Y and Z] only.

Re: The costs of microservices (2020)

#24
post #9
post #3

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…

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…

[deleted]

Re: The costs of microservices (2020)

#25
post #9
post #3

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…

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…

_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.

Re: The costs of microservices (2020)

#26
post #3

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…

> 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.

Re: The costs of microservices (2020)

#27
Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it:

1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing

2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment that have different priorities/sensitive business hours time windows

3) system design decisions that cannot be abstracted away are at the mercy of some large clients of the company that are unable or unwilling to change their way of doing things - you can silo the pain.

And to be clear, it's not that these things are "cost free". It's just a cost that is worth paying to protect the simpler monolith from becoming crap encrusted, disrupted with risky deploys, or constrained by business partners with worse tech stacks.

Re: The costs of microservices (2020)

#30
post #9
post #3

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…

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…

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".

Post reply on HN