3 ms·

> First put all your services in a monorepo have it all build as one under CI. That’s a static check across the entire system. That helps but is insufficient,

> First put all your services in a monorepo have it all build as one under CI. That’s a static check across the entire system. That helps but is insufficient, since the set of concurrently deployed artifact versions can be different than any set of artifact versions seen by CI -- most obviously when two versions of the same artifact are actively deployed at the same time. It also appears to rule out the possibility of ever integrating with other systems (e.g., now you need to build your own Stripe-equivalent in a subdir of your monorepo). > Second don’t use databases. So you want to reimplement your own PostgreSQL-equivalent in another monorepo subdir too? I don't understand how opting not to use modern RDBMSes is practical. IIUC you're proposing implementing a DB using compiled queries that use the same types as the consuming application -- I can see the type-safety benefits, but this immediately restricts consumers to the same language or environment (e.g., JVM) that the DB was implemented in.

threethirtytwo 9mo ago
>That helps but is insufficient, since the set of concurrently deployed artifact versions can be different than any set of artifact versions seen by CI Simple, although I only mentioned repos should be mono, I should've also said deployment should be mono as well. I thought that was a given. >So you want to reimplement your own PostgreSQL-equivalent in another monorepo subdir too? I'm too lazy to do this but in general I want an artifact that is built. All sql queries need to be compiled and built and the database runs that artifact. And of course all of this is part of a monorepo that is monodeployed. >I don't understand how opting not to use modern RDBMSes is practical. It's not practical. My point is there's some really stupid obvious flaws we live with because it's the only practical solution.
- blandflakes 9mo ago
  > Simple, although I only mentioned repos should be mono, I should've also said deployment should be mono as well. I thought that was a given. Deploying your service graph as one atomic unit is not a given, and not necessarily even the best idea - you need to be able to roll back an individual service unless you have very small changes between versions, which means that even if they were rolled out atomically, you still run the risk of mixed versions sets.
  - threethirtytwo 9mo ago
    >Deploying your service graph as one atomic unit is not a given, It's not a given because you didn't make it a given. >and not necessarily even the best idea - you need to be able to roll back an individual service unless you have very small changes between versions, which means that even if they were rolled out atomically, you still run the risk of mixed versions sets. It is the best idea. This should be the standard. And nothing prevents you from rolling back an individual service. You can still do that. And you can still do individual deploys too. But these are just for patch ups. When you roll back an individual service your entire system is no longer in a valid state. It's in an interim state of repair. You need to fix your changes in the monorepo and monodeploy again. A successful monodeploy ensures that the finished deploy is devoid of a common class of errors. Monodeploy should be the gold standard, and individual deploys and roll backs are reserved for emergencies.
    - blandflakes 9mo ago
      > It is the best idea. This should be the standard. And nothing prevents you from rolling back an individual service. You can still do that. And you can still do individual deploys too. But these are just for patch ups. There are a ton of reasons it's not the best idea. This flies in the face of a lot of _better_ ideas. Keeping changesets small so that it's easier to debug when something goes wrong? Blown out of the water by deploying everything at once. Bringing every service up at once is a great way to create the coldest version of your entire product. Requiring a monodeployment turns canarying or A/B testing entire classes of changes into a blocking rollout where any other feature work has to move at the pace of the slowest change. > When you roll back an individual service your entire system is no longer in a valid state. It's in an interim state of repair. The gold standard is that each version of your service can work with each other version of your service, because in The Real World your service will spend time in those states. > Monodeploy should be the gold standard, and individual deploys and roll backs are reserved for emergencies. No, because if it's still possible to mix versions in your services, then a monodeploy doesn't actually solve any issues. I actually am a big fan of fewer services and deploying bigger artifacts, but if you have multiple services, you have to act like you have multiple services.

threethirtytwo 9mo ago

>That helps but is insufficient, since the set of concurrently deployed artifact versions can be different than any set of artifact versions seen by CI Simple, although I only mentioned repos should be mono, I should've also said deployment should be mono as well. I thought that was a given. >So you want to reimplement your own PostgreSQL-equivalent in another monorepo subdir too? I'm too lazy to do this but in general I want an artifact that is built. All sql queries need to be compiled and built and the database runs that artifact. And of course all of this is part of a monorepo that is monodeployed. >I don't understand how opting not to use modern RDBMSes is practical. It's not practical. My point is there's some really stupid obvious flaws we live with because it's the only practical solution.

blandflakes 9mo ago
> Simple, although I only mentioned repos should be mono, I should've also said deployment should be mono as well. I thought that was a given. Deploying your service graph as one atomic unit is not a given, and not necessarily even the best idea - you need to be able to roll back an individual service unless you have very small changes between versions, which means that even if they were rolled out atomically, you still run the risk of mixed versions sets.
- threethirtytwo 9mo ago
  >Deploying your service graph as one atomic unit is not a given, It's not a given because you didn't make it a given. >and not necessarily even the best idea - you need to be able to roll back an individual service unless you have very small changes between versions, which means that even if they were rolled out atomically, you still run the risk of mixed versions sets. It is the best idea. This should be the standard. And nothing prevents you from rolling back an individual service. You can still do that. And you can still do individual deploys too. But these are just for patch ups. When you roll back an individual service your entire system is no longer in a valid state. It's in an interim state of repair. You need to fix your changes in the monorepo and monodeploy again. A successful monodeploy ensures that the finished deploy is devoid of a common class of errors. Monodeploy should be the gold standard, and individual deploys and roll backs are reserved for emergencies.
  - blandflakes 9mo ago
    > It is the best idea. This should be the standard. And nothing prevents you from rolling back an individual service. You can still do that. And you can still do individual deploys too. But these are just for patch ups. There are a ton of reasons it's not the best idea. This flies in the face of a lot of _better_ ideas. Keeping changesets small so that it's easier to debug when something goes wrong? Blown out of the water by deploying everything at once. Bringing every service up at once is a great way to create the coldest version of your entire product. Requiring a monodeployment turns canarying or A/B testing entire classes of changes into a blocking rollout where any other feature work has to move at the pace of the slowest change. > When you roll back an individual service your entire system is no longer in a valid state. It's in an interim state of repair. The gold standard is that each version of your service can work with each other version of your service, because in The Real World your service will spend time in those states. > Monodeploy should be the gold standard, and individual deploys and roll backs are reserved for emergencies. No, because if it's still possible to mix versions in your services, then a monodeploy doesn't actually solve any issues. I actually am a big fan of fewer services and deploying bigger artifacts, but if you have multiple services, you have to act like you have multiple services.