5 ms·

Wouldn't you still have to do the iterative thing to avoid temporary outages during deployments? Or do you try to synchronize all deployments?

sparsely 5y ago
I don't think synchronized deployments is really possible - you'd have to either still do the iterative thing, or possibly have some versioning system in place
- bluGill 5y ago
  It is possible for trivial cases. What I do in my basement for example - though even there I have come to prefer keeping things intentionally unsynchronized: it ensures that after updates I have some system that still works.
bpicolo 5y ago
It takes the guesswork out of library migrations. API migrations still need forwards/backwards compat hygiene, unless you blue/green your entire infrastructure to compatible versions, which is possible but not necessarily practical
rohitpaulk 5y ago
If the change is in a shared library (and not a service shared over the network), it's fine to change all usages at once. Deploying a service wouldn't affect the others. If the change affects the public interface of a service, then there's no option but to make your changes backward-compatible.
- tantalor 5y ago
  > no option but to... Not necessarily; you can accept downtime/breakage instead. That is always an option!
  - bluGill 5y ago
    You must not work on safety critical code where downtime/breakage mean people die.
    - ralmeida 5y ago
      Most people don't, to be fair. The case where zero-downtime strategies are adopted for (at least) a questionable ROI is far more common.
    - closeparen 5y ago
      I hope you're not doing anything "safety critical" with general purpose computers, let alone microservices.
      - bluGill 5y ago
        Well the arm CPUs we use are in general purpose computers as well. Though you are correct, we don't follow the same practices as general purpose computers.
    - marcosdumay 5y ago
      I hope nobody's life depends on the uptime of a web-based distributed system. But, well, I also expect nobody's life to depend on it. There would be a short window between people getting into that situation and they not have any life to depend on anything.
    - tantalor 5y ago
      I was thinking more like bank/govt websites that go down for "scheduled maintenance".
goodpoint 5y ago
Most likely bla3 is referring to statically linked applications. This is the big downside of monorepos: they strongly encourage tight coupling and poor modularity.
- tantalor 5y ago
  > they strongly encourage tight coupling and poor modularity No, that's not true. Why would you say that?
  - bluGill 5y ago
    Because they do nothing to make it hard to add a coupling or break modularity. You should of course use good discipline to ensure that doesn't happen. Compared to mutli-repo it is a lot easier to violate coupling and modularity and not be detected. Anyone who is using a monorepo needs to be aware of this downside and deal with it. There are other downsides of multi-repo, and those dealing with them need to be aware of those and mitigate them. There is no perfect answer, just compromises.
  - majormajor 5y ago
    They make it easy, and then human nature and dev laziness does the rest. If you can reach across the repo and import any random piece of code, you end up with devs doing just that. It's a huge huge pain to try to untangle later. That's why tools like Bazel are strict about visibility and put more friction and explicitness on those sorts of things. But this tends to not be the first thing at the top of people's minds when starting a new project... so in the monorepos I've worked on, it's never been noticed until it's too late to easily fix.
sam0x17 5y ago
If you design with a "no deprecations" mentality and deploy backend before frontend, in _most cases_ this isn't an issue -- the frontend code that needs the new table or column or endpoint that doesn't exist yet won't run until those things are deployed, and the new backend endpoints will be fully backwards compatible with the old frontend, so no issues. You don't even need to be that dogmatic to make this work either -- simply stipulating backwards compatibility between the two previous deploys should be sufficient. The better version of this is simply versioning your backend and frontend but I've never been that fancy.
fwip 5y ago
Depends on how you deploy and your scaling strategy. e.g: If your smallest deployable unit is a Kubernetes pod, and all your affected applications live in that pod, you can treat it as a private change.

sparsely 5y ago

I don't think synchronized deployments is really possible - you'd have to either still do the iterative thing, or possibly have some versioning system in place

bluGill 5y ago
It is possible for trivial cases. What I do in my basement for example - though even there I have come to prefer keeping things intentionally unsynchronized: it ensures that after updates I have some system that still works.

bpicolo 5y ago

It takes the guesswork out of library migrations. API migrations still need forwards/backwards compat hygiene, unless you blue/green your entire infrastructure to compatible versions, which is possible but not necessarily practical

rohitpaulk 5y ago

If the change is in a shared library (and not a service shared over the network), it's fine to change all usages at once. Deploying a service wouldn't affect the others. If the change affects the public interface of a service, then there's no option but to make your changes backward-compatible.

tantalor 5y ago
> no option but to... Not necessarily; you can accept downtime/breakage instead. That is always an option!
- bluGill 5y ago
  You must not work on safety critical code where downtime/breakage mean people die.
  - ralmeida 5y ago
    Most people don't, to be fair. The case where zero-downtime strategies are adopted for (at least) a questionable ROI is far more common.
  - closeparen 5y ago
    I hope you're not doing anything "safety critical" with general purpose computers, let alone microservices.
    - bluGill 5y ago
      Well the arm CPUs we use are in general purpose computers as well. Though you are correct, we don't follow the same practices as general purpose computers.
  - marcosdumay 5y ago
    I hope nobody's life depends on the uptime of a web-based distributed system. But, well, I also expect nobody's life to depend on it. There would be a short window between people getting into that situation and they not have any life to depend on anything.
  - tantalor 5y ago
    I was thinking more like bank/govt websites that go down for "scheduled maintenance".

goodpoint 5y ago

Most likely bla3 is referring to statically linked applications. This is the big downside of monorepos: they strongly encourage tight coupling and poor modularity.

tantalor 5y ago
> they strongly encourage tight coupling and poor modularity No, that's not true. Why would you say that?
- bluGill 5y ago
  Because they do nothing to make it hard to add a coupling or break modularity. You should of course use good discipline to ensure that doesn't happen. Compared to mutli-repo it is a lot easier to violate coupling and modularity and not be detected. Anyone who is using a monorepo needs to be aware of this downside and deal with it. There are other downsides of multi-repo, and those dealing with them need to be aware of those and mitigate them. There is no perfect answer, just compromises.
- majormajor 5y ago
  They make it easy, and then human nature and dev laziness does the rest. If you can reach across the repo and import any random piece of code, you end up with devs doing just that. It's a huge huge pain to try to untangle later. That's why tools like Bazel are strict about visibility and put more friction and explicitness on those sorts of things. But this tends to not be the first thing at the top of people's minds when starting a new project... so in the monorepos I've worked on, it's never been noticed until it's too late to easily fix.

sam0x17 5y ago

If you design with a "no deprecations" mentality and deploy backend before frontend, in _most cases_ this isn't an issue -- the frontend code that needs the new table or column or endpoint that doesn't exist yet won't run until those things are deployed, and the new backend endpoints will be fully backwards compatible with the old frontend, so no issues. You don't even need to be that dogmatic to make this work either -- simply stipulating backwards compatibility between the two previous deploys should be sufficient. The better version of this is simply versioning your backend and frontend but I've never been that fancy.

fwip 5y ago

Depends on how you deploy and your scaling strategy. e.g: If your smallest deployable unit is a Kubernetes pod, and all your affected applications live in that pod, you can treat it as a private change.