5 ms·

Microservices done right help isolate issues though. If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know whi

Microservices done right help isolate issues though. If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. Of course it might turn out that the errors are coming from bad inbound REST calls, but regardless it helps to narrow things down. I don't think that microservices work well with a pure server kind of architecture. For one you miss out on a fundamental microservice advantages, scalability and portability.

candiddevmike 6y ago
Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop"). A monolith can be quite scalable and portable.
- coding123 6y ago
  Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.
  - cameronbrown 6y ago
    Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.
    - coding123 6y ago
      The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).
- hvidgaard 6y ago
  My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later. By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.
  - linkdd 6y ago
    Not doing microservice does not mean doing monolith. There is an in-between that you can aim for.
- 100011_100001 6y ago
  But you don't have to recreate the entire stack, that's the whole point.
mumblemumble 6y ago
> If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. If you have a system with 100 well-defined modules, but blue-widget-model is throwing errors, you know which codebase you need to look at. No modularization technique has a monopoly on this characteristic.
- 100011_100001 6y ago
  It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.
  - mumblemumble 6y ago
    I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
    - 100011_100001 6y ago
      Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
      - rowland66 6y ago
        I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.

candiddevmike 6y ago

Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop"). A monolith can be quite scalable and portable.

coding123 6y ago
Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.
- cameronbrown 6y ago
  Hmm, wouldn't it make more sense to keep batch jobs outside the monolith? Everything else makes sense to stay in a single binary.
  - coding123 6y ago
    The point of it is to be able to run it simply for developers developering things. If I run in prod with 12 different splits of code, that's fine. If I want to run this locally to develop new features, I would love to put in a breakpoint to see my puppeteer job run to do some screen scraping without having to have 15 VSCode windows open. (Which is what I sometimes have to do at my current company because we're a team of 6 doing microservices with 12 apps (more planned yay).
hvidgaard 6y ago
My experience is that monoliths tend to decay over time unless some serious discipline is enforced. It's possible to reference across boundaries, so that happens sooner or later. By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.
- linkdd 6y ago
  Not doing microservice does not mean doing monolith. There is an in-between that you can aim for.
100011_100001 6y ago
But you don't have to recreate the entire stack, that's the whole point.

mumblemumble 6y ago

> If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. If you have a system with 100 well-defined modules, but blue-widget-model is throwing errors, you know which codebase you need to look at. No modularization technique has a monopoly on this characteristic.

100011_100001 6y ago
It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.
- mumblemumble 6y ago
  I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
  - 100011_100001 6y ago
    Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
    - rowland66 6y ago
      I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.