Static Site Post Scheduler: Using AWS Lambda and Serverless to Schedule Blog Posts
serverless.com
serverless.com
Adding the cognitive burden of "serverless" and/or lambda just to schedule seems to complicate something that isn't very complicated. Its almost like an invented problem.
That said, long live this static site generator movement.
I'm betting this movement will continue to grow which is why I'm bootstrapping https://www.remarkbox.com (comments-as-a-service)
1. I can keep track changes with git 2. I can host them on Github pages for FREE 3. I own the content 4. More flexible
In fact I've been really annoyed with all the boilerplate code and extensions I need to deal with in order to have a "usable" workflow set up, I almost thought about moving back to free blog services like medium, tumblr, wordpress, etc. but the only reasons I can't are the ones I mentioned above.
Wordpress is simple from an end user perspective.
Services like medium and tumblr hide the complexity from its users. Its a trade off.
But my point was it's not just about "simplifying the stack". You said "the allure of a static site or a static blog is to simplify the stack;", but the thing is, not everyone thinks that way.
Wordpress and co are easy, but they're fundamentally much more complex than static sites.
Jekyll is quite simple, but it can be hard to use in comparison.
This project came out of the need from our content team needing to publish content late at night and when people are out of office =)
Check out the code https://github.com/serverless/post-scheduler/blob/master/han... this serverless service is just 2 functions that get deployed. It's a set it and forget it service =)
I suppose my original perspective was coming from a one-person operation.
After all, you can argue that the publishing-side stack is anyway very complex: it includes e.g. the Github UI, if one makes edits using the Github UI.
Or use a CI cron running daily?
The other lambda fires on a cron job https://github.com/serverless/post-scheduler#cron-job-archit...
In essence, it's a return to the "cgi-bin" model of scripting, where you write a script that only runs for the lifetime of one request, and then a web server will spin it up to respond to a relevant request and it'll terminate at the end of that request.
The only differences in the modern instantiation of the concept, are that:
1. the "cgi-bin" directory is a mounted object store, common to an entire cluster; and
2. there's some fancy preloading logic that lets Lambda functions stay "hot" between calls to them, so that they can run very quickly. (Sort of like Phusion Passenger does for Ruby code, except with enough isolation to make it safe for multitenant environments. Heroku's old Alpine stack might be a better comparison.)
There's no notion of uptime, provisioning or managing Web sites when using Web sites; but the operators of the Web site certainly have to tackle such things.
Likewise, I'm sure the operators of AWS lambda are very much concerned about such things, even if the users aren't.
In that sense, wordpress.com is "serverless".
Hosted WordPress is SaaS but not FaaS.
Edit: My backyard is filled with old rocket ships, so I am an expert on this subject :-)
In theory yes. I could provision a new function with an exact cron schedule to run once and then tear itself down.
In practice, this is a lot of extra logic to write to achieve this and would also potentially make own AWS account rather messy.
The hourly cron runs about 720 times a month which is far below the 1,000,000 free invocations that lambda provides under their free tier.
1. fire off AWS Step function on new post to S3 bucket
2. read delay / schedule time in metadata from (assumable) markdown post
3. trigger AWS Step Function using the Wait State defined based on read value from 2.
4. As part of Step Function: After Wait State -> Execute Lambda to publish post.
Note: 3) requires setting variable time in Wait State based on environment. Haven't read up so don't know if that's possible, but guess it should be.
This looks like a great alternative solution!
Haven't messed around with step functions yet but was looking into it today after I found this https://www.youtube.com/watch?v=9MKL5Jr2zZ4&t=226s
Are you using step functions for other flows?
If you host using Netlify you can create a build hook to just curl. You could even use Cronitor for a free cron.
Although in my case, I host my Jekyll based site on my own server and just run a daily build via local cron.
The workflow to post anything (present or scheduled) is nothing more than a single git push to get the new content on the server.
It's as simple as can be. #serversforlife
To which I don't understand the appeal of serverless besides having no servers lol.
So it's up to you where your code runs =)
And paying Amazon for the privilege of doing so!
Well done... golf clap
> The hourly cron runs about 720 times a month which is far below the 1,000,000 free invocations that lambda provides under their free tier.
This entire service (the 2 functions & 1 dynamo table) should run well under the AWS free tier. see https://aws.amazon.com/free/
This project greatly simplifies how we publish content in an elegant out of sight out of mind way.
Before, if someone was out of town, we would need to rely on others to push the merge button on posts for us. Now, the robots do it for us!
Avoiding AWS based solutions to "not rely on others" is like using a kerosene lamp in the center of Manhattan. You may be more self sufficient, but.... why?
... as for self-sufficiency, why not? You're trading freedom and independence for serfdom in Amazon's little kingdom. They'll seduce you with shit exactly like this -- stringing together pointless, useless services to achieve an end that in actuality requires 999999999% less machinery than what they sold you -- to make sure your next project is with them and all their comfy little tools at something 2x to 3x the price. The collective knowledge of running servers represented by a federated, disparate group of specialists slowly drains away from public access, only to re-coalesce behind private walls to enrich a bunch of greedy, already-rich fucks instead of the general public. (You can already see this in the declining quality of google results for technical queries)
Meanwhile lots of good admin guys lose their jobs and the world of software development continues its transformation into a cesspool of spoiled brat devs begging, neigh CRYING for Bezos/Nadella/etc to wipe their ass for them.
Welcome to the future! I'll take my self-sufficiency...
AWS isn't built for little static sites. It is built to host Amazon. And others likewise as big. The ability to do neat toys like this at a low cost, utilizing far more machinery than you would ever need to for such small project, is a happy byproduct.
> Meanwhile lots of good admin guys lose their jobs
Don't go all union-y on me! Frictional Unemployment is unavoidable. The reality is that services like AWS free up all those clearly intelligent (by virtue of being "good") admins to utilize their intellect elsewhere. We live in the age of the STEM shortage. If you can work a computer and can be described as "good", I won't worry for you.
FWIW, it's "nay" not "neigh"
Well, according to pingdom I hit 99.98% uptime with the dozen-or-so cheap little DO boxes I run for my firm's infrastructure. That's playing the dual roles of sole developer and sole support on those systems. My data pipeline collects records from hundreds of deployments worldwide, through all manner of diverse corporate IT environments. It really isn't that hard.
I'll agree with your points on frictional unemployment when the thing displacing them represents actual forward progress. AWS is a land grab, not progress.