4 ms·

The diagram of the service in the blog post is absurd. Anyone who designs a microservice environment like this should be fired. The interdependencies between s

The diagram of the service in the blog post is absurd. Anyone who designs a microservice environment like this should be fired. The interdependencies between services in the picture make the entire system fragile and everything will fail if a single service goes down. A real production microservice environment should be designed so that interdependencies are limited and system wide failures won't occur if a service or two go down. Once you limit the interdependencies then the combinatorial explosion doesn't exist anymore. You might have some services that have a wide range of version used by clients, but you don't have the interdependency that complicates things. Then, versioning isn't such a big deal.

rapsey 7y ago
Unfortunately however most developers (even senior ones) follow fads without proper homework and planning.
danielovichdk 7y ago
You cannot build software without dependencies. The dependency pattern around microservices is either a contract on a queue/stream/topic or a version of an API from another depened service. Don't care how many times you tell me that services should be interdepended and bla bla bla... In the end a service has dependencies and those dependencies must then have a versioning strategy so humans are not in doubt. Versioning a microservice is no different than versioning a linked library or a Rest API. Documentation is key. Tell people what versions break.
- jennyyang 7y ago
  You didn't understand what I wrote. I said that having interdependent services the way the diagram was drawn leads to an extremely fragile system. If one service goes down, they all go down. It's not a realistic environment or it's a very poorly designed one. If you simplify the diagram to one that is more realistic, with more 1:1 or N:1 relationships, then the combinatorial factor decreases, and then there is no article to write about.
  - danielovichdk 7y ago
    How does versioning differ based on a 1:1 or a 1:N, or a N:N? It doesn't. No matter how few or many dependencies you have, when they are updated, the dependent system must either update or not update. There is nothing new in regards to versioning of dependencies. It has always been hard to do, and with microservices the versioning story has not all of a sudden improved. What people that are new to versioning, seen from a somewhat autonomous systems perspective, this is something you must have a strategy for.
- thedance 7y ago
  That's ridiculous. Just don't break anything, ever. If you need a service to behave differently, you give it a different name and roll it out and wait for traffic on the original to fall to zero and then you wait a bit longer and them you turn it off and delete it. People who advocate for versioned services just do. not. get it.
  - dikei 7y ago
    Ehh, what you just described is often how service versioning works: launch a v2 service with the v1 still active, keep them running concurrently for a while, then turn off the v1 when it's no longer used. You can distinguish the versions by using different endpoints, version fields, version headers, etc.. But that's just implementation details.
- taleodor 7y ago
  Thank you, I very much second this. Another way of putting this - if we need to ensure identicity between any 2 environments - we have to care about fine details and exact versions. Otherwise, we're back at "works on my machine" mentality. And yes - trying to make microservices independent from each other is also a form of pruning and sometimes works well to a point, but also requires good tooling to be done right.
  - jennyyang 7y ago
    My point is your article is based on a fake premise, or a poorly designed premise. Your architecture that creates this combinatorial explosion is only because your supposed microservice architecture is poorly designed. If you look at a real microservice architecture, it won't be nearly as complicated and it's not as big of a deal to version.
    - taleodor 7y ago
      > My point is your article is based on a fake premise, or a poorly designed premise. That's a strong statement which you should at least try to provide counter-example to support - just saying "you design it wrong" is not enough. I've seen this kind of problem irl left-right-and-center - so I take it there is an issue, and it's not happening because "everybody doing it wrong". > If one service goes down, they all go down I believe you don't understand the diagram. Lines are not dependencies, but a way to connect components of different versions into single product. (I.e., you pick either v1 or v2 of each component, and it becomes single product along the lines - it doesn't necessarily mean there is hard dependency). To my point, I treat whole architecture as a product. I don't necessarily speak about dependencies. Instead, I'm taking general view of this as a math problem - first of all, I establish search space - that is number of available versions to the power of number of microservices. Then I very much support and want to discuss various ways to reduce this search space via pruning - and what you're talking about is just one of the options how to prune it (by reducing dependencies). But as others pointed (rephrasing in my words), you can apply a greedy algorithm to NP-problem, but first of all understand what the real problem you're dealing with is and second of all realize that your algorithm is greedy - meaning it may have flaws in the edge cases and it's better to be prepared to those. In your specific case I claim that you can't be completely sure that you actually don't have any interdependency between components - I believe it would be impossible to prove for any system. And again I saw really hard bugs irl coming from those assumptions. Recent example (this is not about microservices - but pls try to solve this case): https://stackoverflow.com/questions/60486853/aws-ecr-uploading-docker-image-give-below-error https://stackoverflow.com/questions/60486853/aws-ecr-uploadi... - Tools in question must be completely independent, but somehow they are not. So assuming something is completely independent is frequently dangerous.

rapsey 7y ago

Unfortunately however most developers (even senior ones) follow fads without proper homework and planning.

danielovichdk 7y ago

You cannot build software without dependencies. The dependency pattern around microservices is either a contract on a queue/stream/topic or a version of an API from another depened service. Don't care how many times you tell me that services should be interdepended and bla bla bla... In the end a service has dependencies and those dependencies must then have a versioning strategy so humans are not in doubt. Versioning a microservice is no different than versioning a linked library or a Rest API. Documentation is key. Tell people what versions break.

jennyyang 7y ago
You didn't understand what I wrote. I said that having interdependent services the way the diagram was drawn leads to an extremely fragile system. If one service goes down, they all go down. It's not a realistic environment or it's a very poorly designed one. If you simplify the diagram to one that is more realistic, with more 1:1 or N:1 relationships, then the combinatorial factor decreases, and then there is no article to write about.
- danielovichdk 7y ago
  How does versioning differ based on a 1:1 or a 1:N, or a N:N? It doesn't. No matter how few or many dependencies you have, when they are updated, the dependent system must either update or not update. There is nothing new in regards to versioning of dependencies. It has always been hard to do, and with microservices the versioning story has not all of a sudden improved. What people that are new to versioning, seen from a somewhat autonomous systems perspective, this is something you must have a strategy for.
thedance 7y ago
That's ridiculous. Just don't break anything, ever. If you need a service to behave differently, you give it a different name and roll it out and wait for traffic on the original to fall to zero and then you wait a bit longer and them you turn it off and delete it. People who advocate for versioned services just do. not. get it.
- dikei 7y ago
  Ehh, what you just described is often how service versioning works: launch a v2 service with the v1 still active, keep them running concurrently for a while, then turn off the v1 when it's no longer used. You can distinguish the versions by using different endpoints, version fields, version headers, etc.. But that's just implementation details.
taleodor 7y ago
Thank you, I very much second this. Another way of putting this - if we need to ensure identicity between any 2 environments - we have to care about fine details and exact versions. Otherwise, we're back at "works on my machine" mentality. And yes - trying to make microservices independent from each other is also a form of pruning and sometimes works well to a point, but also requires good tooling to be done right.
- jennyyang 7y ago
  My point is your article is based on a fake premise, or a poorly designed premise. Your architecture that creates this combinatorial explosion is only because your supposed microservice architecture is poorly designed. If you look at a real microservice architecture, it won't be nearly as complicated and it's not as big of a deal to version.
  - taleodor 7y ago
    > My point is your article is based on a fake premise, or a poorly designed premise. That's a strong statement which you should at least try to provide counter-example to support - just saying "you design it wrong" is not enough. I've seen this kind of problem irl left-right-and-center - so I take it there is an issue, and it's not happening because "everybody doing it wrong". > If one service goes down, they all go down I believe you don't understand the diagram. Lines are not dependencies, but a way to connect components of different versions into single product. (I.e., you pick either v1 or v2 of each component, and it becomes single product along the lines - it doesn't necessarily mean there is hard dependency). To my point, I treat whole architecture as a product. I don't necessarily speak about dependencies. Instead, I'm taking general view of this as a math problem - first of all, I establish search space - that is number of available versions to the power of number of microservices. Then I very much support and want to discuss various ways to reduce this search space via pruning - and what you're talking about is just one of the options how to prune it (by reducing dependencies). But as others pointed (rephrasing in my words), you can apply a greedy algorithm to NP-problem, but first of all understand what the real problem you're dealing with is and second of all realize that your algorithm is greedy - meaning it may have flaws in the edge cases and it's better to be prepared to those. In your specific case I claim that you can't be completely sure that you actually don't have any interdependency between components - I believe it would be impossible to prove for any system. And again I saw really hard bugs irl coming from those assumptions. Recent example (this is not about microservices - but pls try to solve this case): https://stackoverflow.com/questions/60486853/aws-ecr-uploading-docker-image-give-below-error https://stackoverflow.com/questions/60486853/aws-ecr-uploadi... - Tools in question must be completely independent, but somehow they are not. So assuming something is completely independent is frequently dangerous.