Factor 7: Port Binding
This 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 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?