I really like 12 Factor Apps, the set of ideas and approaches has allowed me to make a few personal projects more easy to setup and run.

Additionally, i worked on the webpage and some components for Apturi Covid (Latvia's COVID contact tracing app, perhaps a bit less relevant now) which was also really easy to hand over to Ops to run thanks to the simple configuration: https://apturicovid.lv/#en

That said, at work there are still some people who don't want to use those approaches, their argumentation being along the lines of:

- config: "we don't like long lists of environment variables, files are easier to read" (ignoring that those don't play nicely with containers)
- config: "files let you group things more easily (processes.properties, datasource.properties, urls.properties)" (ignoring discoverability issues)
- backing services: "ehh, there's nothing wrong with hardcoding at least parts of a path in the app" (disregarding that context paths can change)
- build, release, run: "just put some default config in the app directory for running locally, bundle the front end and back end for ease of deployment" (ignoring that this bundling makes things more risky in regards to accidentally committing/shipping the wrong stuff, and bundling components slows everything down, can't build FE/BE in parallel)
- processes: "how do i restart Tomcat inside of the container?" (treating containers as VMs, though 12FA aren't necessarily bound to containers per se)
- concurrency: (the entire system is built in a way that is only compatible with a single instance, local filesystem used for stuff etc.)
- disposability: (the older apps take minutes to start up due to being large monoliths)
- logs: "but files are easier to work with" (they're only easier if you don't have proper log shipping infra in place)

What's my point with all of this? Well, for starters, if your apps are bad (large clunky monoliths), then it's not like 12 Factor App principles will make things that much better for you, since the actual implementation might be different due to previous assumptions that were made in the app design.

And even if they could, then you still have other people with conflicting opinions or simply views of cloud native and container based applications that will not have you easily running or scaling these apps anytime soon.

It's not like every system needs to be structured like that, but sometimes i wonder whether it would be easier to just work on new projects only and not bother modernizing the older ones. For all i (perhaps should) care about, those older systems might as well run with their config and log files on the file system, inside of Tomcat instances with JDK version and config drift, no scalability and manual restarts after crashes when things inevitably break, as well as eventual disk space issues - just with someone who feels comfortable spending their time that way behind the wheel, not me.

A bit like the blog post "Green Vs. Brown Programming Languages" which talked about most of the dreaded programming languages being old and most of the loved ones being new: https://earthly.dev/blog/brown-green-language/ Perhaps that's simply due to there not being any old legacy codebases to maintain in the newer languages, ergo them being liked.