▲ 278 points
back
183 comments
I am a lead on a small startup team and one of the biggest pain points is dealing with infrastructure. We have no dedicated devops person and much of that work falls on me and other people who would be better writing code. I think the cloud paradigm is experiencing a shift. Few of us want to deal with cloud infrastructure (whether clicking around or via Terraform or equivalent) to execute a function every X minutes - its unnecessary developer hours. The functionality is so common that it should just work. Perhaps stemming from that there seem to be two recent trends:
1. Services like this cron with Dyno Deploy or Vercel where the cloud things are abstracted away for you.
2. I have no data to back it up but it seems like JVM is experience a bit of a comeback with a few companies adopting Kotlin for backend and, also subjectively, talk about Elixir has increased here on Hacker News (we've all seen that table that shows how the Erlang VM is cron/background jobs/logging service/KV store all rolled into one). And if those are not the trends I feel like they should be.
Both of those are very appealing to me as a team lead. Honestly, I have never been a fan of managing services in AWS/GCP/etc - the setup overhead rarely seemed to outweigh the pros, at least until some heavy amount of data start moving around. I might be stating the obvious - less work is definitely better, but pretty much every company I have consulted for in the last few years had a (crappy) bespoke cloud setup that was a massive time sink.
It is really disappointing to me when I hear takes like this. As an industry we are splitting the roles of programmers and engineers so that programmers can just throw spaghetti at the wall and it is the engineers problem to happily run it.
We need more well rounded people that also fundamentally understand how their code is executing on the backend so performance and cost can be optimized.
For sure. As someone who has stayed away from this part of the biz, infrastructure always looked like makework to me. Necessary, mind you, but still makework that was indicative of poor/insufficient computing primitives for services.
> it seems like JVM is experience a bit of a comeback with a few companies adopting Kotlin for backend
JVM 21 adding virtual threads, and Spring Boot 3.2 using them with one line of config is huge. We can now write simple code that looks blocking and let the runtime handle it instead of writing async function/await everywhere. Personally I'm loving Spring Boot 3.2 with Kotlin, especially for the fact that I can bundle scheduled jobs, API, and frontend all in one place for my indie projects. Plus the JVM world of devs seems to have a somewhat decent appreciation of how to make web services that aren't rife with unnecessary coupling.
The bad? There is a legendary amount of cargo-culting blog posts and questionable advice around Spring Boot, often for older versions.
> one of the biggest pain points is dealing with infrastructure
> We have no dedicated devops person
I understand that not every startup can afford an extra person for infra-heavy tasks, but this should not be surprising. Any tool which looks like an abstraction to you might get complex by time, and steal your time. The cloud was supposed to fix some of these, look where we are now.
I don't understand the reluctance to hire a system administrator. If you have two or more technical folks, at least one of them should be a sysadmin (or "devops" if you prefer). Pretending that it's an unskilled role that anyone should pick up reflects a poor understanding of the industry.
The "crappy bespoke cloud setup" is usually the result of people whose jobs are usually just regular app devs, but had been thrown into the infrastructure side head first. I think the key is to actually have someone who knows what they are talking about.
Unlike other people I don't think you need to hire someone directly. I do devops freelancing so you could hire someone like me. Or look online for various people that do it. I mean if its a toy app without many customers then who cares, but once you start scaling infrastructure gets to me more and more important.
Or you could just use an actual host running actual cron. No clicking, no terraform, just crontab -e. The last thing small short-staffed startups with no infra people should be doing is messing around setting up cloud infra to run something on a schedule.
> We have no dedicated devops person and much of that work falls on me and other people who would be better writing code. I think the cloud paradigm is experiencing a shift.
Part of that shift is that prior to the cloud, the development environment and production environments were very similar. By that I mean if a programmer could set up his debian / redhat laptop from the command line, then it wasn't a big jump to set up a server running debian / redhat in a production environment.
But no one in their right mind runs k8s on their laptop just to support VSCode and a compiler. Worse they could not run AWS/GCP because they are proprietary, insanely large, complex and forever changing. I'm pretty sure becoming an expert engineer in those environments is a full time job. The end result is a new class of engineers have arisen that look after the production side, and the developers just throw their code over the wall once it's tested.
I'm sure the cloud providers love this, as they have created a cohort of engineers that have invested years in learning their product, now have their wages dependent on that product being used within their organisation, and a total monopoly over that product because it can never be reproduced by anyone else. But for the industry as a whole, it looks to be a backward step. Once the problem expands beyond what a single human mind can cope with, you need teams. The communication overhead of a team means they don't have a hope of being as productive as a single person.
The share amount of complexity introduced by these proprietary cloud frameworks looks to be unnecessary. Most of it smells like technical debit created by organic growth together with an insistence on backward compatibility (don't want to give those locked in customers an excuse to move). And desktop OS's are (Debian / Windows / ...) are insecure by design, at least when compared to their phone brethren. And, their phone brethren look somewhat like cloud designs now, Phones have isolated apps with private data areas. The apps communicate via channels provided by the OS, and the availability of those channels is controlled by permissions assigned by the user. In the cloud we isolated things for performance as they could run on distance machines, whereas in a personal device we did it for security. But the end result looks similar.
So maybe one day we will end up where we started, with a developer environment looking like the cloud we deploy too. I fear I'm too old to experience if / when it does happen, but it does seem like something we should aspire to.
For cron jobs in Elixir you can use:
- [0] Quantum, quite simple and supports cron syntax.
- [1] Oban, which is a job runner, requires a DB, but also supports periodic jobs with a cron syntax.
(probably others but that's the ones I've used)
There’s a new crop of PaaS products that aim to provide a layer of sanity on top of cloud providers (e.g. Aptible). Might be a good fit for you.
> 1. Services like this cron with Dyno Deploy or Vercel where the cloud things are abstracted away for you.
I agree with the sentiment, but to me it’s a shame this even qualifies as abstraction in the first place. Periodic execution of a function is extremely basic and already exists in almost every programming environment. If this needs to be a service (instead of a library call), there is something deeply wrong elsewhere, imo. We all laughed about leftpad, but at least that was native code and not “as-a-service”, dependent on networking and proprietary code on someone else’s machine.
I have nothing against Deno in particular, and I’m also not saying this is easy from an implementation perspective (due to complexity elsewhere). I’m just surprised that trivial features – from an end-user perspective – justify such a ruckus.
I think this is where modern PHP (8.0+) has its strengths.
Its well known how to deploy. Its easy to deploy. The footguns are vigorously and thoroughly documented. The frameworks (Symfony, Laravel) are good. They all have a solution for X (be it queues, async work, cron jobs etc) and they have turn key deploy solutions favored by their respective communities.
Its honestly one of the easiest languages to deploy with nowadays, in my estimation. Rivaled only by C# / F# or platforms like Deno Deploy or Cloudflare workers. Sometimes the most boring / mature thing is the best thing.
PaaS
Sounds like you’d like to use a PaaS provider.
Heroku/Render/Fly/etc.
There is a collection of new tools trying to address this exact problem such as Nitric, Winglang and Ampt for example. (disclaimer, I work on Nitric)
+1, as someone whose company has a crappy bespoke cloud setup that's a massive time sink
> Honestly, I have never been a fan of managing services in AWS/GCP/etc - the setup overhead rarely seemed to outweigh the pros
I just `ssh` into prod and `git pull` and either `docker compose up` or `kubectl apply` or `terraform apply` or `helm update` or `argocd sync`
The AI-generated imagery at https://deno.com/blog/cron/cover.png is actually painful the longer you look at it. The multiple watch hands might be an artistic effect, but the clock lacks the tenth hour and has two elevenths, the dinosaur's legs make absolutely no sense, and the water reflections show a different pattern on the dinosaur legs and a completely different set of clock hands than what is visible above.
I know that displaying artwork is not the point of the article, but please, at least make it believable when you look at it for more than one second.
Yes, by all means, make sure that the dinosaur wearing a clock around his neck looks believable. I'd hate to see something ridiculous.
It's hard to ignore when it takes up my entire screen and I have to scroll to see anything else. AI artwork is popping up everywhere and I don't think it looks as cool as people seem to think. It comes off incredibly tacky.
It's especially disappointing to see Deno doing this, because in the past they've used endearing art made by an artist, hashrock, which I liked very much.
I was pleasantly surprised to see this, but it seems that the JS context in each run of the cron script is cloned so cron jobs are actually run in a separate "process".
Namely, I ran this example.
let s = 0, r = 0;
Deno.cron("Add second", "* * * * *", async () => {
console.log(`Add second ${s++}`);
});
Deno.serve(async (_req) => {
return new Response(`Seconds Running: ${s} / Number of requests: ${r++}`);
})
So, effectively, it seems that Deno.Cron clones the JS context but any changes done to that context will not be reflected in the Deno.serve. And, if that's the case, why don't handle Cron jobs in a different flow rather than mixing them with Deno.serve? (I think it can lead to unintended side-effects)
I'd love if someone from the Deno team could provide more context here, maybe I missed something?
I like a lot of what Deno does, but I'm having some trouble understanding why this (along with Deno's KV and Queues offering) is part of the Deno runtime.
The blog post touts this as a feature to reduce the amount of code to get up and running, but a library would accomplish the same thing. A first-party library could even directly integrate with Deno Deploy in the same way that this appears to.
Why pollute the runtime with something unrelated?
Great, but do they really have to leave the cron schedule format as the only option for specifying? It seems like a great idea if it's 1975 and you are dealing with limitations of that time. And I think it's good to keep it as an option.
But why not include any kind of schedule specifier that is a bit less cryptic and error prone? Is it really so much code?
Maybe someone has a package already that can wrap this or output a schedule from a human readable description or something. Maybe something like `human-to-cron`.
> How exactly does Deno Deploy know there’s a cron in your code, even when there’s no web server handling requests?
> When a new production deployment of your project is created, an ephemeral V8 isolate is used to evaluate your project’s top-level scope and to discover any Deno.cron definitions. A global cron scheduler is then updated with your project’s latest cron definitions, which includes updates to your existing crons, new crons, and deleted crons.
Having cron jobs defined in the code itself just feels weird. I get the convenience of doing things "in one place", but it's such an orthogonal concept. But I suppose combining things is part of the allure of deno any way.
Now that aside, the Flavor Flav dinosaur is the best thing I've seen all week.
Nice, I was just wondering if there was an opportunity for a product similar to vercel for batch jobs.
This isn't quite that but close.
From my experience there 5 main components for larger scale system.
- Request server
- database
- queue
- background worker
- offline batch jobs
I feel like so far serverless has the first 3 fairly well developed but the last two are still underdeveloped.
But maybe I'm just not aware of other solutions?
There is no doubt that this is a cool technical feat, but I don't think you'll catch me handling cron-like scheduling like this alongside application code.
I can see from comments like vvpan's that there is a fatigue around managing services in AWS/GCP/etc, but I have gone very much in the other direction in the last few years towards bare metal servers managed with NixOS. I feel much more confident in handling scheduled jobs on bare metal with Systemd timers than tying myself even deeper into a specific language+deployment solution ecosystem.
Not using something more intuitive than cron's schedule format seems like a missed opportunity.
hey, andy from the deno team here. we're really excited to land this. happy to answer any questions or pass questions along to the team!
Overlapping as an option would be nice, if I'm using cron to pull data to append to a database, and the append fails, I can normally retry. However, without overlap, I can't sit there doing retries since that will block future cron runs.
Timezones would be nice, "This helps avoid issues with time zones which observe daylight saving time." But it also causes issues with daylight saving time. I can't run something at 9 in the morning, I need to run it 1-2 hours before-hand, calculate the offset, and then queue a run 1-2 hours later. Or I can run 2 crons and have one or the other die early. Point being, all solutions become very hacky very fast.
It would be nice if an object was passed to the handler that had a targetDate for the ideal start time would be, so runs can be easily labeled and separated.
Yes I could round the Date.now() to the last minute, however, if Deploy ever goes over the minute boundary, that's all kaput.
In a similar vein: Systemd timers have some nice features, AccuracySec/RandomizedDelaySec/FixedRandomDelay, some options similar to that would be nice (of course, with minute resolution instead) (and of course, fixed delay can be pre-calculated, but it would be nice to just say 30m and have deno runtime manage that for me)
https://www.freedesktop.org/software/systemd/man/latest/syst...
When using Deno Deploy, which region does a cron job run in? Is there a way to configure it?
Nice, years ago I wrote a TypeScript (originally CoffeeScript re-written to TypeScript) library to generate schedule times for a cron between two time points, should be easy to write a service like this with it.
Vercel is it you? Seems like Deno Runtime is implementing what Deno Deploy would sell. While I understand it from a business perspective it totally makes me uninterested, I’d rather keep my dysfunctional marriage with AWS
How long does the job get to run?
Would be really awesome if this could be used to offload long lived jobs from the request.
Defer.run is building this for vercel and it’s really cool.
I want to love Deno. It seems to really modernize TypeScript development. I just haven't had good experiences with it.
I spent a day or two migrating a TypeScript project [-1] over to Deno from NodeJS. Here's what I had to do:
* Change all of my local imports to something that would work with Deno. That meant appending `.ts` or `index.ts` for folders, except in some cases where Deno requires `.js`
* Modify my monorepo to play nice with Deno -- an import map does this easily. Deno has documentation around import maps, but I had to figure out the solution myself. Also, import maps are currently broken in JetBrains IDEs.
* Change my NPM imports to something that would work with Deno. The most straightforward thing to do was just change `import "foo"` to `import "npm:foo"`, but this felt hacky so eventually I used https://esm.sh, which worked for some packages but not others.
* Figure out how to get Lodash working with TypeScript. It's not simple. [0]
* Use a hack to get typeorm with sqlite working. [1]
* Try out `deno compile`, only to determine that it somehow works differently than `deno run`. My project simply wouldn't work with `deno compile`, probably because my project has some system dependencies that don't get properly linked/included.
* Setup my scripts to properly lint my project. Deno has formatting/linting built-in, but it's split across many commands with different usages. For example, I can run `deno fmt` to format my entire project, but I have to give Deno a path to run `check` or `lint`, e.g. `deno check src/index.ts `
* Patch a third-party library that was setting an HTTP header to `null`. NodeJS handles this case just fine, but Deno throws an error [2].
* Attempt to build my UI (astro + react) with Deno. It seems some people have gotten this partially working, but I gave up and stayed on NodeJS for building my UI. This led to me:
* Using dnt [3] to build a Deno package for consumption with NodeJS/npm frontend. This was actually surprisingly simple; kudos to the author of the dnt library.
After all of that work, I finally was able to use Deno in my project. It was really cool! Unfortunately, both VS Code and IntelliJ with Deno are essentially unusable [4]. Or, at least, unacceptably slow compared to what I had with NodeJS.
[-1]: https://github.com/shepherdjerred/glitter-boys/tree/sj/deno
[0]: https://stackoverflow.com/a/66073607
[1]: https://github.com/typeorm/typeorm/issues/6123#issuecomment-...
[2]: https://github.com/Sansossio/twisted/issues/97
Anyone here using Deno in a production workload? Genuinely curious about your experience.
Wrote similar when I was working on an API platform. Used http callbacks. https://m3o.com/cron/api#Schedule
This really seems to muddy the distinction between the data layer and the application layer. I'm sure they've put a lot of thought into this, but it seems like there could be some bizarre edge cases.
I love Deno. I’ve been playing with it for a long time now. But the fact that Deno Deploy still doesn’t have a “deploy” button but we’ve got cool crons just seems… backwards?
Does it work locally?
Have the team at Deno not heard of systemd timers?
This is pretty neat, I can see this maybe being useful for database cleanup/housekeeping, what other example use cases are there?
Excited to use this, nice work Deno team!
What I see is yet another way that the backend JS world is finally achieving something .NET had over 10 years ago[0].
Node/Deno/Bun/etc. + npm sounds super straightforward (and it is at first). But I've thought for years that it's far easier to be productive on the backend on .NET in Visual Studio, since it's simpler to design, deliver, and maintain infrastructure.
If you like this, Elixir will make your brain explode :)
Better to call it adenocron.
while this looks useful it certainly shows what they are most concerned about which is making money off their cloud service.
I don’t think they have much interest in being a Node alternative anymore.
My first question when I am considering a product like this is how can I get an email when there's an error in my application. Why isn't that in the top level feature list of everything like this, or am I unusual in thinking that this is an essential feature of any hosting system?