I'm the author of 12factor (although really it is an aggregation of the work and insights from many people at Heroku). It continues to surprise and please me that this piece continues to be relevant eight years later—a virtual eternity in software/internet time.<p>Fun fact: I debated whether to call it "the Heroku way" or somesuch. Glad I went with a standalone name, feel like that allowed it to take on a life beyond that product. For example I doubt Google would have wanted a page about "Heroku Way app development on GCP" in their documentation. :-)
12 factor seems to have stood the test of time really well—I was introduced via Heroku (who I think invented it?) quite a long time ago in tech years, and yet it still seems to be probably the most popular ‘framework’ for devops.<p>In fact, my startup EnvKey[1] was heavily inspired by the 12 factor approach. While it has always worked well for me, one bit that always felt thorny was using the environment for configuration and secrets. It’s obviously great to get this stuff out of code, but then you face new issues on how to keep it all in sync across many environments and pass potentially highly sensitive data around securely.<p>EnvKey fills in this gap using end-to-end encryption and a seamless integration that builds on top of environment variables—it’s a drop-in replacement if you already use the environment for config. Check it out if you’re looking for something to smooth out this aspect of 12 factor! We have lots of folks using it with GCP/GKE.<p>1 - <a href="https://www.envkey.com" rel="nofollow">https://www.envkey.com</a>
> In non-cloud environments, web apps are often written to run in app containers such as GlassFish, Apache Tomcat, and Apache HTTP Server. In contrast, twelve-factor apps don't rely on external app containers.<p>This comment stood out to me. Why does this have anything to do with cloud vs non-cloud?<p>Furthermore I think there are merits to both of the approaches. But the article phrased it as if one is clearly more superior than the other.<p>I think we should also not forget that for the longest time, even before there was Google Cloud, there was App Engine that adopted the former approach: you simply write your handlers in Python, and the server provided by Google runs your handlers. Nowadays in the new Python App Engine runtime they added gunicorn by default so it's less clear.
Backing Services section is over promising. Changing databases isn't a simple configuration change. Every database doesn't speak the same SQL. It doesn't have the same optimizations nor configuration. Also, your organization probably won't be making that change-- ever. Even if you could swap, you very likely won't.<p>This is similar to the claim that by using an ORM, you can easily change databases except that the ORM actually can achieve it because it abstracts away the differences. Yet, very rarely does this valuable feature get used.
Also worth reading is "Beyond the Twelve-Factor App" (O’Reilly). It goes into the 12 factors and expands them to 15 for cloud-native apps. I believe I got a free e-book via Pivotal's content library.
> A better approach is to store configuration in environment variables.<p>It's about damn time, Google! I've been working on a number of GCP projects this year and have consistently bumped up against the awkwardness that was Google's (former?) preference for configuration files over environment variables.
Hmm, non of the 12 factors is really be specific to the cloud. I mean ok, the implementation of some of the thinks might slightly differ. E.g. you should still abstract over storage, but it's not necessary a external service as this additional external dependency is just not no always necessary.<p>It's kinda funny how cloud forces people to finally use patterns recommended since years.
I wonder if anyone else does this.
I have a private, env-var only repo per project that I very simply import (git clone) while building. I'm sure there are some risks like possible leakage if a team member's github account is compromised but it seems like a very nice, clean way of managing secrets. I even get the benefit of a version control.
Its interesting to see this 12-factor popping up today. We used this 12-factor app development methodology at one of my client and they had good documentation about it. This was in 2015-2016 and I believe this is still relevant.