Falsehoods programmers believe about Unix time

A while back I blogged a collection of “Falsehoods programmers believe about …“. One of those things was time. Today I came across a nice addition to that – “Falsehoods programmers believe about Unix time“.

These three facts all seem eminently sensible and reasonable, right?
1. Unix time is the number of seconds since 1 January 1970 00:00:00 UTC
2. If I wait exactly one second, Unix time advances by exactly one second
3. Unix time can never go backwards
False, false, false.

All three of these are false and for the same reason – leap seconds. The article provides a nice and easy explanation of how and why that happens.

Welcome to HTTPS

Finally, after years and years of recommending Let’s Encrypt to everyone, this blog has now followed its own advice and moved to HTTPS. All the old links should be automatically redirected as well, so most people probably won’t notice any difference. But if you do, please do let me know.

Container misconceptions

Ricard Bejarano points out a few container misconceptions. I particular like the bit about Swarm as a better option than Kubernetes for individual projects and small setups (1-2 nodes):

Swarm is Docker, Inc.’s orchestrator. It started development five years ago. It’s built into the Docker Engine, which makes it the same to run it on development machines as in production servers.
In my opinion, it is much less powerful than Kubernetes, and I would vote against using it in a business environment.
That said, I’m a happy admin of a single-node Swarm running all of my personal services at home. But that’s it. I wouldn’t use it for anything with more than 1-2 nodes, but for those applications, I feel is the right tool for the job.

faast.js – serverless batch computing made simple

faast.js is a new framework that makes writing serverless functions super easy. Read more about it in this introductory blog post:

Faast.js started as a side project to solve the problem of large scale software testing. Serverless functions seemed like a good fit because they could scale up to perform work in parallel, then scale down to eliminate costs when not being used. Even better, all infrastructure would be managed by the cloud provider. It seemed like a dream come true: a giant computer that could be as big as needed for the job at hand, yet could be rented in 100ms increments.
But trying to build this on AWS Lambda was challenging:
* Complex setup. Lambda throws you into the deep end with IAM roles, permissions, command line tools, web consoles, and special calling conventions. Lambda and other FaaS are oriented towards an event-based processing model, and not optimized for batch processing.
* Primitive package dependency support. Everything has to be packaged up manually in a zip file. Every change to the code or tests requires a manual re-deploy.
* Native packages. Common testing tools like puppeteer are supported only if they are compiled specially for Lambda.
* Persistent infrastructure. Logs, queues, and functions are left behind in the cloud after a job is complete. These incur costs and count towards service limits, so they need to be managed or removed, creating an unnecessary ops burden.
* Developer productivity. Debugging, high quality editor support, and other basic productivity tools are awkward or missing from serverless function development tooling.
Faast.js was born to solve these and many other practical problems, to make serverless batch processing as simple as possible.

And here’s the quick visualization of the architecture for you.