5 ms·

14 million doing not so complex things is an easy achievement. When you get into a lot of microservices providing tons of features your teams will balloon.

Scarblac 3y ago
That's why it's important to keep the number of devs low, it makes it less likely that one starts talking about microservices.
- pestaa 3y ago
  It's more important to keep the number of features low. Good devs talk about aligning the architecture to requirements, and that sometimes includes microservices.
  - Sparkyte 3y ago
    This is true. I completely agree with the minimized scope. However a dev needs to be careful to not let their service just sit unmaintained. New teams will always need engineers to maintain and improve.
- Sparkyte 3y ago
  You talk as if monolithic apps are vastly superior. To be forward it depends entirely on the purpose and life of the application. It is about whatever shoe fits the design.
  - Aeolun 3y ago
    Sure. It’s just that 99% of applications work fine (or better) as a monolithic design.
    - Sparkyte 3y ago
      Depends on the purpose of the application though. Monolithic is a good architecture when you have a few purposeful features and functions. But when your design relies on many services to provide a wide variety of features you need to break out this design to allow teams to operate independently. Mini monoliths are more popular today than traditional monoliths of the old.
      - qaq 3y ago
        You can split things up you don't have to though. Teams operating independently is fairly orthogonal to this.
        Sparkyte 3y ago
        Yeah no I get you. You just want a monolith to be purposeful when you design one. Not multi-purposeful. This is also at the limitation of a programming language. I am kind of kubernetes guy, but I am dying because it relies heavily on a virtualize network distributed. It would drastically increase the performance if kubernetes clusters were built like monoliths and each kubernetes node handled traffic independently. So of like keeping it all in the same rack. Only leaving the rack if needed. But I keep seeing bad technology decisions repeated over and over. I stopped pushing because some person with a bigger title would say this is good design. Big kubernetes clusters eventually fail. Multiple small clusters survive.
        qaq 3y ago
        Replacing function call with network call does not really solve any org issues. There is pretty much 0 difference if teams are shipping "modules" for a monolith vs a microservice outside of much simplified CI/CD setup in case of monolith. You can gain some scaling efficiencies from scaling services independently but it's a minor advantage for most projects.
        Aeolun 3y ago
        > You can gain some scaling efficiencies from scaling services independently Not necessarily, because if you scale only one of your services all the other services do not benefit at all. Having microservices would only be better in that instance if they actually consume the resources they are given.
    - wiseowise 3y ago
      And you of course have data to prove it, right?
      - rjh29 3y ago
        Experience.
- sleiben 3y ago
  We use the microservices architecture as a single team and don’t have any issues with this for many years. The key is to have a monorepo and stay consistent by following strict coding guidelines. In my opinion it makes the backend way more resilient than a monolith. Don’t kill me for this opinion please ;)
  - BoorishBears 3y ago
    How does it make the backend more resilient than a monolith? Do you not realize you have multiple instances of a monolith or something?
    - ahoka 3y ago
      Bad input crashes app, monolith fails over, other instance crashes. Full outage. Assuming proper vertical separation, this risk can be reduced by microservices.
      - elktown 3y ago
        It might just as well be increased by microservices due to fragile dependency chains and just different people working async and what not.
        ahoka 3y ago
        Maybe read my comment again.
        elktown 3y ago
        Care to enlighten me? Your comment reads like "assuming the best case scenario for X and worst case scenario for Y, X can reduce the risk". Well, you don't say.
      - BoorishBears 3y ago
        This is not what microservices solve. There'll always be critical microservices that keep your app running. It doesn't matter if all your other services are running if the one serving up core functionality goes down. If your engineering rigor is so poor that you can't get reliable failovers with a monolith, god help you keeping microservices running.
- devjab 3y ago
  In two decades of development I've never once seen a monolithic architecture that with some form of shared database not be terrible for the business it powered. I certainly understand why it's very common, it's what's still being taught to most CS students in my country after all, and, it's frankly a lot easier to implement. The result, however, is always the same. It ends up being a mess where nobody can do anything because the data structures are so intertwined (and undocumented) that nobody knows how it's actually used. What happens is that monoliths become magnets for business logic, and then you bottleneck every change into requireing a select few members of your organisation. As time goes by, you end up with a giant turd that stagnates and directly hurts your business. Not by intention, but because that's exactly what happens when you make things complicated. It's important to keep in mind that this isn't a technical problem. It's an organisational problem. In fact, there is no technical reason why monoliths would be an anti-pattern, which is likely why they are still being taught as though they weren't at many universities where professors still naively think that the MBA's aren't going to cost-cut IT at every opportunity even though their entire organisation is made up of employees who spend 100% of their working time on IT devices of some form. Similarily, Microservices, aren't really the "technical" response to this. It's how IT and digitalisation had to evolve to keep up with business demands and better generate value. The simpler and more decoupled you keep things, the better you'll be able to respond to business needs. Sure, there are a gazillion different ways to do Microservices wrong, and if you do it wrong, then you'll likely be in the same mess that you would be with a monolith, only so much worse, because now you have 9 million tiny monoliths and shared databases. Luckily we still live in a world where everyone is somehow still OK with IT not working. We went to an appointment that isn't relevant the other day, and they had a tablet where you could register your license plate to avoid getting a parking ticket. It didn't work, so we talked with the receptionist who was like "yeah, it does that all the time, don't worry, if the systems are down then they can't give out tickets"... Fine for us, but think about that... It turned out the system was down in my entire city, which means that all those hundreds of employees who are out handing out tickets had nothing to do while their IT system was being fixed, hell, the entire company wasn't generating income for my city while their IT was down, and this was a regular occurrence? What my point with this is, is that you can do things really wrong, and still be a "successful" company, it's just that the companies who manage to generate value better (which is frankly always microservices of some form) tend to simply do better. But like I said. You can do "microservices" in a million different ways. Running two different django backends to handle different parts of Instagram could be considered having two microservices after all. The importance is how you deal with the needs of your organisaiton in a rapid fashion.
qaq 3y ago
Well it's not like you have have to get into microservices
koonsolo 3y ago
Honest question: what justifies microservices in the popular companies compared to instagram? Twitter: just sharing a bunch of text. Netflix: platform with static content, where sharing isn't even possible. TikToķ: Instagram for video, so basically just bigger files. WhatsApp: they also pulled it off with a small team. If you talk about Roblox, now there's a challenge! And they pulled it off with way less engineers than Twitter.
- the-smug-one 3y ago
  For Twitter and TikTok, I bet that the reasons are B2B offerings and not their B2C offerings.

Scarblac 3y ago

That's why it's important to keep the number of devs low, it makes it less likely that one starts talking about microservices.

pestaa 3y ago
It's more important to keep the number of features low. Good devs talk about aligning the architecture to requirements, and that sometimes includes microservices.
- Sparkyte 3y ago
  This is true. I completely agree with the minimized scope. However a dev needs to be careful to not let their service just sit unmaintained. New teams will always need engineers to maintain and improve.
Sparkyte 3y ago
You talk as if monolithic apps are vastly superior. To be forward it depends entirely on the purpose and life of the application. It is about whatever shoe fits the design.
- Aeolun 3y ago
  Sure. It’s just that 99% of applications work fine (or better) as a monolithic design.
  - Sparkyte 3y ago
    Depends on the purpose of the application though. Monolithic is a good architecture when you have a few purposeful features and functions. But when your design relies on many services to provide a wide variety of features you need to break out this design to allow teams to operate independently. Mini monoliths are more popular today than traditional monoliths of the old.
    - qaq 3y ago
      You can split things up you don't have to though. Teams operating independently is fairly orthogonal to this.
      - Sparkyte 3y ago
        Yeah no I get you. You just want a monolith to be purposeful when you design one. Not multi-purposeful. This is also at the limitation of a programming language. I am kind of kubernetes guy, but I am dying because it relies heavily on a virtualize network distributed. It would drastically increase the performance if kubernetes clusters were built like monoliths and each kubernetes node handled traffic independently. So of like keeping it all in the same rack. Only leaving the rack if needed. But I keep seeing bad technology decisions repeated over and over. I stopped pushing because some person with a bigger title would say this is good design. Big kubernetes clusters eventually fail. Multiple small clusters survive.
        qaq 3y ago
        Replacing function call with network call does not really solve any org issues. There is pretty much 0 difference if teams are shipping "modules" for a monolith vs a microservice outside of much simplified CI/CD setup in case of monolith. You can gain some scaling efficiencies from scaling services independently but it's a minor advantage for most projects.
        Aeolun 3y ago
        > You can gain some scaling efficiencies from scaling services independently Not necessarily, because if you scale only one of your services all the other services do not benefit at all. Having microservices would only be better in that instance if they actually consume the resources they are given.
  - wiseowise 3y ago
    And you of course have data to prove it, right?
    - rjh29 3y ago
      Experience.
sleiben 3y ago
We use the microservices architecture as a single team and don’t have any issues with this for many years. The key is to have a monorepo and stay consistent by following strict coding guidelines. In my opinion it makes the backend way more resilient than a monolith. Don’t kill me for this opinion please ;)
- BoorishBears 3y ago
  How does it make the backend more resilient than a monolith? Do you not realize you have multiple instances of a monolith or something?
  - ahoka 3y ago
    Bad input crashes app, monolith fails over, other instance crashes. Full outage. Assuming proper vertical separation, this risk can be reduced by microservices.
    - elktown 3y ago
      It might just as well be increased by microservices due to fragile dependency chains and just different people working async and what not.
      - ahoka 3y ago
        Maybe read my comment again.
        elktown 3y ago
        Care to enlighten me? Your comment reads like "assuming the best case scenario for X and worst case scenario for Y, X can reduce the risk". Well, you don't say.
    - BoorishBears 3y ago
      This is not what microservices solve. There'll always be critical microservices that keep your app running. It doesn't matter if all your other services are running if the one serving up core functionality goes down. If your engineering rigor is so poor that you can't get reliable failovers with a monolith, god help you keeping microservices running.
devjab 3y ago
In two decades of development I've never once seen a monolithic architecture that with some form of shared database not be terrible for the business it powered. I certainly understand why it's very common, it's what's still being taught to most CS students in my country after all, and, it's frankly a lot easier to implement. The result, however, is always the same. It ends up being a mess where nobody can do anything because the data structures are so intertwined (and undocumented) that nobody knows how it's actually used. What happens is that monoliths become magnets for business logic, and then you bottleneck every change into requireing a select few members of your organisation. As time goes by, you end up with a giant turd that stagnates and directly hurts your business. Not by intention, but because that's exactly what happens when you make things complicated. It's important to keep in mind that this isn't a technical problem. It's an organisational problem. In fact, there is no technical reason why monoliths would be an anti-pattern, which is likely why they are still being taught as though they weren't at many universities where professors still naively think that the MBA's aren't going to cost-cut IT at every opportunity even though their entire organisation is made up of employees who spend 100% of their working time on IT devices of some form. Similarily, Microservices, aren't really the "technical" response to this. It's how IT and digitalisation had to evolve to keep up with business demands and better generate value. The simpler and more decoupled you keep things, the better you'll be able to respond to business needs. Sure, there are a gazillion different ways to do Microservices wrong, and if you do it wrong, then you'll likely be in the same mess that you would be with a monolith, only so much worse, because now you have 9 million tiny monoliths and shared databases. Luckily we still live in a world where everyone is somehow still OK with IT not working. We went to an appointment that isn't relevant the other day, and they had a tablet where you could register your license plate to avoid getting a parking ticket. It didn't work, so we talked with the receptionist who was like "yeah, it does that all the time, don't worry, if the systems are down then they can't give out tickets"... Fine for us, but think about that... It turned out the system was down in my entire city, which means that all those hundreds of employees who are out handing out tickets had nothing to do while their IT system was being fixed, hell, the entire company wasn't generating income for my city while their IT was down, and this was a regular occurrence? What my point with this is, is that you can do things really wrong, and still be a "successful" company, it's just that the companies who manage to generate value better (which is frankly always microservices of some form) tend to simply do better. But like I said. You can do "microservices" in a million different ways. Running two different django backends to handle different parts of Instagram could be considered having two microservices after all. The importance is how you deal with the needs of your organisaiton in a rapid fashion.

qaq 3y ago

Well it's not like you have have to get into microservices

koonsolo 3y ago

Honest question: what justifies microservices in the popular companies compared to instagram? Twitter: just sharing a bunch of text. Netflix: platform with static content, where sharing isn't even possible. TikToķ: Instagram for video, so basically just bigger files. WhatsApp: they also pulled it off with a small team. If you talk about Roblox, now there's a challenge! And they pulled it off with way less engineers than Twitter.

the-smug-one 3y ago
For Twitter and TikTok, I bet that the reasons are B2B offerings and not their B2C offerings.