7 ms·

I think people think about microservice because they themselves failed to achieve modular monothlic.

deleted 4y ago
[deleted]
gitfan86 4y ago
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.
BlargMcLarg 4y ago
The main reason I hear when poking more is "so we're not dependent on other teams to release our module". For some reason, I feel this is somewhat of a scapegoat and fails in practice. But I don't have enough experience.
- NoGravitas 4y ago
  In any case, that sounds like an organizational problem, not a technical one.
  - iampims 4y ago
    Microservices are one way to help with scaling the organization, not necessarily the product/code.
giancarlostoro 4y ago
I think it can have its benefits but I don't think it should be your entire application. I know some people swear by it, and if that's what works for them and keeps them profitable, you know what? Go for it. I think serverless is fantastic on the other hand[1]. I had a web application where I was parsing shapefiles to then import them into SQL Server. These files could be massive and take longer to process than they took to upload. As a result I figured that it might make more sense to create a serverless function in Azure to parse them once they were uploaded to blob storage. This was very easy to implement and transparent. If you are using something like Azure and want efficient ways to process your data without doing it all in your monolithic application and blocking your users, or creating a thread in the background which makes me a little uncomfortable, then serverless is a godsend. I think Microservice architecture if I had to pin where it might make sense would be for APIs. I would then emphasize on versioning each microservice API. If you do a microservice architecture for APIs you can update parts of your API without taking the whole beast down (unless you use something like Erlang or slots in the case of Azure Web Apps, where it forwards new requests to new slot). I think this might be a reasonable use case for microservices. For a normal website though, I think monolithic with some serverless helper functions (if needed) is probably good enough otherwise. [1] Note: Let's not confuse microservices for serverless, because it's not necessarily the same thing, although some people use serverless to achieve the microservice architecture, serverless functions can do so much more!
jfabre 4y ago
It always baffled me to hear:" Oh we're gonna do microservices, because our monolith is a total mess and we're very unproductive". If you can't organize a monolith, what makes you think you will be able to organize microservices which are vastly more complicated to work with. How about you learn as a company the proper skills and habits to achieve logical modularity within a single process before you try doing that with multiple processes.
- jfabre 4y ago
  And I would also add: The reason your monolith is a mess is because your organization has low standards on code quality and doesn't value it. It is not willing to invest in it, and probably your department didn't acquire the skills and habits to produce clean code in cheap manner. The developers who are used to good code usually leave you out of frustration. No one likes to be unproductive, especially productive people.
  - eddd-ddde 4y ago
    I hate how much I can relate to this.
  - atom_arranger 4y ago
    I wonder if part of why microseconds work for some companies is the hype helps justify the work to management. > We need to convert to microservices. Sounds like a cool shiny new approach enabling better scaling and organization. > We need to refactor this mess. Sounds like complaining, why is it a mess anyways? These two things may essentially be doing the same thing, organizing/breaking up the code logically, one just might sound more appealing to management.
- gitfan86 4y ago
  "productive" means shipping code to these people. They are trying to minimize how often someone says "we are blocked on deploying that code"
  - jfabre 4y ago
dehrmann 4y ago
Without diligence, monoliths tent to turn into dependency spaghetti. Microservices can force you to spend more time structuring things.
- gedy 4y ago
  Especially in Rails apps where almost any bit of code can modify anything else.
manfre 4y ago
The monolithic vs microservices arguments are more about where to arbitrarily draw separation lines in the deployed architecture. Someone with a monolith that embeds the database could claim those who use MySQL failed to achieve modular monolithic.

deleted 4y ago

[deleted]

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.

BlargMcLarg 4y ago

The main reason I hear when poking more is "so we're not dependent on other teams to release our module". For some reason, I feel this is somewhat of a scapegoat and fails in practice. But I don't have enough experience.

NoGravitas 4y ago
In any case, that sounds like an organizational problem, not a technical one.
- iampims 4y ago
  Microservices are one way to help with scaling the organization, not necessarily the product/code.

giancarlostoro 4y ago

I think it can have its benefits but I don't think it should be your entire application. I know some people swear by it, and if that's what works for them and keeps them profitable, you know what? Go for it. I think serverless is fantastic on the other hand[1]. I had a web application where I was parsing shapefiles to then import them into SQL Server. These files could be massive and take longer to process than they took to upload. As a result I figured that it might make more sense to create a serverless function in Azure to parse them once they were uploaded to blob storage. This was very easy to implement and transparent. If you are using something like Azure and want efficient ways to process your data without doing it all in your monolithic application and blocking your users, or creating a thread in the background which makes me a little uncomfortable, then serverless is a godsend. I think Microservice architecture if I had to pin where it might make sense would be for APIs. I would then emphasize on versioning each microservice API. If you do a microservice architecture for APIs you can update parts of your API without taking the whole beast down (unless you use something like Erlang or slots in the case of Azure Web Apps, where it forwards new requests to new slot). I think this might be a reasonable use case for microservices. For a normal website though, I think monolithic with some serverless helper functions (if needed) is probably good enough otherwise. [1] Note: Let's not confuse microservices for serverless, because it's not necessarily the same thing, although some people use serverless to achieve the microservice architecture, serverless functions can do so much more!

jfabre 4y ago

It always baffled me to hear:" Oh we're gonna do microservices, because our monolith is a total mess and we're very unproductive". If you can't organize a monolith, what makes you think you will be able to organize microservices which are vastly more complicated to work with. How about you learn as a company the proper skills and habits to achieve logical modularity within a single process before you try doing that with multiple processes.

jfabre 4y ago
And I would also add: The reason your monolith is a mess is because your organization has low standards on code quality and doesn't value it. It is not willing to invest in it, and probably your department didn't acquire the skills and habits to produce clean code in cheap manner. The developers who are used to good code usually leave you out of frustration. No one likes to be unproductive, especially productive people.
- eddd-ddde 4y ago
  I hate how much I can relate to this.
- atom_arranger 4y ago
  I wonder if part of why microseconds work for some companies is the hype helps justify the work to management. > We need to convert to microservices. Sounds like a cool shiny new approach enabling better scaling and organization. > We need to refactor this mess. Sounds like complaining, why is it a mess anyways? These two things may essentially be doing the same thing, organizing/breaking up the code logically, one just might sound more appealing to management.
gitfan86 4y ago
"productive" means shipping code to these people. They are trying to minimize how often someone says "we are blocked on deploying that code"
- jfabre 4y ago

dehrmann 4y ago

Without diligence, monoliths tent to turn into dependency spaghetti. Microservices can force you to spend more time structuring things.

gedy 4y ago
Especially in Rails apps where almost any bit of code can modify anything else.

manfre 4y ago

The monolithic vs microservices arguments are more about where to arbitrarily draw separation lines in the deployed architecture. Someone with a monolith that embeds the database could claim those who use MySQL failed to achieve modular monolithic.