Earlier quoted context omitted.
Why is this so hard to believe? This is proof that simple software can scale very well. Your takeaway, IMO, should be that a lot of solutions are over-engineered relative to the businesses they serve. Not every company handles Slack's scale.
Cron scaling? Seriously? By definition cron does not scale, it is account by account per VM/machine with no rhyme or reason.
Executing Cron Scripts Reliably at Scale
51–60 of 100 posts
Re: Executing Cron Scripts Reliably at Scale
#52I would be curious why kube cron jobs didn't seem to fit the bill, my favorite part of these posts are when they have a section hinting that they explored other options picked specific tradeoffs
Re: Executing Cron Scripts Reliably at Scale
#53Earlier quoted context omitted.
Why is this so hard to believe? This is proof that simple software can scale very well. Your takeaway, IMO, should be that a lot of solutions are over-engineered relative to the businesses they serve. Not every company handles Slack's scale.
It’s no longer simple when you have platform code to prevent nodes from disappearing or dying on the minute on a kubernetes cluster the size of slack. A triggered pulse event stream would have done the trick to invoke a lambda or call code for every “thing” that needed a beat. Kubernetes comes with a scheduler…
Re: Executing Cron Scripts Reliably at Scale
#54Earlier quoted context omitted.
Can you name some? I've been looking for software in that space, a thing that runs cronjobs, with ability to kick off adhoc runs from some UI, see what is running, and if possible parameterise the custom runs (i.e., run an ad-hoc report for a different client than usual cron does)
I almost hate to say it, but Jenkins.
Plus, Jenkins has a few nice extensions to the crontab, including setting a timezone and using "H" to spread job execution load.
Re: Executing Cron Scripts Reliably at Scale
#55I would be curious why kube cron jobs didn't seem to fit the bill, my favorite part of these posts are when they have a section hinting that they explored other options picked specific tradeoffs
Spinning up a new Kubernetes pod for every single job run is a very expensive and wasteful operation, starting at least in the order of seconds (usually more) vs just milliseconds for a new process in an already hot environment.
Re: Executing Cron Scripts Reliably at Scale
#56I can’t believe an org of Slack’s size relied on cron scripts for anything critical. It is the worst possible way to schedule jobs at scale. Serious problems with discoverability, single points of failure, and failure mode options. Also surprised they didn’t just use an open source scheduler or product. There are a gazillion of them.
Can you name some? I've been looking for software in that space, a thing that runs cronjobs, with ability to kick off adhoc runs from some UI, see what is running, and if possible parameterise the custom runs (i.e., run an ad-hoc report for a different client than usual cron does)
Re: Executing Cron Scripts Reliably at Scale
#57I can’t believe an org of Slack’s size relied on cron scripts for anything critical. It is the worst possible way to schedule jobs at scale. Serious problems with discoverability, single points of failure, and failure mode options. Also surprised they didn’t just use an open source scheduler or product. There are a gazillion of them.
Can you name some? I've been looking for software in that space, a thing that runs cronjobs, with ability to kick off adhoc runs from some UI, see what is running, and if possible parameterise the custom runs (i.e., run an ad-hoc report for a different client than usual cron does)
For jobs run by data analysts, airflow and python work great. For devops jobs, begrudgingly, Jenkins or GitHub Actions. But there's so many varieties.
Re: Executing Cron Scripts Reliably at Scale
#58You give it a schedule and an endpoint (HTTP or a Cloud Task) and then it hits that endpoint on a schedule.
I go with Scheduler->Cloud Tasks->Cloud Functions, which gives you reliability and near infinite scalability.
Very easy to reason about and full monitoring of the whole stack.
Re: Executing Cron Scripts Reliably at Scale
#59Re: Executing Cron Scripts Reliably at Scale
#60Earlier quoted context omitted.
“Why are we doing this refactor in this PR along with the feature? Let’s do the feature first and then do the refactor later (read: never)”
The bet your making is you never need to do the refactor. The amount of absolutely garbage code that has never needed to change ever is easily worth a wait-and-see attitude.