5 ms·

I feel like each of this points can be reasonably disputed. 1. One app - one repo. There is nothing fundamentally wrong with multiple apps (as in separate pods

I feel like each of this points can be reasonably disputed. 1. One app - one repo. There is nothing fundamentally wrong with multiple apps (as in separate pods/containers/processes) being developed in a single repo, as long as they are tightly coupled functionally, share the release cycle, but still need to be deployed separately to get advantages of separate processes and independent scaling. The first example that comes to mind is separation of public api and worker processes, e.g. ruby's sidekiq, python's celery or a generic kafka consumer. 2. > A twelve-factor app never relies on implicit existence of system-wide packages. This is incredibly hard to achieve in practice if you're not running something nix, and even then there are leaks of dependencies on kernel syscall APIs. Every Rust app implicitly depends on a glibc (except musl ones), which is present in major Linux distros except slim ones such as Alpine. In fact, the whole Docker crutch IMO is needed specifically to alleviate this problem. 3. > The twelve-factor app stores config in environment variables It seems to me much more brittle, as it forces you to store secrets in envs, which could be less secure, and to abandon structured file configs, which may enjoy type safety, IDE autocomplete and automatic parsing. With envs you are forced to implement parses for non-trivial and non-string config vars yourself. In fact, envs are often committed into repos as well in form of dot-env files, so the point about commit-safety is moot as well.

twic 3y ago
> This is incredibly hard to achieve in practice if you're not running something nix, and even then there are leaks of dependencies on kernel syscall APIs. You're misinterpreting that guideline. The text says (my emphasis): > Most programming languages offer a packaging system for distributing support libraries, such as CPAN for Perl or Rubygems for Ruby. Libraries installed through a packaging system can be installed system-wide (known as “site packages”) It's not saying not to depend on the operating system (of which glibc is part), it's saying not to require particular language package manager packages to be installed on the machine. Agreed that the other ones you mention are silly, though. Especially the one about environment variables - that isn't actually reasoned advice, it was just the authors writing down what was most common in Ruby development at the time, on the assumption that that must be the best thing to do.
- vilunov 3y ago
  Well, glibc could be considered part of the operating system, although this too is arguably not correct, because some technologies go out of the way to not depend on anything present in the system and be completely self-contained, e.g. fully statically linked Go binary with no Cgo usage. Nevertheless, glibc is not the only system dependency which is often used by apps, another such example is JVM of a specific version, which is not tracked by any of the popular JVM build tools and package managers; and OpenSSL, which is too installed by the system package manager. Dockerfiles exists to fix this by defining all the necessary installation steps as a sequence of instructions, but this is far from a proper package manager.
  - twic 3y ago
    The libc is absolutely part of the operating system. Some people and tools go out of their way to avoid using it, but they are completely mistaken to do so. Go in particular has wasted a huge amount of effort on this absolutely pointless exercise. And not just libc - on a typical unix, there are a small number of other libraries which constitute part of the operating system, like libm, libdl, and libpthread. They are part of the means by which the operating system delivers the POSIX environment. You're right that the JVM is a dependency, and that there is very poor versioning support for it in production. Everywhere i've worked, we've come up with ad-hoc solutions for it, and none of them have been very good.
- aniforprez 3y ago
  In my experience, sourcing config from env variables seems like the best thing to do because you can completely ignore where the app is running in favor of injecting whatever you want in any environment of your choosing and your app no longer needs to care about that. The implication is that business logic must not include the content of your config or where it is sourced from. It must simply use the values in the config. This way my apps could give less of a fart if I run it as a container in kube, in nomad, in local on localhost, in a devcontainer, in a directory with vars loaded using direnv, in vercel/netlify and so on. This also allows incredible flexibility in how that config is sourced as long as you simply dump them into the env vars. Want to load secrets from a .env file on local? Sure. Want to load secrets from Vault on production? Run a simple script to load vault secrets onto the env and run your app.
damianh 3y ago
"One app - one repo" Where did you see that being expressed?
- vilunov 3y ago
  https://12factor.net/codebase https://12factor.net/codebase
  - ulizzle 3y ago
    It says there that a codebase can contain multiple repos. They don’t mean a monorepo when they say codebase
    - vilunov 3y ago
      > A codebase is any single repo (in a centralized revision control system like Subversion), or any set of repos who share a root commit (in a decentralized revision control system like Git). They do mean that a repo = a codebase. A remark about "set of repos" is just a technicality of distributed VCSs, meaning that each copy cloned from a single source (or from other copies) is a single repo.
samus 3y ago
I agree with your view of the first rule and would gladly store multiple related apps in one repo. No rationale for why one repo should only containing one app is given, therefore that rule can be disregarded. Dynamic or managed languages can often ignore most of the hassle with system packages.
brodouevencode 3y ago
> 1. One app - one repo. There is a U-shaped utility to monorepos. Most projects fall in the middle somewhere, largely ones managed by independent engineering teams that have no centralized platform/devops/whatever-we-are-calling-it-these-days team.
kagakuninja 3y ago
They also say every server should be a separate process, which is debatable. When using languages that lack real threads (Ruby, Python, etc) you have no choice.
talent_deprived 3y ago
> There is nothing fundamentally wrong with multiple apps (as in separate pods/containers/processes) being developed in a single repo, as long as they are tightly coupled functionally, share the release cycle, but still need to be deployed separately to get advantages of separate processes and independent scaling. We disagree on fundamentals then and I think more of the world agrees with me and with the 12 factors.
Aeolun 3y ago
Point 1 was written when it was standard practice to stick all of your organisations code in a single repository. The concept of splitting things (history, diffs, etc.) up per app was foreign to a lot of people.
lmm 3y ago
> There is nothing fundamentally wrong with multiple apps (as in separate pods/containers/processes) being developed in a single repo, as long as they are tightly coupled functionally, share the release cycle, but still need to be deployed separately to get advantages of separate processes and independent scaling. If they're deployed separately, they don't share the release cycle. Sooner or later you'll end up with mismatched versions of them running (e.g. perhaps one piece fails to deploy). So you need to be prepared for that, so you want them in separate repos so you can easily test with different versions. > This is incredibly hard to achieve in practice if you're not running something nix, and even then there are leaks of dependencies on kernel syscall APIs. Every Rust app implicitly depends on a glibc (except musl ones), which is present in major Linux distros except slim ones such as Alpine. Most higher-level languages avoid depending on a specific glibc; as long as you have a working runtime for that language then your app will work with it. And sure in some cases you resort to docker or something. It can indeed be hard but that doesn't mean it's not worth doing.
- vilunov 3y ago
  > If they're deployed separately, they don't share the release cycle. Sooner or later you'll end up with mismatched versions of them running (e.g. perhaps one piece fails to deploy). So you need to be prepared for that, so you want them in separate repos so you can easily test with different versions. In that case I'll just rollback the first one. I see no reason to logically decouple two processes into two services when the separation is technically driven. They share the queues, the database, the domain, further division will just make things more complex with no obvious advantage.
  - lmm 3y ago
    > In that case I'll just rollback the first one At that point you're not deploying separately any more. They explicitly say you can have multiple processes and process types as part of the same app (see #8). The point is that "repo of its own" should align with "atomic unit of release/deployment".

twic 3y ago

> This is incredibly hard to achieve in practice if you're not running something nix, and even then there are leaks of dependencies on kernel syscall APIs. You're misinterpreting that guideline. The text says (my emphasis): > Most programming languages offer a packaging system for distributing support libraries, such as CPAN for Perl or Rubygems for Ruby. Libraries installed through a packaging system can be installed system-wide (known as “site packages”) It's not saying not to depend on the operating system (of which glibc is part), it's saying not to require particular language package manager packages to be installed on the machine. Agreed that the other ones you mention are silly, though. Especially the one about environment variables - that isn't actually reasoned advice, it was just the authors writing down what was most common in Ruby development at the time, on the assumption that that must be the best thing to do.

vilunov 3y ago
Well, glibc could be considered part of the operating system, although this too is arguably not correct, because some technologies go out of the way to not depend on anything present in the system and be completely self-contained, e.g. fully statically linked Go binary with no Cgo usage. Nevertheless, glibc is not the only system dependency which is often used by apps, another such example is JVM of a specific version, which is not tracked by any of the popular JVM build tools and package managers; and OpenSSL, which is too installed by the system package manager. Dockerfiles exists to fix this by defining all the necessary installation steps as a sequence of instructions, but this is far from a proper package manager.
- twic 3y ago
  The libc is absolutely part of the operating system. Some people and tools go out of their way to avoid using it, but they are completely mistaken to do so. Go in particular has wasted a huge amount of effort on this absolutely pointless exercise. And not just libc - on a typical unix, there are a small number of other libraries which constitute part of the operating system, like libm, libdl, and libpthread. They are part of the means by which the operating system delivers the POSIX environment. You're right that the JVM is a dependency, and that there is very poor versioning support for it in production. Everywhere i've worked, we've come up with ad-hoc solutions for it, and none of them have been very good.
aniforprez 3y ago
In my experience, sourcing config from env variables seems like the best thing to do because you can completely ignore where the app is running in favor of injecting whatever you want in any environment of your choosing and your app no longer needs to care about that. The implication is that business logic must not include the content of your config or where it is sourced from. It must simply use the values in the config. This way my apps could give less of a fart if I run it as a container in kube, in nomad, in local on localhost, in a devcontainer, in a directory with vars loaded using direnv, in vercel/netlify and so on. This also allows incredible flexibility in how that config is sourced as long as you simply dump them into the env vars. Want to load secrets from a .env file on local? Sure. Want to load secrets from Vault on production? Run a simple script to load vault secrets onto the env and run your app.

damianh 3y ago

"One app - one repo" Where did you see that being expressed?

vilunov 3y ago
https://12factor.net/codebase https://12factor.net/codebase
- ulizzle 3y ago
  It says there that a codebase can contain multiple repos. They don’t mean a monorepo when they say codebase
  - vilunov 3y ago
    > A codebase is any single repo (in a centralized revision control system like Subversion), or any set of repos who share a root commit (in a decentralized revision control system like Git). They do mean that a repo = a codebase. A remark about "set of repos" is just a technicality of distributed VCSs, meaning that each copy cloned from a single source (or from other copies) is a single repo.

samus 3y ago

I agree with your view of the first rule and would gladly store multiple related apps in one repo. No rationale for why one repo should only containing one app is given, therefore that rule can be disregarded. Dynamic or managed languages can often ignore most of the hassle with system packages.

brodouevencode 3y ago

> 1. One app - one repo. There is a U-shaped utility to monorepos. Most projects fall in the middle somewhere, largely ones managed by independent engineering teams that have no centralized platform/devops/whatever-we-are-calling-it-these-days team.

kagakuninja 3y ago

They also say every server should be a separate process, which is debatable. When using languages that lack real threads (Ruby, Python, etc) you have no choice.

talent_deprived 3y ago

Aeolun 3y ago

Point 1 was written when it was standard practice to stick all of your organisations code in a single repository. The concept of splitting things (history, diffs, etc.) up per app was foreign to a lot of people.

lmm 3y ago

> There is nothing fundamentally wrong with multiple apps (as in separate pods/containers/processes) being developed in a single repo, as long as they are tightly coupled functionally, share the release cycle, but still need to be deployed separately to get advantages of separate processes and independent scaling. If they're deployed separately, they don't share the release cycle. Sooner or later you'll end up with mismatched versions of them running (e.g. perhaps one piece fails to deploy). So you need to be prepared for that, so you want them in separate repos so you can easily test with different versions. > This is incredibly hard to achieve in practice if you're not running something nix, and even then there are leaks of dependencies on kernel syscall APIs. Every Rust app implicitly depends on a glibc (except musl ones), which is present in major Linux distros except slim ones such as Alpine. Most higher-level languages avoid depending on a specific glibc; as long as you have a working runtime for that language then your app will work with it. And sure in some cases you resort to docker or something. It can indeed be hard but that doesn't mean it's not worth doing.

vilunov 3y ago
> If they're deployed separately, they don't share the release cycle. Sooner or later you'll end up with mismatched versions of them running (e.g. perhaps one piece fails to deploy). So you need to be prepared for that, so you want them in separate repos so you can easily test with different versions. In that case I'll just rollback the first one. I see no reason to logically decouple two processes into two services when the separation is technically driven. They share the queues, the database, the domain, further division will just make things more complex with no obvious advantage.
- lmm 3y ago
  > In that case I'll just rollback the first one At that point you're not deploying separately any more. They explicitly say you can have multiple processes and process types as part of the same app (see #8). The point is that "repo of its own" should align with "atomic unit of release/deployment".