
Twelve-factor app development on Google Cloud - 9nGQluzmnq3M
https://cloud.google.com/solutions/twelve-factor-app-development-on-gcp
======
adamwiggins
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.

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. :-)

~~~
butisaidsudo
Just wanted to thank you for this. When I was a lost and confused junior, I
had no one more experienced around to ask for advice. I stumbled across this
and it answered so many questions that I had, and it still very much applies
many years later.

------
danenania
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.

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.

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.

1 - [https://www.envkey.com](https://www.envkey.com)

~~~
WrtCdEvrydy
> I think invented it

I don't think so... the 12 factor app was existing before that... but came to
more common usage during the rise of Rails (and Heroku)

~~~
jbarham
Both [https://12factor.net/](https://12factor.net/) and the Wikipedia page
[https://en.wikipedia.org/wiki/Twelve-
Factor_App_methodology](https://en.wikipedia.org/wiki/Twelve-
Factor_App_methodology) credit Heroku developers for formalizing the 12 factor
methodology.

~~~
rarecoil
If you go to the bottom of the page, you'll notice that
[https://12factor.net/](https://12factor.net/) is written by Adam Wiggins, a
Heroku cofounder.

------
kccqzy
> 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.

This comment stood out to me. Why does this have anything to do with cloud vs
non-cloud?

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.

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.

~~~
thomascgalvin
Primarily because instances are disposable. Getting more traffic to your Foo
service than you expected? Spin up another Foo, and let the load balancer
figure it out. Then, an hour later, when traffic goes back to normal, kill the
new instance.

This is easier to do when your service is self-contained. It's certainly
possible with an app server, but 12-factor apps tend to view the service as an
atomic unit that can be started and stopped wholesale.

~~~
kccqzy
These are orthogonal. Have you used Google App Engine prior to Python 3? When
you get more traffic, the App Engine spins up more instances, each running
both the handlers you wrote and the server code you didn't write.

------
Dowwie
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.

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.

~~~
hunterloftis
The backing services factor doesn't mean that you should expect to be able to
hot-swap database types.

Rather, it means you should be able to "dependency inject" a compatible
database into your app. Say your app is designed to speak Postgres - that
Postgres db should be able to run locally, or on a managed cloud service, and
the app shouldn't know or care which. You should be able to switch between
such services without any code changes.

In practice, this sometimes does mean that multiple database implementations
satisfy the interface expected by your app, and you can in fact hot-swap
underlying stores. But the spirit of the factor is that the app should have
its dependencies ("backing services") provided, rather than hard-coded.

~~~
Dowwie
Ah, that makes sense. Thanks for clarifying

------
bogle
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.

~~~
dv35z
Beyond the 12 factor app:

(1) One codebase, one application

(2) API first

(3) Dependency management

(4) Design, build, release, and run

(5) Configuration, credentials, and code

(6) Logs

(7) Disposability

(8) Backing services

(9) Environment parity

(10) Administrative processes

(11) Port binding

(12) Stateless processes

(13) Concurrency

(14) Telemetry

(15) Authentication and authorization

More info: [https://content.pivotal.io/blog/beyond-the-twelve-factor-
app](https://content.pivotal.io/blog/beyond-the-twelve-factor-app)

------
ethagnawl
> A better approach is to store configuration in environment variables.

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.

~~~
emmelaich
This is the weakest or least well-defined aspect of 12factor.

How can you 'store' anything in something as ephemeral as environment
variables? Where do these environment variables come from? When are they set?

You should of course store everything in version control; the point of this
guideline is that the scope should not be the same as the app or an instance.

There is particular tension between this guideline and X. environments should
be a similar as possible and I. there should be a single codebase for all
deployments.

~~~
tybit
Another option is rather than storing configuration in config files, is to
store it in code. After experimenting with different approaches, storing
configuration in code and switching on a single environment variable ENV (or
STAGE or whatever you like to call it) this is probably my favourite.

This doesn't work for everyones infrastructure setups, but it's worked well
for mine.

~~~
icebraining
A file that stores configuration is a configuration file, even if the encoding
format happens to be the same as the main programming language and not toml or
yaml :)

That works fine if there's a limited number of environments, but it becomes a
pain if you're running the same app in too many, or if someone else needs to
deploy it independently of the developers.

~~~
solipsism
_it becomes a pain if you 're running the same app in too many,_

No it doesn't. It's trivial to generate the full set of configs using a
script, if you have too many to manage manually.

 _or if someone else needs to deploy it independently of the developers_

And how exactly do envvars help with that? The set of envvars still needs to
get pushed with each deployment. envvars are just a special config file.

------
dathinab
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.

It's kinda funny how cloud forces people to finally use patterns recommended
since years.

------
SenHeng
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.

~~~
firepoet
We definitely avoid this approach. Fine grained access control per secret per
environment is impossible. We use explicit secret management software.

~~~
dhbradshaw
"We use explicit secret management software"

This is interesting. Can you go into more detail?

~~~
wikibob
[https://www.vaultproject.io/](https://www.vaultproject.io/)

Fairly easy to integrate with Kubernetes too.

------
rasikjain
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.

