3 ms·

> Your problems is how you're failing to preserve API contracts, and instead you go to the extreme of insisting in breaking all contracts at once. Preserving c

> Your problems is how you're failing to preserve API contracts, and instead you go to the extreme of insisting in breaking all contracts at once. Preserving contracts has a significant cost. Why would you try to preserve contracts if you're in fact in control of all producers and consumers?

chipdart 2y ago
> Preserving contracts has a significant cost. Not really. You just need to break out a new version when you put out a breaking change. This can mean anything between duplicating the code that implements your interface to then apply a change and checking a version flag when invoking an operation to determine which version to run. Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? > Why would you try to preserve contracts if you're in fact in control of all producers and consumers? Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. Also, as others have pointed out, storing code in the same repository gives you no assurance that all your services will be deployed at the same exact moment in time. Consider for example multi-region deployments, or even deployments to multiple availability zones. Those aren't atomic. Why does anyone believe that storing all code in the same repository is enough to make these operations atomic?
- friendzis 2y ago
  > Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? Not isolated to this particular issue. People really like to pretend that problems are much simpler than they actually are and that inherent complexity is just some edge cases to be ironed out.
  - The_Colonel 2y ago
    What is an edge case, what is an accepted outage window, failure rate etc. depends on the specific case. On one end you have Netflix-like architectures, on the other end you have intranet apps used twice monthly by two users. There's a wide range of needs and expectations in between.
- The_Colonel 2y ago
  > Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? Yes, but my time is limited and there's the opportunity cost. It also means more code, more tests for future. More code, ceteris paribus, represents more maintenance costs for the future. > Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. I can prevent things from breaking in multi-repo, multi-versioned architecture, it's just more expensive to do so.
- lolinder 2y ago
  > Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? No one is saying that. But there are lots of types of shared code that can be updated atomically, so why not update them atomically? And there's nothing inherent in being a monorepo that prevents you from being careful about the non-atomic updates. It's really easy to accidentally deploy multiple repos in a way that gets the deployment order wrong. You have to be careful with non-atomic deployments whatever type of repo structure you have.

chipdart 2y ago

> Preserving contracts has a significant cost. Not really. You just need to break out a new version when you put out a breaking change. This can mean anything between duplicating the code that implements your interface to then apply a change and checking a version flag when invoking an operation to determine which version to run. Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? > Why would you try to preserve contracts if you're in fact in control of all producers and consumers? Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. Also, as others have pointed out, storing code in the same repository gives you no assurance that all your services will be deployed at the same exact moment in time. Consider for example multi-region deployments, or even deployments to multiple availability zones. Those aren't atomic. Why does anyone believe that storing all code in the same repository is enough to make these operations atomic?

friendzis 2y ago
> Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? Not isolated to this particular issue. People really like to pretend that problems are much simpler than they actually are and that inherent complexity is just some edge cases to be ironed out.
- The_Colonel 2y ago
  What is an edge case, what is an accepted outage window, failure rate etc. depends on the specific case. On one end you have Netflix-like architectures, on the other end you have intranet apps used twice monthly by two users. There's a wide range of needs and expectations in between.
The_Colonel 2y ago
> Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? Yes, but my time is limited and there's the opportunity cost. It also means more code, more tests for future. More code, ceteris paribus, represents more maintenance costs for the future. > Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. I can prevent things from breaking in multi-repo, multi-versioned architecture, it's just more expensive to do so.
lolinder 2y ago
> Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? No one is saying that. But there are lots of types of shared code that can be updated atomically, so why not update them atomically? And there's nothing inherent in being a monorepo that prevents you from being careful about the non-atomic updates. It's really easy to accidentally deploy multiple repos in a way that gets the deployment order wrong. You have to be careful with non-atomic deployments whatever type of repo structure you have.