3 ms·

> Periodic execution of a function is extremely basic and already exists in almost every programming environment. Periodic execution is surprisingly complicate

> Periodic execution of a function is extremely basic and already exists in almost every programming environment. Periodic execution is surprisingly complicated. What happens when your node is down when it was supposed to execute and then comes back up? What happens around timezone changes and leap years? What does this thing do if a run takes so long that the previous run is still going? How do you get logs/notifications if it fails? "Best effort" periodic execution is super easy, where you try to make a thing happen every period but it's okay if it doesn't happen as long as it does happen at some point in the near future (i.e. periodic clean up jobs, or maybe batch emails). There's also a salient argument that you shouldn't run things inside the same process/VM if you can avoid it. It'd be a real shame if the production app went down because the cleanup cronjob went haywire and choked out the CPU.

twic 3y ago
I am a big fan of avoiding service proliferation and cloud complexity, and just making really good use of the facilities provided by your language and OS of choice. But for exactly the reasons you outline, scheduling jobs is one of the few things where i would be eager to use some reliable, observable, carefully-engineered service.
klabb3 3y ago
> What happens when your node is down when it was supposed to execute and then comes back up? If you want at-least-once scheduling you’d probably use a library that writes a last-completed time to your db. > What happens around timezone changes and leap years? For wall-time scheduling you’d need to handle it, yes. Why would a service be better than a library though? > What does this thing do if a run takes so long that the previous run is still going? I think we’d need either another db entry or simply prevent overlap directly in the library. > How do you get logs/notifications if it fails? Same way as other things in your app that fails I guess. Perhaps logging a critical event? If you’re talking about external health monitoring then yes, you’d need to have a separate service by definition, preferably with a completely different provider/host.

twic 3y ago

I am a big fan of avoiding service proliferation and cloud complexity, and just making really good use of the facilities provided by your language and OS of choice. But for exactly the reasons you outline, scheduling jobs is one of the few things where i would be eager to use some reliable, observable, carefully-engineered service.

klabb3 3y ago

> What happens when your node is down when it was supposed to execute and then comes back up? If you want at-least-once scheduling you’d probably use a library that writes a last-completed time to your db. > What happens around timezone changes and leap years? For wall-time scheduling you’d need to handle it, yes. Why would a service be better than a library though? > What does this thing do if a run takes so long that the previous run is still going? I think we’d need either another db entry or simply prevent overlap directly in the library. > How do you get logs/notifications if it fails? Same way as other things in your app that fails I guess. Perhaps logging a critical event? If you’re talking about external health monitoring then yes, you’d need to have a separate service by definition, preferably with a completely different provider/host.