3 ms·

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 detail

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.

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.