3 ms·

>It's just one way to manage our data Sure, but there are tradeoffs to any approach. More services == more devops == more complexity in fault tolerance, commun

>It's just one way to manage our data Sure, but there are tradeoffs to any approach. More services == more devops == more complexity in fault tolerance, communication, data storage/consistency, etc. I'm not saying it's a bad model _for you_, obviously I have no idea, but the point of the article is that some tend to jump toward complexity when they shouldn't.

revskill 8y ago
It's not "more services == more devops". It's like this: Only manage the nessessary data. If i need to change one part of data, i don't migrate the whole data. I just need to change that only changed part.
- EpicEng 8y ago
  I can't imagine a microservice architecture that does not require more devops work than a comparable and sane monolith. Your second and third sentences haven't convinced me.
  - staticassertion 8y ago
    At one company I was at we moved to microservices to reduce ops work. Scale independence was a huge value add for us.
  - revskill 8y ago
    Not quite. With a monothlic, it's an overhead to migrate data, because one small mistake will take your application down. So, in real world, it takes more overhead to manage a monothlic than a microservice architecture.
    - iBelieve 8y ago
      With microservices, if you make a mistake and take part of your application down, aren't you worse off because only part of your application is running and is now in an undefined state?
      - revskill 8y ago
        It's fine to have only one part of the application down, instead of the whole go down. Each part of application is ran by different roles/functionalities.
      - threeseed 8y ago
        You really need to think that comment through first. If you're a bank then it's fine if your notification microservice goes down because at least you can still accept payments, handle deposits, transfer money etc. In almost no situation is there a case where having no availability is preferred over partial availability.
  - threeseed 8y ago
    Developers and operations often love microservices. If you make one small change you only have to test and deploy that one microservice. Instead of having to redeploy the monolith which not sure if you've ever done that before is often terrifying.
threeseed 8y ago
Then let's write all of our code in one class with global variables. More classes == more testing == more complexity == more communication issues.
- EpicEng 8y ago
  That's pretty hyperbolic. Are you implying that monolithic designs are just inherently inferior? I don't think that even approaches a reasonable take on the subject.
  - threeseed 8y ago
    It's a pretty good analogy actually. If you think back to the early Java days when everyone was obsessed with design patterns and over engineered code people said exactly the same thing. Why do you have these interfaces if the implementation will never change ? So I'm not saying monolithic designs are bad but they simply don't scale well once you get to a certain size. Just like design patterns should only be used once your codebase gets to a certain size.
    - EpicEng 8y ago
      I wouldn't say that's quite the same thing, and people _absolutely do_ over engineer/encapsulate their code today. In my own, admittedly limited experience, it seems to me that the biggest win with microservices are realized when you have large teams working independently. There is a complexity overhead that, in my opinion, isn't justified for most apps being worked on by small teams. That said, I don't hold a hard opinion here; I don't have enough experience with them yet. I'm open to having my mind changed.
- merb 8y ago
  you actually need more testing if you have more services. especially integration tests are way harder to pull of in a microservices architecture. also communication issues arise from bad api design, which of course can happen with microservices as good as in monoliths.

revskill 8y ago

It's not "more services == more devops". It's like this: Only manage the nessessary data. If i need to change one part of data, i don't migrate the whole data. I just need to change that only changed part.

EpicEng 8y ago
I can't imagine a microservice architecture that does not require more devops work than a comparable and sane monolith. Your second and third sentences haven't convinced me.
- staticassertion 8y ago
  At one company I was at we moved to microservices to reduce ops work. Scale independence was a huge value add for us.
- revskill 8y ago
  Not quite. With a monothlic, it's an overhead to migrate data, because one small mistake will take your application down. So, in real world, it takes more overhead to manage a monothlic than a microservice architecture.
  - iBelieve 8y ago
    With microservices, if you make a mistake and take part of your application down, aren't you worse off because only part of your application is running and is now in an undefined state?
    - revskill 8y ago
      It's fine to have only one part of the application down, instead of the whole go down. Each part of application is ran by different roles/functionalities.
    - threeseed 8y ago
      You really need to think that comment through first. If you're a bank then it's fine if your notification microservice goes down because at least you can still accept payments, handle deposits, transfer money etc. In almost no situation is there a case where having no availability is preferred over partial availability.
- threeseed 8y ago
  Developers and operations often love microservices. If you make one small change you only have to test and deploy that one microservice. Instead of having to redeploy the monolith which not sure if you've ever done that before is often terrifying.

threeseed 8y ago

Then let's write all of our code in one class with global variables. More classes == more testing == more complexity == more communication issues.

EpicEng 8y ago
That's pretty hyperbolic. Are you implying that monolithic designs are just inherently inferior? I don't think that even approaches a reasonable take on the subject.
- threeseed 8y ago
  It's a pretty good analogy actually. If you think back to the early Java days when everyone was obsessed with design patterns and over engineered code people said exactly the same thing. Why do you have these interfaces if the implementation will never change ? So I'm not saying monolithic designs are bad but they simply don't scale well once you get to a certain size. Just like design patterns should only be used once your codebase gets to a certain size.
  - EpicEng 8y ago
    I wouldn't say that's quite the same thing, and people _absolutely do_ over engineer/encapsulate their code today. In my own, admittedly limited experience, it seems to me that the biggest win with microservices are realized when you have large teams working independently. There is a complexity overhead that, in my opinion, isn't justified for most apps being worked on by small teams. That said, I don't hold a hard opinion here; I don't have enough experience with them yet. I'm open to having my mind changed.
merb 8y ago
you actually need more testing if you have more services. especially integration tests are way harder to pull of in a microservices architecture. also communication issues arise from bad api design, which of course can happen with microservices as good as in monoliths.