3 ms·

I think that author just does not have experience outside of what he does. Maybe his systems can fall back to sane defaults. But what is sane default if you hav

by ozim 11y ago

I think that author just does not have experience outside of what he does. Maybe his systems can fall back to sane defaults. But what is sane default if you have to communicate with 3rd party server and your system is worthless when connection is not there? You have to have ip/domain name configured. For cars if something is wrong then in some cases you can start and even drive but users get warning. If there is something really wrong car will not start. So I think what author suggests is at least asking for trouble. Almost everywhere as quoted: "Everything in this post is about improving the deployment process for your applications, specifically those running in a Docker container, but these ideas should apply almost anywhere."

lwf 11y ago
The author is a she.
- parasubvert 11y ago
  Kelsey isn't a she :)
  - lwf 11y ago
    Oh, welp. That's what I get for gendering names. My apologies, to both you and Kelsey.
parasubvert 11y ago
"I think that author just does not have experience outside of what he does." Kelsey's recommendations aren't that different from general resilient systems guidelines in the Erlang community, or any of the many notes on how distributed system development is Different. "But what is sane default if you have to communicate with 3rd party server and your system is worthless when connection is not there? " The sane default is to wait and keep trying to connect for at least a bounded period of time (and a sensible approach to backoff). The point is that, if you're building distributed systems, you need to account for partial failure. One of the 12 factors is the process model: your app should be considered a process that will be killed and/or restarted at will. It might do so when your backing services are currently unavailable. The sensible thing is to retry a bounded number times (with backoff) before giving up. Sometimes the underlying application platform also does this for you (by killing your app process and rescheduling it, if it doesn't come up after a certain time period). Baking in timing dependencies as a failure mode makes software less resilient.

by ozim 11y ago

lwf 11y ago

The author is a she.

parasubvert 11y ago
Kelsey isn't a she :)
- lwf 11y ago
  Oh, welp. That's what I get for gendering names. My apologies, to both you and Kelsey.

parasubvert 11y ago

"I think that author just does not have experience outside of what he does." Kelsey's recommendations aren't that different from general resilient systems guidelines in the Erlang community, or any of the many notes on how distributed system development is Different. "But what is sane default if you have to communicate with 3rd party server and your system is worthless when connection is not there? " The sane default is to wait and keep trying to connect for at least a bounded period of time (and a sensible approach to backoff). The point is that, if you're building distributed systems, you need to account for partial failure. One of the 12 factors is the process model: your app should be considered a process that will be killed and/or restarted at will. It might do so when your backing services are currently unavailable. The sensible thing is to retry a bounded number times (with backoff) before giving up. Sometimes the underlying application platform also does this for you (by killing your app process and rescheduling it, if it doesn't come up after a certain time period). Baking in timing dependencies as a failure mode makes software less resilient.