diff options
Diffstat (limited to 'wiki/12factor')
| -rw-r--r-- | wiki/12factor/3-config.md | 22 | ||||
| -rw-r--r-- | wiki/12factor/7-port-binding.md | 31 | ||||
| -rw-r--r-- | wiki/12factor/index.md | 19 |
3 files changed, 0 insertions, 72 deletions
diff --git a/wiki/12factor/3-config.md b/wiki/12factor/3-config.md deleted file mode 100644 index 5d6c6c6..0000000 --- a/wiki/12factor/3-config.md +++ /dev/null @@ -1,22 +0,0 @@ -# Factor 3: Config - -[This section](http://www.12factor.net/config) advises using environment -variables for everything. - -> [Owen J](https://twitter.com/derspiny): I think I disagree with -> 12factor's conclusions on config even though I agree with the premises -> and rationale in general -> -> [Owen J](https://twitter.com/derspiny): environment variables -> are neither exceptionally portable, exceptionally standard, nor -> exceptionally easy to manage -> -> [Owen J](https://twitter.com/derspiny): and therefore should not be -> the exceptional configuration mechanism :) -> -> [Kit L](https://twitter.com/wlonk): that's exactly the critique i have - -Frustratingly, the config section doesn't provide any guidance on sensible -ways to _manage_ environment variables. In any real-world deployment, they're -going to have to be stored somewhere; where's appropriate? `.bash_profile`? -`httpd.con` as `SetEnv` directives? Per-release `rc` files? `/etc/init.d`? diff --git a/wiki/12factor/7-port-binding.md b/wiki/12factor/7-port-binding.md deleted file mode 100644 index a756496..0000000 --- a/wiki/12factor/7-port-binding.md +++ /dev/null @@ -1,31 +0,0 @@ -# Factor 7: Port Binding - -[This](http://www.12factor.net/port-binding) is the exact point where the -Heroku-specific features of the approach overwhelm the general features. - -Factor 7 is over-specific: - -* It presupposes the existence of a front-end routing layer, without providing - any insight into how to deploy, configure, provision, or manage one. - -* It demands HTTP (by name) rather than a more flexible “any well-standardized - protocol,” without explaining why. (Web apps can have non-HTTP internal - components.) - -* It dismisses the value of “pre-existing” container ecosystems that don't - work the way Heroku does. Have a giant, well-managed - [Glassfish](http://glassfish.org) cluster that you deploy components to? TOO - BAD, not Heroku-like enough for these guys even though many aspects run - along similar philosophical lines. - -* It dismisses the value of unix-as-a-container. Unix domain sockets with - controlled permissions? Psh, let's go through the network stack instead. - SysV IPC? (Yeah, I know.) Network. Pipes? Network. There's an implicit - exception for “intra-process” communication, but it's never really - identified or reasoned about. - -* Have you _seen_ the kinds of process control interfaces developers invent, - when left to their own devices? Signals and PID files are well-established - conventions, and smart, competent people still fuck those up all the time. - Command-line arguments are another frequent case of NIH stupidity. Do you - really want every app to have its own startup API? diff --git a/wiki/12factor/index.md b/wiki/12factor/index.md deleted file mode 100644 index 6e75732..0000000 --- a/wiki/12factor/index.md +++ /dev/null @@ -1,19 +0,0 @@ -# 12-Factor Apps - -Some folks over at [Heroku](http://heroku.com/) wrote up their perceived best -practices for building “software as a service”-style applications and called -it [The Twelve-Factor App](http://www.12factor.net). It's a good read, and has -lots of good advice in it. - -I have a few thoughts on it. - ------ - -* [III. Config](3-config) -* [VII. Port Binding](7-port-binding) - ------ - -At some point around sections 6 or 7, the goodness of the advice is overtaken -by the “be more like Heroku specifically”-ness of the advice, to the detriment -of their point. |