3 ms·

Many services do not tolerate any downtimes, imagine you are processing money and you kill the process in the middle, it can be quite the pain to recover.

• nicolaslem 8y ago
  The article and my comments are about personal side projects, not about running a business. For me this means cutting down on complexity: 80% of the features for 20% of the work. Moreover, stopping a container does not mean killing it, it sends a SIGTERM that the application catches to terminate gracefully. I would also argue that applications processing money must be able to tolerate unexpected failures. Because Kubernetes or not, servers go down, processes get killed, disks get corrupt.
  • ngrilly 8y ago
    You may have side projects which are for a small business or a non-profit, and yet requires being able to sustain multiple requests per second on a single machine. In such a setup, zero downtime deployments are necessary. Some (most) application are being able to gracefully terminate, but it doesn't solve the issue. You still need some mechanism to start the new version, wait for it to be reader, switch the new traffic to the new version, and then gracefully shutdown the old version.
  • leandot 8y ago
    Those are fair points for side projects that have no visitors, but at least for me a side project can also have quite some traffic and then even a little timeout may not be an option. Plus you get a ton of goodies by relying on k8s (or similar) - ability to do an easy rollout, rollback, blue-green deployments, partial rollout, ability to replace multiple containers together if frontend and backend containers must be in sync (a pod) etc. Just my 2 cents.