3 ms·
> As you can see there’s nothing special here, but if you look closely you can see this application will only startup under specific conditions, which we’ll cal
by jacques_chester 11y ago
> As you can see there’s nothing special here, but if you look closely you can see this application will only startup under specific conditions, which we’ll call the happy path. If the configuration file or working directory is missing, or the database is not available during startup, the above application will fail to start.
Why not let a PaaS do this for you? Heroku, Cloud Foundry, OpenShift or the others I've yet to learn about?
Disclaimer: I work for Pivotal who donate the majority of engineering effort to Cloud Foundry.
- cpitman 11y agoI agree with the general idea, let an already existing product handle problems that everyone has. The last part is still important though, if we are going to build "distributed" apps, then we need to handle those dependencies failing or being briefly unavailable. And the reality is that every app becomes distributed as soon as it has a database or client. A ton of legacy applications make the implicit assumption that the network is reliable, and fall over hard when it isn't true anymore.
- jacques_chester 11y agoI agree that legacy apps break 12 factor rules. That's why the 12 factor app is "a thing" in the first place. An app which follows them can survive being killed and restarted. I've worked on some legacy migrations and it's usually a process of incrementally chiselling out services and cleaning up hard-coded assumptions. Tedious but usually doable.