6 ms·

I don't understand the hate for microservices on hn. I have found microservices are a great way to extend monoliths developed with legacy frameworks. There are

I don't understand the hate for microservices on hn. I have found microservices are a great way to extend monoliths developed with legacy frameworks. There are so many pros with the cons easily avoidable with the right tooling / processes.

JamesBarney 7y ago
Basically it comes down to Distributed logging:hard Distributed debugging: hard Distributed versioning: hard Distributed transactions: very hard And on 95% of projects these problems aren't worth solving for the benefits of microservices.
- bogdanu 7y ago
  > And on 95% of projects these problems aren't worth solving for the benefits of microservices. And especially with a team of 4 or 5 developers.
  - deleted 7y ago
    [deleted]
  - capableweb 7y ago
    I just started working on a new project about half a year ago, completely greenfield. The backend developer (there is only one...) jumped into microservices directly, deploying on AWS Fargate, trying to split out as many things into containers as possible, because that's the "proper" way of doing it. We still have few users as the project is new, but hey, at least we could scale to 100000s users in a few minutes, instead of having easier logging, debugging and versioning A lot of stuff in software engineering is just driven by what's popular, not what's needed.
    - bcrosby95 7y ago
      A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.
      - redis_mlc 7y ago
        With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless to see their expressions when senior mgmt. and business owners finally find out.
        gullyfur 7y ago
        Could you elaborate what you mean by transactions?
        AlexCoventry 7y ago
        Sequences of interactions with the DB which are either atomically committed to on success of the sequence, or rolled back on failure, so that the DB is in the same state it had before the interactions began.
        elbear 7y ago
        Can you explain why you lose that ability? It's not obvious to me.
        NateEag 7y ago
        One of the fundamental laws of microservices is that each service is responsible for storing its own state. Nothing else is allowed access to its backing store. Given that, once you have more than one service in your architecture, you cannot coordinate transactions across the distinct storage mechanisms - they are distinct databases and are therefore subject to the CAP theorem and other complexities of distributed computing. Of course, nothing's stopping you from putting all your features into one service to avoid this thorny problem. It's a wise approach for most of us. When you do that you have a monolithic architecture, not a microservice one.
        rumanator 7y ago
        > With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. I don't follow your reasoning. I mean, the ACID vs BASE problem you described is extensively covered in pretty much any microservices 101 course or even MOOC, along other basic microservices tradeoffs such as the distributed tax and ways to mitigate or eliminate these issues like going with bounded contexts. Why do you believe this is a mystery that no one is aware of?
- dnautics 7y ago
  You can have a monolith and still suffer form these problems and need these technologies, as soon as you introduce a load balancer.
  - erpellan 7y ago
    If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.
    - rumanator 7y ago
      If your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern. https://microservices.io/patterns/data/shared-database.html https://microservices.io/patterns/data/shared-database.html
      - JamesBarney 7y ago
        Martin Fowler lists the benefits of microservices as Strong module boundaries Independent deployment Technology diversity And with a single database you severely limit the benefits from strong module boundaries and independent deployments. Suddenly you have to synchronize deployments, and anyone can pull or change any data in the database which now must be enforced with discipline which gets you into the same boat as a monolith.
        bogdanu 7y ago
        > which gets you into the same boat as a monolith Only worse because you don't have tools (IDEs, linters, etc) telling you what parts of the code have to be changed.
      - erpellan 7y ago
        Yes, and what does that buy you? Instead of a single deployable unit that owns the database, there are many deployable units, none of which can own the database. That doesn't seem like an improvement.
- darkteflon 7y ago
  Why is distributed logging hard? Genuinely curious.
  - sokoloff 7y ago
    It’s not the log writing that’s hard; it’s the log insight extraction that is. When you compare poring over logs from multiple invocations, even with request identifiers, the tooling is worse than tooling to look over stack traces/core dumps. A calls B, C, and D. B puts an item on a queue that eventually causes a call to C. Both B and C call D. Which D call is slow/erroring? Is it the AD, the ABD, the ABqCD, or the ACD call?
- maliker 7y ago
  Our initial prototype was a cluster-based approach, and once we had a better estimate of user growth and resources we moved to a monolith for all the reasons you cite.
philwelch 7y ago
HN can be a very contrarian community when it comes to popular trends or common practices in the tech industry.
- wolco 7y ago
  It's just mindless copying. Just because x worked for someone here in this specific situation doesn't mean we should throw out everything else.
  - rumanator 7y ago
    No, contrarian is a good description of the problem. We see a lot of posters complaining loudly about problems they never had or tools they never used. Some appear to simply enjoy arguing for the sake of it.

JamesBarney 7y ago

Basically it comes down to Distributed logging:hard Distributed debugging: hard Distributed versioning: hard Distributed transactions: very hard And on 95% of projects these problems aren't worth solving for the benefits of microservices.

bogdanu 7y ago
> And on 95% of projects these problems aren't worth solving for the benefits of microservices. And especially with a team of 4 or 5 developers.
- deleted 7y ago
  [deleted]
- capableweb 7y ago
  I just started working on a new project about half a year ago, completely greenfield. The backend developer (there is only one...) jumped into microservices directly, deploying on AWS Fargate, trying to split out as many things into containers as possible, because that's the "proper" way of doing it. We still have few users as the project is new, but hey, at least we could scale to 100000s users in a few minutes, instead of having easier logging, debugging and versioning A lot of stuff in software engineering is just driven by what's popular, not what's needed.
  - bcrosby95 7y ago
    A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.
    - redis_mlc 7y ago
      With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless to see their expressions when senior mgmt. and business owners finally find out.
      - gullyfur 7y ago
        Could you elaborate what you mean by transactions?
        AlexCoventry 7y ago
        Sequences of interactions with the DB which are either atomically committed to on success of the sequence, or rolled back on failure, so that the DB is in the same state it had before the interactions began.
      - elbear 7y ago
        Can you explain why you lose that ability? It's not obvious to me.
        NateEag 7y ago
        One of the fundamental laws of microservices is that each service is responsible for storing its own state. Nothing else is allowed access to its backing store. Given that, once you have more than one service in your architecture, you cannot coordinate transactions across the distinct storage mechanisms - they are distinct databases and are therefore subject to the CAP theorem and other complexities of distributed computing. Of course, nothing's stopping you from putting all your features into one service to avoid this thorny problem. It's a wise approach for most of us. When you do that you have a monolithic architecture, not a microservice one.
      - rumanator 7y ago
        > With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. I don't follow your reasoning. I mean, the ACID vs BASE problem you described is extensively covered in pretty much any microservices 101 course or even MOOC, along other basic microservices tradeoffs such as the distributed tax and ways to mitigate or eliminate these issues like going with bounded contexts. Why do you believe this is a mystery that no one is aware of?
dnautics 7y ago
You can have a monolith and still suffer form these problems and need these technologies, as soon as you introduce a load balancer.
- erpellan 7y ago
  If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.
  - rumanator 7y ago
    If your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern. https://microservices.io/patterns/data/shared-database.html https://microservices.io/patterns/data/shared-database.html
    - JamesBarney 7y ago
      Martin Fowler lists the benefits of microservices as Strong module boundaries Independent deployment Technology diversity And with a single database you severely limit the benefits from strong module boundaries and independent deployments. Suddenly you have to synchronize deployments, and anyone can pull or change any data in the database which now must be enforced with discipline which gets you into the same boat as a monolith.
      - bogdanu 7y ago
        > which gets you into the same boat as a monolith Only worse because you don't have tools (IDEs, linters, etc) telling you what parts of the code have to be changed.
    - erpellan 7y ago
      Yes, and what does that buy you? Instead of a single deployable unit that owns the database, there are many deployable units, none of which can own the database. That doesn't seem like an improvement.
darkteflon 7y ago
Why is distributed logging hard? Genuinely curious.
- sokoloff 7y ago
  It’s not the log writing that’s hard; it’s the log insight extraction that is. When you compare poring over logs from multiple invocations, even with request identifiers, the tooling is worse than tooling to look over stack traces/core dumps. A calls B, C, and D. B puts an item on a queue that eventually causes a call to C. Both B and C call D. Which D call is slow/erroring? Is it the AD, the ABD, the ABqCD, or the ACD call?
maliker 7y ago
Our initial prototype was a cluster-based approach, and once we had a better estimate of user growth and resources we moved to a monolith for all the reasons you cite.

philwelch 7y ago

HN can be a very contrarian community when it comes to popular trends or common practices in the tech industry.

wolco 7y ago
It's just mindless copying. Just because x worked for someone here in this specific situation doesn't mean we should throw out everything else.
- rumanator 7y ago
  No, contrarian is a good description of the problem. We see a lot of posters complaining loudly about problems they never had or tools they never used. Some appear to simply enjoy arguing for the sake of it.