5 ms·

> 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?
      - JamesBarney 7y ago
        I've seen a couple of projects where the original team didn't think they needed transactions, or underestimated how much harder eventually consistent distributed systems are to reason about than an acid system.
    - Aeolun 7y ago
      It doesn’t matter if you have transactions or not. Just make sure you execute things in the right order! Same for referential integrity, if you just make sure nothing ever goes wrong, there’s no need for it! /s
  - cc81 7y ago
    I've been in discussions about internal applications with few hundreds users and very moderate amounts of data being shuffled and stored and some people, of various backgrounds, are just so convinced that we need to go all in on Kubernetes, Microservices, Istio etc. And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one or two raspberry pi, that is the amount of power you actually need here". Don't get me wrong I do think they absolutely have their place and in other parts of the company we have much larger software development projects and they are absolutely making great use of Microservice architectures and Kubernetes and is getting a lot out of it. But that is 100+ teams building a product portfolio together.
    - rumanator 7y ago
      > And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one or two raspberry pi, that is the amount of power you actually need here". If your product has a global audience who needs to CRUD stuff, caching and a single raspberry pi won't get you very far in the game. If it's just an intranet stuff with a few hundred users and your front-end isn't very chatty then you're right, you don't need much.
      - capableweb 7y ago
        If you don't pile abstractions on top of abstractions on top of kubernetes on top of docker, you'd be surprised how much you can do with a single small-sized instance.
        lima 7y ago
        k8s has no performance overhead and can be useful even for simple applications (like for reproducible dev environments and CI). Agreed, otherwise.
        capableweb 7y ago
        I'm not talking about performance overhead, I'm talking about architecture overhead. Kubernetes doesn't have any advantages over not using Kubernetes for simple applications. Reproducible dev environments and CI you can get easily without Kubernetes, without having to add complex solutions for logging, profiling and other introspection tools. One could argue that you need the reproducible dev environments and CI to be solved BEFORE even start using Kubernetes.
  - mads_ravn 7y ago
    This. At least that is what I often think, when I hear people describing micro-services. If there is no data sharing between computations, then the problem is embarrassingly parallel [1] and thus easy to scale. The problem is not the monolith, it is the data sharing, which micro-services only solve if each service owns it’s own data. To be fair people advocating micro-services also often argue that they should own their data, but in quite a few of the instances I’ve heard described, this is not the case. [1] https://en.m.wikipedia.org/wiki/Embarrassingly_parallel https://en.m.wikipedia.org/wiki/Embarrassingly_parallel

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?
    - JamesBarney 7y ago
      I've seen a couple of projects where the original team didn't think they needed transactions, or underestimated how much harder eventually consistent distributed systems are to reason about than an acid system.
  - Aeolun 7y ago
    It doesn’t matter if you have transactions or not. Just make sure you execute things in the right order! Same for referential integrity, if you just make sure nothing ever goes wrong, there’s no need for it! /s
- cc81 7y ago
  I've been in discussions about internal applications with few hundreds users and very moderate amounts of data being shuffled and stored and some people, of various backgrounds, are just so convinced that we need to go all in on Kubernetes, Microservices, Istio etc. And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one or two raspberry pi, that is the amount of power you actually need here". Don't get me wrong I do think they absolutely have their place and in other parts of the company we have much larger software development projects and they are absolutely making great use of Microservice architectures and Kubernetes and is getting a lot out of it. But that is 100+ teams building a product portfolio together.
  - rumanator 7y ago
    > And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one or two raspberry pi, that is the amount of power you actually need here". If your product has a global audience who needs to CRUD stuff, caching and a single raspberry pi won't get you very far in the game. If it's just an intranet stuff with a few hundred users and your front-end isn't very chatty then you're right, you don't need much.
    - capableweb 7y ago
      If you don't pile abstractions on top of abstractions on top of kubernetes on top of docker, you'd be surprised how much you can do with a single small-sized instance.
      - lima 7y ago
        k8s has no performance overhead and can be useful even for simple applications (like for reproducible dev environments and CI). Agreed, otherwise.
        capableweb 7y ago
        I'm not talking about performance overhead, I'm talking about architecture overhead. Kubernetes doesn't have any advantages over not using Kubernetes for simple applications. Reproducible dev environments and CI you can get easily without Kubernetes, without having to add complex solutions for logging, profiling and other introspection tools. One could argue that you need the reproducible dev environments and CI to be solved BEFORE even start using Kubernetes.
- mads_ravn 7y ago
  This. At least that is what I often think, when I hear people describing micro-services. If there is no data sharing between computations, then the problem is embarrassingly parallel [1] and thus easy to scale. The problem is not the monolith, it is the data sharing, which micro-services only solve if each service owns it’s own data. To be fair people advocating micro-services also often argue that they should own their data, but in quite a few of the instances I’ve heard described, this is not the case. [1] https://en.m.wikipedia.org/wiki/Embarrassingly_parallel https://en.m.wikipedia.org/wiki/Embarrassingly_parallel