Show HN: Cronit – Online Cronjobs(cronit.app) |
Show HN: Cronit – Online Cronjobs(cronit.app) |
Observation: Online cron jobs are not unlike online containerized web services (both involve running code) -- the difference is in the invocation event -- online web services are typically invoked in response to an HTTP (or other protocol) request, online cron jobs are invoked in response to a timer event, that is, in response to a specific, pre-scheduled, time.
So we have both request-based and pre-scheduled time-slot based -- invocation methods...
In theory there could be online code invocation -- based on a series of user-defined events and/or conditions... sort of like "if the time is X" and "the temperature in Siam is 52 degrees" and "Our shipping partner in the far east has just shipped 50,000 widgets" -- then send them an email... or invoke some code which does something like that...
Or perhaps, a connected web search just returned a new web page containing specific search terms -- now run some code to process that page in some way, and return the results formatted to some format...
The possibilities are endless...
Observation: There's not just code that lives online -- but there are all sorts of conditions, other than http requests and pre-scheduled time slots -- that could cause code to be invoked, for one reason or another...
Perhaps there's a future business for creating a control panel for users to invoke their online code -- in response to different types of events/sets of conditions -- occuring in the real and/or digital world...
Anyway, once again, great idea for online cron jobs -- and I wish you all of the success in the world with your business!
This is why we have CloudWatch Events (now called EventBridge).
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/W...
https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-...
OK, first let's define "serverless" -- "serverless" in this context means "code still runs on a computer" -- but that computer is (usually, but not always!) stripped of many of the usual resources typically associated with having an "online server", which could (but doesn't have to!) include the stripping away of an Operating System (at least, one visible to the running program), API calls, file system, system files, etc., etc.
But AWS Lambda code still runs on a computer somewhere -- and that computer is connected to the Internet. The idea of having remote code running on a computer over a network -- is not a new one in computing -- it's a very old one -- so this part of things I am not describing!
I am describing, at a high-level, the invokation possibilites for that code.
>This is why we have CloudWatch Events (now called EventBridge).
Yes, Amazon has its own message bus system (call it a "message bus", call it a "message broker" -- https://en.wikipedia.org/wiki/Message_broker -- note the list of other message broker software -- this idea is also not a new one!) whereby two parties using that system can set up what Amazon calls "events" (result of a message traversing that infrastructure).
There's nothing wrong with that -- but I search for something more generic, more global, more not-invented-yet...
I search for a way that a single user (not a pair -- one required to set up an event producer, one required to set up an event consumer) could, if the single user wanted to, set up an event for themselves -- which would run their code (or perform some functionality) -- as a result of some change somewhere in the global internet...
For example, let's say I'm interested in "Robotics".
And somebody, somewhere on the Internet -- puts up a new web page about "Robotics".
Well, this person, whoever they are -- is not going to explicitly code an AWS generator and subsequently publish/send an "Event" to me, especially if one of us, but more likely, both of us, are not on Amazon's system, right?
So I think about how the above scenario might work in a future online community.
AWS is great for what it does -- and it gets us a long way to that idea -- but it doesn't get us ALL of the way there...
That was the point of the abstract thought behind my message...