4 ms·

That is only true if your jobs aren't doing a stateless operation. I use cron all the time on cattle VMs. No reason to cargo cult extra stuff into the mix.

scarface74 8y ago
Until that one server goes down in the middle of the night or it has issues. Or if the server doesn’t go down and your cron job fails. Do you then implement retry logic in every job since cron can’t do retries automatically?
- kiallmacinnes 8y ago
  I think the parent poster was referring to the fact that Cron jobs can act purely on local state, and that's OK. For example, if I had a traditionally deployed (i.e. not in K8S / a PaaS / similar) backend app that accepted file uploads, then passed those off to something else, I'd be streaming the uploads to a temporary holding directory on disk. I'd then have a CronJob that clears stale items from the temp dir. If the server fails, that's OK that the CronJob didn't run. There are still plenty of use cases for traditional cron.
- C1sc0cat 8y ago
  Yes jobs that run unattended via chron should have logging and watch dog processes that check for completion and possibly do reconciliation - that can alert if something goes wrong and the logs help diagnosis.
  - scarface74 8y ago
    Now you’re reinventing Nomad....
- coldtea 8y ago
  >Until that one server goes down in the middle of the night or it has issues. The extra complexity of any workflow manager would make it even more certain to "goes down in the middle of the night or have issues".
  - scarface74 8y ago
    In the case of Nomad, you run it as cluster of three. But if one of my app servers went down in the middle of the night, when I was using Nomad, the next day I might notice a degradation of performance but everything still ran. The server going down was never really the issue though honestly. The issue was usually a process taking more CPU/Memory than expected in that case Nomad could intelligently schedule jobs based on available resources across the fleet of app servers. These days with AWS, I don’t use Nomad, I just use CloudWatch and for the processes that aren’t Lambda based, I use autoscaling groups with the appropriate metrics for scaling in and out. That also means if a server goes wonky, I can just take it out of the group for troubleshooting later and another instance will automatically be launched.
deleted 8y ago
[deleted]

scarface74 8y ago

Until that one server goes down in the middle of the night or it has issues. Or if the server doesn’t go down and your cron job fails. Do you then implement retry logic in every job since cron can’t do retries automatically?

kiallmacinnes 8y ago
I think the parent poster was referring to the fact that Cron jobs can act purely on local state, and that's OK. For example, if I had a traditionally deployed (i.e. not in K8S / a PaaS / similar) backend app that accepted file uploads, then passed those off to something else, I'd be streaming the uploads to a temporary holding directory on disk. I'd then have a CronJob that clears stale items from the temp dir. If the server fails, that's OK that the CronJob didn't run. There are still plenty of use cases for traditional cron.
C1sc0cat 8y ago
Yes jobs that run unattended via chron should have logging and watch dog processes that check for completion and possibly do reconciliation - that can alert if something goes wrong and the logs help diagnosis.
- scarface74 8y ago
  Now you’re reinventing Nomad....
coldtea 8y ago
>Until that one server goes down in the middle of the night or it has issues. The extra complexity of any workflow manager would make it even more certain to "goes down in the middle of the night or have issues".
- scarface74 8y ago
  In the case of Nomad, you run it as cluster of three. But if one of my app servers went down in the middle of the night, when I was using Nomad, the next day I might notice a degradation of performance but everything still ran. The server going down was never really the issue though honestly. The issue was usually a process taking more CPU/Memory than expected in that case Nomad could intelligently schedule jobs based on available resources across the fleet of app servers. These days with AWS, I don’t use Nomad, I just use CloudWatch and for the processes that aren’t Lambda based, I use autoscaling groups with the appropriate metrics for scaling in and out. That also means if a server goes wonky, I can just take it out of the group for troubleshooting later and another instance will automatically be launched.

deleted 8y ago

[deleted]