Cron Job Resources

help
1

Hello Rust Community,

I am working on building a corn job for a rust project, I have an api-server running so I am looking into either scheduling/triggering the cron job using rust (the running api-server) or an outside source like Kubernetes/ AWS Task Scheduler.

If you can point me to resources, crates, rust example projects, or even your input/opinion, I would appreciate that. I would like to weigh my options, and figure out the pros and cons of using rust vs K8s.

2

I use cron for a cron-like scheduler in Rust. Has the (dis-)advantage that I can share resources with my server. On the other hand a k8s cron job would be cleaner from a structural perspective and it would make resource management easier (i.e. if I have a big cron job the response time of my server goes down). So I want to switch but haven't gotten around to it yet.

1 Like
3

Thank you for the response. What's making me lean towards Kubernetes is this, I would like my server to be independent of my cron job. I imagine having the corn job as part of the server, would make debugging harder? But can you elaborate more on why else are you looking into switching to K8s?

4

I can't say it did, but I don't know how easy it would be with a k8s cron job. The reasons I think k8s cron jobs are better suited for doing cron jobs in a k8s environment are:

  1. Resource independence. Your cron job gets its own resources (memory and cpu), independent of your server. If you start your cron job in a thread in the same pod as your server, they will share resources. This way a computationally heavy cron task could take away resources from your server and increase response time for api requests to it.
  2. Cron jobs need to run only once, even when you have multiple replicas in your deployment. My server runs in a deployment with a single pod. If I wanted to horizontally scale up to multiple pods, every pod would run the cron job. I don't want that and probably you won't either.
  3. This is an esoteric architectural point: from a structural perspective, it is cleaner in my opinion. Keeping track of all the parts in a distributed system can become very hard very quickly. A cron job is a small part of your distributed system and probably "just another thread". But in my experience these little "just another thread" type of tasks add up in making communication and synchronization across your cluster more difficult. It can also inhibit scaling (see previous point). If you use k8s as your orchestration tool, I'd try to utilize its capabilities and minimize the layers of distribution as much as possible. You make managing a k8s cluster a lot easier by writing small, independent (possibly stateless) k8s workloads with as little coupling as possible I'd boldly proclaim.
1 Like
5

Thank you, you brought up really good points. Especially the horizontal scaling part, I didnt think of that.

1 Like
6

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.