4 ms·

OK imagine that you have two different modules that manage transactions to a database. Now suddenly you need there to be consistent mutations between those func

OK imagine that you have two different modules that manage transactions to a database. Now suddenly you need there to be consistent mutations between those functions. Do you see my point? Microservices do nothing here - you have run into antipatterns that are universal, and that microservice architecture addresses explicitly as an antipattern.

dagss 4y ago
I do not see your point. Sometimes consistent mutations between modules is wanted. Monoliths lets you do it. Perhaps you discovered your module boundaries were wrong, you create a supermodule to encaspulate both to coordinate the joint transaction and then split up later a different way and so on. Module boundaries are refactorable. Importantly, what if the alternatives you end up with achieve the same things with microservices end up causing a ball of mud of services, reimplementing transaction logic that belong in your DB in your homegrown network protocols? You seem to say that some things are not possible with microservices and therefore this leads to cleaner code. My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices are so complex that the cure is worse than the disease you wanted to cure in the first place.
- staticassertion 4y ago
  > Module boundaries are refactorable. Why are microservices not refactorable? This is the same exact issue in both cases. You designed something for a use case, the use case changed, now your old design isn't working. So maybe you merge those two services, or merge those two modules, or whatever else you want to do. > reimplementing transaction logic that belong in your DB in your homegrown network protocols Don't do that? I mean, again, this issue of "I wrote something the wrong way and now I have to fix that" is not any better or worse in microservices. > My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices That doesn't sound like microservices. In fact, even the idea of having a database shared across services doesn't sound like microservices - it's an explicit antipattern. So it sounds like a bad SOA design. The point of microservices is to take SOA and add patterns and guidance to avoid the issues you're talking about.
  - dagss 4y ago
    Microservices gets owned by different teams, teams get cemented, politics get in the way of refactoring. Game over. Sure, if you are a single team working on 10 microservices you can probably refactor with abandon without spending 70% of your working days in meetings talking about migrations and trying to sync strategies... You may have experiences that that microservices are as easy to refactor as monoliths; in my experience it is orders of magnitude harder... I think there is a bit of a "No true scotsman" fallacy at play here. You see something you do not like then it is "not microservices done properly". How about state all the things you don't like about monoliths , then I say "that is not monoliths done properly", "don't do that" for each one? I think both monoliths and microservices can lead to good code or balls of mud depending on the organization and developers involved. Real question isn't whether "microservices done right" is better. The question is: does a Decision to do microservices reduce the chances of a ball of mud, when that Decision is then implemented by imperfect developers in an imperfect organization? PS I always meant that each microservice had their own DB above, we agree on that and I never dreamt otherwise. What I was getting at is that when you go distributed, sometimes quite complex patterns must be applied to compensate. You may say the architecture is then "better", but on what metric? It is certainly more work up front -- so you start out in the negative and to become better the system and organization need at least to get to a certain scale, you need to save in the hours you invested to come out ahead. In many scenarios the cost in developer-months needed up front is just as important as other factors in evaluating the best architecture. E.g. a scrappy startup simply should not do it IMO. Corporations..... perhaps;but I have seen it gone badly. (I guess it is just not "done right" then? See above.)
    - dagss 4y ago
      PS I think microservices excel in making people FEEL productive (doing work that is not directly benefiting the company). I have personal experience with the same product built twice, once as a monolith by a small team that worked really well and once as lots of services. The featureset and development speed is about the same, but the many-services requires 10x as many people. However by splitting into many services everyone feels productive doing auxiliary and incidental work. Only those of us who worked on the first system are able to see that the total output of the company is the same but 10x as expensive.

dagss 4y ago

I do not see your point. Sometimes consistent mutations between modules is wanted. Monoliths lets you do it. Perhaps you discovered your module boundaries were wrong, you create a supermodule to encaspulate both to coordinate the joint transaction and then split up later a different way and so on. Module boundaries are refactorable. Importantly, what if the alternatives you end up with achieve the same things with microservices end up causing a ball of mud of services, reimplementing transaction logic that belong in your DB in your homegrown network protocols? You seem to say that some things are not possible with microservices and therefore this leads to cleaner code. My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices are so complex that the cure is worse than the disease you wanted to cure in the first place.

staticassertion 4y ago
> Module boundaries are refactorable. Why are microservices not refactorable? This is the same exact issue in both cases. You designed something for a use case, the use case changed, now your old design isn't working. So maybe you merge those two services, or merge those two modules, or whatever else you want to do. > reimplementing transaction logic that belong in your DB in your homegrown network protocols Don't do that? I mean, again, this issue of "I wrote something the wrong way and now I have to fix that" is not any better or worse in microservices. > My retort is that the kind of things one sometimes come up with as workarounds to make things still work for microservices That doesn't sound like microservices. In fact, even the idea of having a database shared across services doesn't sound like microservices - it's an explicit antipattern. So it sounds like a bad SOA design. The point of microservices is to take SOA and add patterns and guidance to avoid the issues you're talking about.
- dagss 4y ago
  Microservices gets owned by different teams, teams get cemented, politics get in the way of refactoring. Game over. Sure, if you are a single team working on 10 microservices you can probably refactor with abandon without spending 70% of your working days in meetings talking about migrations and trying to sync strategies... You may have experiences that that microservices are as easy to refactor as monoliths; in my experience it is orders of magnitude harder... I think there is a bit of a "No true scotsman" fallacy at play here. You see something you do not like then it is "not microservices done properly". How about state all the things you don't like about monoliths , then I say "that is not monoliths done properly", "don't do that" for each one? I think both monoliths and microservices can lead to good code or balls of mud depending on the organization and developers involved. Real question isn't whether "microservices done right" is better. The question is: does a Decision to do microservices reduce the chances of a ball of mud, when that Decision is then implemented by imperfect developers in an imperfect organization? PS I always meant that each microservice had their own DB above, we agree on that and I never dreamt otherwise. What I was getting at is that when you go distributed, sometimes quite complex patterns must be applied to compensate. You may say the architecture is then "better", but on what metric? It is certainly more work up front -- so you start out in the negative and to become better the system and organization need at least to get to a certain scale, you need to save in the hours you invested to come out ahead. In many scenarios the cost in developer-months needed up front is just as important as other factors in evaluating the best architecture. E.g. a scrappy startup simply should not do it IMO. Corporations..... perhaps;but I have seen it gone badly. (I guess it is just not "done right" then? See above.)
  - dagss 4y ago
    PS I think microservices excel in making people FEEL productive (doing work that is not directly benefiting the company). I have personal experience with the same product built twice, once as a monolith by a small team that worked really well and once as lots of services. The featureset and development speed is about the same, but the many-services requires 10x as many people. However by splitting into many services everyone feels productive doing auxiliary and incidental work. Only those of us who worked on the first system are able to see that the total output of the company is the same but 10x as expensive.