Why this weird CRON jobs architecture?

After messing with CRON jobs, I just read this thread and understood there is no way to have a CRON job inside a web-service.

Here are some pretty important issues I have with this architecture choice:

  • I can not use data storage (I use a SQLite DB, which won’t be accessible in a cron, that’s an issue…)
  • I can not use the environment web service, unless I decide to migrate to an env group (which creates accidental complexity)
  • I need to build the web-service twice
  • My CRON jobs are at the same level than all my apps in my dashboard, which will become messy quickly.

I can’t help asking: why this choice?

A a sidenote, in my opinion, you should be totally honnest in this post: Render vs Heroku Comparison — Discover the Heroku Alternative for Developers | Render and explain features Heroku have and you don’t have (yet). And there are many.

Because the level of surprise/disappointment is high when I find out such things the hard way, and the trust decreases :confused:

Hey there,

Cron jobs run inside their own process so that they are entirely isolated from the web process. It would be far too easy to have a cron job that used all the resources and brought down your web services, so you are right in all your observations there.

Using our persistent storage disks you can store your sqliteDB but as disks can only be attached to a single service at a time, then other services, be it a background worker, cron wouldn’t be able to access the file-based DB. Certainly, with sqlite you’d end up with an issue around file locking if it were possibl. You do mention Heroku, but they don’t support persistent file storage as we have here so you can’t be using sqlite over there?

We always intend to be open and honest when comparing ourselves to competitors, if you have any specific features where you think our doc could be better then please do let us know or please, call us out on false claims. We have many, many customers coming to us from Heroku and the genuine feedback we get is that, that doc is a good reflection on the state of things.

Regards,

Thanks for your answer.

It’s still not very clear to me though. I try to understand the differences with Heroku on this particular topic. On Heroku we have one-off dynos to avoid killing the web worker, but since the cron is defined inside the app structure. we still don’t need to duplicate the environment nor another build.
Is there something that prevents to do such a thing in Render? Is it an architectural choice? A consequence of another choice? Do you agree that this architecture can be a problem for some people? (even if I used Postgres, most of the problems I quoted are still relevant).

About the documentation, I was specifically mentioning the “Render VS Heroku” page, in which you only mention Render advantages over Heroku, not the opposite. I understand it’s a marketing choice.

Don’t get me wrong, I love and usually prefer Render over Heroku. But I’d love you more if I could read in your docs things like “we can’t group applications and don’t have pipelines”. No false claims from you, just some omissions. And I would prefer be aware of all the differences before using services. Just an simple and honnest feedback from a user here :slight_smile:

1 Like

Ah ok - I think I’m with you now.

I think it comes down to the differences in the approach we’ve taken vs Heroku. On Heroku, as you say the app is front and centre. In fact, nothing can exist on Heroku without an app. Databases, schedulers, workers, addon etc all are related to the app. So when you look at an app on Heroku everything exists within it. Behind the scenes, when you spin up a worker or a scheduled task you don’t see that in the UI, it’s just a process that run’s the deployed code as the app they relate to.

Whereas on us, we’re more service orientated. If all you want is Postgres, just create a Postgres DB, similar for Redis etc - no app required. When you deploy a webservice you set the repo that backs it and also with background workers, cron you tell us the repo that backs it - this can be the same repo as the app but it really doesn’t have to be. Granted it does mean the UI can seem a little cluttered with webservices, databases, crons, background workers but we’re working on something to clean all that up. It does mean that using blueprints to manage all your services becomes important when you’ve got a handful of services to manage - I typically always go with envvar groups as my default now when I create new services as they may need to be shared with other services in the future.

I hear you on the documentation, but I think you reached the correct conclusion - it’s a marketing choice. We have a pile of work in progress at the moment which will hopefully address your needs if it’s pipelines you’re after :wink:

John B

1 Like

Thanks, very clear :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.