8 ms·

I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.

by solmag 5y ago

wongarsu 5y ago
Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir
- foobarian 5y ago
  Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. Need an out of cycle release? Hopefully you have CI/CD or now you have to beg the SRE in charge to do it for you.
  - Sebb767 5y ago
    > Splitting a system into microservices can help individual teams be better stewards of their part of the system. Team being the keyword here. If you have 3-5 developers per microservice, you're absolutely okay. If you have 3-5 microservices per developer, that's when it gets ugly.
  - yakshaving_jgt 5y ago
    Given your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper. > heck even a different language There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.
    - foobarian 5y ago
      > There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls I mean it's only computers and the only limit to what we can make them do is our imagination. In this case though for the sake of argument what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. I'm not sure how I would accomplish this in a monolith.
      - ratww 5y ago
        > I'm not sure how I would accomplish this in a monolith. With a library. Depending on what you’re doing (process ran a few times a day?), maybe even spawning a process is enough. > what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. That sounds like you need at most two different services, not microservices.
        foobarian 5y ago
        > With a library. I don't know what that library is right now. Meanwhile I could set up the separate repos/microservices by the end of the day. > That sounds like you need at most two different services, not microservices It is unfortunate that the "micro" in "microservice" is often misunderstood to expect that these are very small and granular components. In practice by and large it ends up being separate services with separate repo, code review, ownership, deploy or CI/CD etc. pipelines. It doesn't have to mean they are actually very small. I know people like to joke about npm components and the leftpad thing but in my experience microservices have not turned out like that.
        ratww 5y ago
        > I don't know what that library is right now Are you serious? In which language do you program that you don't have to use multiple libraries daily? You just talked about NPM. In your example, the C# could output DLLs that have functions that can be called by the Java code. This can give the same encapsulation you get with your multiple services example, including separate deployments, different repo, different language, etc. You could also use different processes. Please tell me you know what an executable is... > Meanwhile I could set up the separate repos/microservices by the end of the day That's because someone set it up for you, not because it's faster. In your hypothetical scenario of "I needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system" you didn't mention that "…but we already have a fast way of setting up micro services". > It is unfortunate that the "micro" in "microservice" is often misunderstood* It's not, you're using the term loosely. "Two services" do not make a micro service architecture. Sorry to be blunt, but I'm getting the feeling you're not talking out of experience, but rather repeating popular talking points.
  - WJW 5y ago
    If you don't even have CI/CD yet I'll argue that your team has not reached the operational sophistication required for microservices yet. There are many ways in which microservices Also if individual devs can reach out across the codebase and turn private methods public, it is the pull request review procedure that you need to improve, not the architecture.
  - drunkpotato 5y ago
    Yes, that is the marketing brochure pitch for microservices. In the real world, poorly designed microservices make the ball of mud problem much, much worse, and whatever pain you had in deployments in a monolith are now magnified ten-fold. I have not been fortunate enough to see well-designed microservices, so I suspect the ball of mud is the default. Can this be rectified through discipline? Probably, but I haven't seen it. Asynchronous? Doesn't save you, when an upstream service changes event definitions and emits events with unexpected structure, and a downstream service starts failing. Can this be rectified through Async OpenAPI and rigorous contract testing? Probably, but I haven't seen this happen in a way that helps. I have seen large companies survive perfectly well on a monolithic ball of mud, and small companies get lost in a mud pit of microservices. My point is not that microservices are bad, they're not, they're just a tool, but they are a tool that is a poor fit for most companies, in my opinion. I can't speak to the few giant companies that need them and use them effectively; there is a good reason the tool exists.
    - foobarian 5y ago
      > In the real world, poorly designed microservices make the ball of mud problem much, much worse I can see that. I am trying to reflect on why I have such negative experience with a monolith and positive with microservices. It's possible that in the monolith setups I had, poor design was easy by default. No linting, no cross-module ownership interlocks, very slow and costly production deploys. Likewise the microservice setups tended to make poor design harder since code is isolated by default both at compile and runtime. Can you make a monolith with all the good benefits of modularity but without the complications of network RPC etc.? Maybe, but I haven't seen it yet. (Excluding trivial single-team apps; talking about at least 3 teams and 50+ headcount orgs). > Asynchronous? Doesn't save you, when an upstream service changes event definitions and emits events with unexpected structure, and a downstream service starts failing Sure, shit happens. Again my experience may be colored, but when costly mistakes happen in monoliths, it tended to take longer to roll back because of how deploys are structured both technically and on an organizational level. I think I would still prefer smaller units in this case.
  - ratww 5y ago
    > With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. If "any developer" can do it, then the problem is not with monoliths, but rather with your pull request reviews process and lack of code ownership. This can even be helped by Github and other platforms with a CODEOWNERS file. Microservices by themselves doesn't solve this problem. If anyone has commit access to all micro services, then they can make an even bigger mess, the same way.
    - foobarian 5y ago
      I haven't had experience with well isolated modules in a monolith so I'm likely not giving monolith enough credit here. It's possible a microservice organization may still have an advantage by having more of this isolation by default, instead of an uphill battle to get things set up properly.
      - ratww 5y ago
        If you are already doing code reviews, it is trivial to setup. If you’re using microservices + monorepo, you need exactly the same thing, otherwise people will just commit in your service. If you’re relying on multiple repositories, you can just split things within libraries and have the exact same effect. You can even have separate deployments with this arrangement. Not to mention it is also an “uphill battle to get things set up properly” with microservices, so there’s really no advantage in using them for enforcing encapsulation. But most important: a team unable to enforce encapsulation and code ownership is not ready for microservices at all.
      - deleted 5y ago
        [deleted]
- jayd16 5y ago
  In process queues don't offer the same capacity smoothing as a shared queue. I don't think most of those queues offer persistence either. They're really not equivalent, are they?
cjfd 5y ago
Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.
- jayd16 5y ago
  So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
  - cjfd 5y ago
    Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.
    - jayd16 5y ago
      >On the other hand, why not a monolith and single instance? Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.
      - ratww 5y ago
        Running a single instance doesn’t mean not having a backup.
  - imwillofficial 5y ago
    I didn’t read any of that. I read it as more tools in the toolbox.

I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.

by solmag 5y ago

I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.

Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir

foobarian 5y ago
Splitting a system into microservices can help individual teams be better stewards of their part of the system. They can release on their own schedule, they can use their own linting rules, heck even a different language, and they can have better control of incoming code changes. With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. Need an out of cycle release? Hopefully you have CI/CD or now you have to beg the SRE in charge to do it for you.
- Sebb767 5y ago
  > Splitting a system into microservices can help individual teams be better stewards of their part of the system. Team being the keyword here. If you have 3-5 developers per microservice, you're absolutely okay. If you have 3-5 microservices per developer, that's when it gets ugly.
- yakshaving_jgt 5y ago
  Given your negative characterisation of the "ball of mud", I'm guessing you haven't actually read the original paper. > heck even a different language There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls.
  - foobarian 5y ago
    > There's nothing about writing software in different languages that necessitates separating functionality with HTTP calls I mean it's only computers and the only limit to what we can make them do is our imagination. In this case though for the sake of argument what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. I'm not sure how I would accomplish this in a monolith.
    - ratww 5y ago
      > I'm not sure how I would accomplish this in a monolith. With a library. Depending on what you’re doing (process ran a few times a day?), maybe even spawning a process is enough. > what options would I have if I, say, needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system. That sounds like you need at most two different services, not microservices.
      - foobarian 5y ago
        > With a library. I don't know what that library is right now. Meanwhile I could set up the separate repos/microservices by the end of the day. > That sounds like you need at most two different services, not microservices It is unfortunate that the "micro" in "microservice" is often misunderstood to expect that these are very small and granular components. In practice by and large it ends up being separate services with separate repo, code review, ownership, deploy or CI/CD etc. pipelines. It doesn't have to mean they are actually very small. I know people like to joke about npm components and the leftpad thing but in my experience microservices have not turned out like that.
        ratww 5y ago
        > I don't know what that library is right now Are you serious? In which language do you program that you don't have to use multiple libraries daily? You just talked about NPM. In your example, the C# could output DLLs that have functions that can be called by the Java code. This can give the same encapsulation you get with your multiple services example, including separate deployments, different repo, different language, etc. You could also use different processes. Please tell me you know what an executable is... > Meanwhile I could set up the separate repos/microservices by the end of the day That's because someone set it up for you, not because it's faster. In your hypothetical scenario of "I needed to let a remote team add some functionality to my, say, Spring backend but they really prefer to write C# and have their own CI/CD system" you didn't mention that "…but we already have a fast way of setting up micro services". > It is unfortunate that the "micro" in "microservice" is often misunderstood* It's not, you're using the term loosely. "Two services" do not make a micro service architecture. Sorry to be blunt, but I'm getting the feeling you're not talking out of experience, but rather repeating popular talking points.
- WJW 5y ago
  If you don't even have CI/CD yet I'll argue that your team has not reached the operational sophistication required for microservices yet. There are many ways in which microservices Also if individual devs can reach out across the codebase and turn private methods public, it is the pull request review procedure that you need to improve, not the architecture.
- drunkpotato 5y ago
  Yes, that is the marketing brochure pitch for microservices. In the real world, poorly designed microservices make the ball of mud problem much, much worse, and whatever pain you had in deployments in a monolith are now magnified ten-fold. I have not been fortunate enough to see well-designed microservices, so I suspect the ball of mud is the default. Can this be rectified through discipline? Probably, but I haven't seen it. Asynchronous? Doesn't save you, when an upstream service changes event definitions and emits events with unexpected structure, and a downstream service starts failing. Can this be rectified through Async OpenAPI and rigorous contract testing? Probably, but I haven't seen this happen in a way that helps. I have seen large companies survive perfectly well on a monolithic ball of mud, and small companies get lost in a mud pit of microservices. My point is not that microservices are bad, they're not, they're just a tool, but they are a tool that is a poor fit for most companies, in my opinion. I can't speak to the few giant companies that need them and use them effectively; there is a good reason the tool exists.
  - foobarian 5y ago
    > In the real world, poorly designed microservices make the ball of mud problem much, much worse I can see that. I am trying to reflect on why I have such negative experience with a monolith and positive with microservices. It's possible that in the monolith setups I had, poor design was easy by default. No linting, no cross-module ownership interlocks, very slow and costly production deploys. Likewise the microservice setups tended to make poor design harder since code is isolated by default both at compile and runtime. Can you make a monolith with all the good benefits of modularity but without the complications of network RPC etc.? Maybe, but I haven't seen it yet. (Excluding trivial single-team apps; talking about at least 3 teams and 50+ headcount orgs). > Asynchronous? Doesn't save you, when an upstream service changes event definitions and emits events with unexpected structure, and a downstream service starts failing Sure, shit happens. Again my experience may be colored, but when costly mistakes happen in monoliths, it tended to take longer to roll back because of how deploys are structured both technically and on an organizational level. I think I would still prefer smaller units in this case.
- ratww 5y ago
  > With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud. If "any developer" can do it, then the problem is not with monoliths, but rather with your pull request reviews process and lack of code ownership. This can even be helped by Github and other platforms with a CODEOWNERS file. Microservices by themselves doesn't solve this problem. If anyone has commit access to all micro services, then they can make an even bigger mess, the same way.
  - foobarian 5y ago
    I haven't had experience with well isolated modules in a monolith so I'm likely not giving monolith enough credit here. It's possible a microservice organization may still have an advantage by having more of this isolation by default, instead of an uphill battle to get things set up properly.
    - ratww 5y ago
      If you are already doing code reviews, it is trivial to setup. If you’re using microservices + monorepo, you need exactly the same thing, otherwise people will just commit in your service. If you’re relying on multiple repositories, you can just split things within libraries and have the exact same effect. You can even have separate deployments with this arrangement. Not to mention it is also an “uphill battle to get things set up properly” with microservices, so there’s really no advantage in using them for enforcing encapsulation. But most important: a team unable to enforce encapsulation and code ownership is not ready for microservices at all.
    - deleted 5y ago
      [deleted]
jayd16 5y ago
In process queues don't offer the same capacity smoothing as a shared queue. I don't think most of those queues offer persistence either. They're really not equivalent, are they?

cjfd 5y ago

Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.

jayd16 5y ago
So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
- cjfd 5y ago
  Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue. On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.
  - jayd16 5y ago
    >On the other hand, why not a monolith and single instance? Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.
    - ratww 5y ago
      Running a single instance doesn’t mean not having a backup.
- imwillofficial 5y ago
  I didn’t read any of that. I read it as more tools in the toolbox.