4 ms·

Microservices tend to provide good isolation barriers in systems and those tend to increase stability of highly complex systems. Though Erlang is a counterexam

• hackerfromthefu 6y ago
  Having a compiler able to check your whole system at once, tends to increase stability of highly complex systems. But microservices breaks that, as well as introduces many other consistency problems, plus huge complexity overhead, all of which are forces toward instability in highly complex systems. I suggest that the important factors for stability are not really about microservices, and that depending on the situation microservices is usually a net negative for stability, for the reasons mentioned above.
  • onethought 6y ago
    This isn’t true. You can run all your micro services together and check them on a single computer. Micro services doesn’t break that. So, no net negative. As other people have pointed out. It’s a tool... you can have bad code in a monolith just as much as micro services.
    • bob1029 6y ago
      Microservices does break compile-time type checking. Runtime correctness != compile-time correctness. This is all assuming you managed to convince everyone to use the same language and throw everything under 1 solution too. I absolutely love that our application takes just a little bit longer to build than a smaller isolated microservice. This is when my computer is doing all of the hard troubleshooting work for me ahead of time. 32+ cores diligently seeking out my wasted time and banishing bugs before they can even make it into QA. Determining that your types don't line up during integration testing seems like a foolish approach if you value your time.
      • onethought 6y ago
        No it doesn’t. Typescript/GraphQL both have strong type checking. I think you need to be more familiar with the available tech before spreading FUD. You can even compose the micro services into a monolith if you want everything to just run. It’s a tool not a religion. Yes I’m assuming conventions for services, just as in a monolith I’d assume standards for design and composition (usually an overriding architecture like MVC or some such).
        • bob1029 6y ago
          I am very familiar with the tech. You cannot move the goal posts around regarding the nature of your application architecture and then claim that I am spreading FUD as a result. Strong type checking across the scope of the entire problem domain is the guarantee that I am ultimately looking for. Only if you compile your whole application into a single binary output do you get these guarantees. I do not care that each microservice independently passes type checks. This is hardly a compelling argument if we are talking about delivering working products. The most critical points of verification in a system with multiple services are where all of these pieces connect back together.
          • onethought 6y ago
            The interaction between the services (connection points) would also pass type checks. (Because they are typed as well) ... so that’s the whole problem domain. No move of goal post. And no, like I said with things like typescript (And flow or Sorbet) you don’t need to compile any binary at all let a lone a single one. Also: a monolith does not refer to a single binary it refers to a single application code base. (You can have monoliths in Ruby/Python/JavaScript/php/etc where no binary is produced) I think you are misunderstanding what I’m saying, because I’m basically saying the same thing again: - service A consumes service B - they are both type checked (as you readily admit) - the call site of service B in service A is type checked as well. - there are 0 points in the code or interactions that are not type checked.