7 ms·

The big advantage of microservices is organizational not technical. You can hire teams and tell them that they are responsible for an API that receives specific

The big advantage of microservices is organizational not technical. You can hire teams and tell them that they are responsible for an API that receives specific data and should return specific data. These teams can operate independently. You don't have to force all the teams to use the same language or dev process. That could be good or bad depending on the circumstances, but at least you have the option with microservices.

quickthrower2 4y ago
Do you need services though to achieve this? How about libraries?
- adra 4y ago
  Libraries are great, but you can't deploy new versions of library without needing to step on toes. If your dev teams are just "shove this at ops" and done, then it may not make a difference, but if you need to be responsible for the code running in the real world, just library segregation doesn't cut it.
  - quickthrower2 4y ago
    I can’t get my head around that though. I agree to split into services where “you’r have to do that anyway”. But adding services where part A of the monolith needs to use part B where a library would do the job seems odd. If you are trying to solve a specific scaling issue, then sure, but this is rare.
  - magicalhippo 4y ago
    I'm being dense it seems, because I don't see what microservices brings to this. What's the fundamental difference in this regard between shipping an executable with a bunch of dynamic libraries, and deploying a bunch of microservices?
    - olalonde 4y ago
      It's mostly about data. Each micro services is responsible for their own data, data migrations, data store, etc. Think of it as a mini web app with an API. In theory, you could use a library in that way but I have never seen such use in practice. You would also run into the problem of having to always keep all library users on the latest version as to avoid having two versions which expect different database schemas. It also largely forces you to stick to a single programming language.
      - quickthrower2 4y ago
        Conversely though, if you can make do with a single data store and data layer (orm or just simple queries) the libraries can use that. The schema and generated classes could be a shared common library that different teams can work on (maybe with some architecture obersight) Or if using schema-less each library “knows” it’s own json formats Then you get nice things like atomic transactions across multiple “services”. You also have no network concerns. You can pull out microservices for things that need special attention. Such as a spikey-load service that might need to run as a lambda. Version management is a solved problem. Use your languages package manager and semantic versions. I concede you need to stick to one language. Ish. You have C FFIs. A .NET app could reference a dll written in C++ or Rust. But yeah not as flexible as services. Although there are inbetween things like RPC.
ironmagma 4y ago
All those things are quite achievable with a modular monolith. The API is the module.
- windows_sucks 4y ago
  yeah but deployments and language choice are no longer a single teams choice now. microservices really do allow for a "we did our job" development
  - ironmagma 4y ago
    Language is always brought in as a "pro" for microservices. I would call it a "con." Fragmentation across languages can be a big problem if your business logic is complicated; suddenly you have to link against code written in another language, or worse, rewrite it.
  - rco8786 4y ago
    Kind of unrelated unless the language chosen is the reason a team can’t do their work?
  - eddd-ddde 4y ago
    You can still 100% just use whatever language and build a library, instead of sending json or binary data through network calls, you just use FFI.
cdavid 4y ago
That's the theory. What I've observed is that that companies who cannot achieve modularity w/ monolith are often the same ones incapable to achieve modularity w/ MS anyway. So now you have in practice is a distributed monolith, with brittle, ad-hoc dependencies between services. A symptom is that most features require touching many MS.
giancarlostoro 4y ago
Yes, and in some cases, maybe you really need some crucial python library but the rest of your systems are in Go, and maybe you discovered a new library that does exactly what you need, in a third language in the most efficient way possible, you can embed a microservice into the mix. I think though, it is usually best to hire for one common language as much as possible, this way your team can jump across projects if the need arises.
Lio 4y ago
The downside to that is that if you get the factoring of the app wrong you now have to refactor across disparate codebases separated by network calls. It's much easier to start with a monolith and refactor it into microservices later than it is to refactor microservices written in different languages by different teams into a single codebase.
devoutsalsa 4y ago
But they can't work independently. Unless your micro service operates in a vacuum, it's sending generating messages that will be consumed by other services. All of that communication requires a lot of frikkin' work. You need to maintain API documentation, update client libraries, remove garbage messages from the queue, coordinate deployment schedules, and all sorts of other crap. If you have FAANG level resources, maybe you can mock out & automate everything to the point where you don't need to worry nearly as much, but that's a monolithic effort (pun intended).
fleddr 4y ago
The big disadvantage of microservices is also organizational.
whodidntante 4y ago
What about basic business functionality, for example, a function to create a site URL, which can be quite complex, and which would be very time consuming and complex and a maintenance nightmare if implemented in multiple languages. You could, of course, create this as a service. And then make possibly hundreds of calls to this service to generate a single web page. Or, you can provide a library that does this, and the calls are cheap, reliable, and predictable. Of course, if it is a service, the caller would locally the cache the information needed to make all the calls, do a batch call to the service, and then backfill in all the links. This then precludes generating and sending the page as you go, and creates the possibility for an explosion in complexity if a simple change in requirements that causes the arguments for the URL generation to be dependent on another service/library call. Not everything should be a service call.
Barrin92 4y ago
This isn't a good idea organizationally though. What matters is the performance of the system, not the performance of its parts, this is kind of a systems 101 lesson. If you build a car and send each team off to find the best parts in isolation and screw them together, you don't have the best car, you likely have something that doesn't even drive, because the parts don't fit. The performance of a system is in the interaction of its parts, not the sum of the performance of its parts taken individually. Teams can never operate independently because it only ever makes sense to improve a part if it improves the functioning of the entire system. The whole problem with the microservices approach it that it optimizes the wrong thing.
- mpyne 4y ago
  > This isn't a good idea organizationally though. It's absolutely necessary for very large organizations though. The alternative of trying to centrally plan the IT operations of an organization of, say, 500,000, gets to be quickly intractable. Groups try to do it with frameworks like SAFe and while that may help a little bit, in the end you need to treat different parts of the organization as individual silos that are able to control and execute on their specific mission set within the wider org. Otherwise the complexity of the problem set they're dealing with makes it impossible to do anything without breaking other systems or teams.
rco8786 4y ago
Yikes I would never consider introducing a network layer as an organizational tool. Teams that do this are vastly underestimating the latency and general complexity of distributed systems.

quickthrower2 4y ago

Do you need services though to achieve this? How about libraries?

adra 4y ago
Libraries are great, but you can't deploy new versions of library without needing to step on toes. If your dev teams are just "shove this at ops" and done, then it may not make a difference, but if you need to be responsible for the code running in the real world, just library segregation doesn't cut it.
- quickthrower2 4y ago
  I can’t get my head around that though. I agree to split into services where “you’r have to do that anyway”. But adding services where part A of the monolith needs to use part B where a library would do the job seems odd. If you are trying to solve a specific scaling issue, then sure, but this is rare.
- magicalhippo 4y ago
  I'm being dense it seems, because I don't see what microservices brings to this. What's the fundamental difference in this regard between shipping an executable with a bunch of dynamic libraries, and deploying a bunch of microservices?
  - olalonde 4y ago
    It's mostly about data. Each micro services is responsible for their own data, data migrations, data store, etc. Think of it as a mini web app with an API. In theory, you could use a library in that way but I have never seen such use in practice. You would also run into the problem of having to always keep all library users on the latest version as to avoid having two versions which expect different database schemas. It also largely forces you to stick to a single programming language.
    - quickthrower2 4y ago
      Conversely though, if you can make do with a single data store and data layer (orm or just simple queries) the libraries can use that. The schema and generated classes could be a shared common library that different teams can work on (maybe with some architecture obersight) Or if using schema-less each library “knows” it’s own json formats Then you get nice things like atomic transactions across multiple “services”. You also have no network concerns. You can pull out microservices for things that need special attention. Such as a spikey-load service that might need to run as a lambda. Version management is a solved problem. Use your languages package manager and semantic versions. I concede you need to stick to one language. Ish. You have C FFIs. A .NET app could reference a dll written in C++ or Rust. But yeah not as flexible as services. Although there are inbetween things like RPC.

ironmagma 4y ago

All those things are quite achievable with a modular monolith. The API is the module.

windows_sucks 4y ago
yeah but deployments and language choice are no longer a single teams choice now. microservices really do allow for a "we did our job" development
- ironmagma 4y ago
  Language is always brought in as a "pro" for microservices. I would call it a "con." Fragmentation across languages can be a big problem if your business logic is complicated; suddenly you have to link against code written in another language, or worse, rewrite it.
- rco8786 4y ago
  Kind of unrelated unless the language chosen is the reason a team can’t do their work?
- eddd-ddde 4y ago
  You can still 100% just use whatever language and build a library, instead of sending json or binary data through network calls, you just use FFI.

cdavid 4y ago

That's the theory. What I've observed is that that companies who cannot achieve modularity w/ monolith are often the same ones incapable to achieve modularity w/ MS anyway. So now you have in practice is a distributed monolith, with brittle, ad-hoc dependencies between services. A symptom is that most features require touching many MS.

giancarlostoro 4y ago

Yes, and in some cases, maybe you really need some crucial python library but the rest of your systems are in Go, and maybe you discovered a new library that does exactly what you need, in a third language in the most efficient way possible, you can embed a microservice into the mix. I think though, it is usually best to hire for one common language as much as possible, this way your team can jump across projects if the need arises.

Lio 4y ago

The downside to that is that if you get the factoring of the app wrong you now have to refactor across disparate codebases separated by network calls. It's much easier to start with a monolith and refactor it into microservices later than it is to refactor microservices written in different languages by different teams into a single codebase.

devoutsalsa 4y ago

But they can't work independently. Unless your micro service operates in a vacuum, it's sending generating messages that will be consumed by other services. All of that communication requires a lot of frikkin' work. You need to maintain API documentation, update client libraries, remove garbage messages from the queue, coordinate deployment schedules, and all sorts of other crap. If you have FAANG level resources, maybe you can mock out & automate everything to the point where you don't need to worry nearly as much, but that's a monolithic effort (pun intended).

fleddr 4y ago

The big disadvantage of microservices is also organizational.

whodidntante 4y ago

What about basic business functionality, for example, a function to create a site URL, which can be quite complex, and which would be very time consuming and complex and a maintenance nightmare if implemented in multiple languages. You could, of course, create this as a service. And then make possibly hundreds of calls to this service to generate a single web page. Or, you can provide a library that does this, and the calls are cheap, reliable, and predictable. Of course, if it is a service, the caller would locally the cache the information needed to make all the calls, do a batch call to the service, and then backfill in all the links. This then precludes generating and sending the page as you go, and creates the possibility for an explosion in complexity if a simple change in requirements that causes the arguments for the URL generation to be dependent on another service/library call. Not everything should be a service call.

Barrin92 4y ago

This isn't a good idea organizationally though. What matters is the performance of the system, not the performance of its parts, this is kind of a systems 101 lesson. If you build a car and send each team off to find the best parts in isolation and screw them together, you don't have the best car, you likely have something that doesn't even drive, because the parts don't fit. The performance of a system is in the interaction of its parts, not the sum of the performance of its parts taken individually. Teams can never operate independently because it only ever makes sense to improve a part if it improves the functioning of the entire system. The whole problem with the microservices approach it that it optimizes the wrong thing.

mpyne 4y ago
> This isn't a good idea organizationally though. It's absolutely necessary for very large organizations though. The alternative of trying to centrally plan the IT operations of an organization of, say, 500,000, gets to be quickly intractable. Groups try to do it with frameworks like SAFe and while that may help a little bit, in the end you need to treat different parts of the organization as individual silos that are able to control and execute on their specific mission set within the wider org. Otherwise the complexity of the problem set they're dealing with makes it impossible to do anything without breaking other systems or teams.

rco8786 4y ago

Yikes I would never consider introducing a network layer as an organizational tool. Teams that do this are vastly underestimating the latency and general complexity of distributed systems.