adamwiggins / 12factor Goto Github PK

Great work!

What is the license of the content?

See http://12factor.net/

Hello there, I would be more than happy helping translating it to Brazillian Portuguese, but first I would like to know if there is a preferred way of doing so since just forking the project + translating the files wouldn't be a great idea in terms of maintenance, right...

What would you suggest?

The 12 factor is awesome! It's a thing that i always recommend to all developers that i know. But when i talk about the 12 factor i always talk about infrastructure as code too.

Infrastructure as code is a thing that every developer should keep in mind. So why not add infrastructure as code as a thirteen factor?

Instead of focusing on a mechanism (port binding), the focus should be on containerization, and the verbiage should also allow for things like UNIX-domain (file) sockets for the exposed connection. If anything, UNIX-domain sockets are superior to plain port binding because they're more secure on several axes:

• Finer-grained access control, following the UNIX permissions model
• No chance of a misconfiguration exposing the raw port to the outside world
• Limits the attack surface for multiple users on a shared system

Additionally, in my own experience it makes things a lot easier to configure, since you don't have to run anything that keeps track of a service-port mapping, and it's way less likely to make mistakes with e.g. configuring multiple services on the same port or reverse proxying to the wrong one. You can also make better use of systemd to only launch the underlying service when the socket is needed by the fronting server, which can save on resources when managing several services which only run on rare occasion.

GitHub project URL.

I feel like a lot of the issues stated throughout the 12 factor sections arise from applications made in only-developer teams, with no consideration for easy deployability, explicit dependencies, external configuration, etc. I think the document would benefit from a rewording of the Who should read this document? section, given the problems that come from a mentality of separated development/ ops teams, where the former only adds code, and the latter has to deal with deploys. It would also keep things consistent with X. Dev/Prod Parity.

I like what I have read on the 12factor.net site but one concept in particular stands out as unclear, perhaps incomplete: config.

The site recommends using individual environment variables instead of sets of environment variables grouped in to environments (e.g. production, staging). However, the site also recommends that the development and production environments be kept as similar as is possible, suggesting that there must be some mechanism keeping at least the variable names in sync, if not the values, for consistent development environments. These two recommendations seem to be in conflict, or at least one could be clarified to support the other.

Are there practical examples demonstrating a way to manage environment variables without them being grouped in to environments or files that may inadvertently be committed to VCS?

This link in Concurenncy factor description not alive anymore.

Twelve-factor app processes should never daemonize or write PID files.

Can anyone find active link and replace the broken one?

We should add default values to the Config part. Something along this line:

Configuration values when not explicitly specified in the environment variables should point to their default values, which should run the application under a local/test environment. If application requires backing services to operate (such as a database), then the default values should point to the backing resources running on the same host machine. For example, if application requires PostgreSQL, then if the PostgreSQL host is not specified in the environment variable, it should point to localhost:5432.

Configuration that do not have default values, such as credentials, should be left unspecified, and application should behave accordingly when those values are left blank (e.g. hard fail if credentials are missing).

Default values can be specified in a separate configuration file but treated as constants, overridable only by environment variables.

I'm frequently amazed at the number of shops still develop enterprise code with little or no automated test coverage.

The initial 12factor.net concepts are irrefutably good stuff, to someone who has some background with the challenges.

To someone reviewing strategies, 12factor.net lacks some clearly attached studies of one or more 12factor conventions being applied to scale deployments.

the year 2012 is associated with the information. Git evolution of the material is the sole testimony of adoption rate that an outsider can clearly measure about 12factor at this time.

12factor creates a a challenge to credibility when someone who is examining the 12factor evolution as a fit finds the incomplete project rehoming cited in #20 and brings questions to mind about the cohesiveness of the title bearing authors carrying a Movement with a capital M to the next level of awareness.

Is there a way we can extend the config.yml or other references, to specific languages?

I am willing to work on Python and maybe parts of C, but I've had multiple people point me to this site which is great, but then I have to research for this format in python.

Would be helpful that just as we are changing the written/spoken language we could also adjust the code referenced in Python, Ruby, Java etc.

Maybe it makes sense to move the main repository to the https://github.com/heroku/12factor ?

Hi, this is more of a question about what you're proposing. In a situation where your application is composed of several independent services, how do you handle authentication? How can you make sure that all the components are looking at the same user session/data? I'm a Python guy: what if you have two small Django-based services and you need to make sure that they are both looking at the same User object?

Any pointers would be appreciated