John Demian lays out Lambda’s runtime environment limitations for your consideration.

I gave Lambda a chance to impress me after Pam Selle gave us the hard sell, but I hit up against the 5-minute function execution timeout. Needless to say I was not impressed.

It’s nice to see they’ve increased that to 15 minutes, but there are other constraints to consider as well.

One of the most exciting announcements from last week’s AWS re:Invent was Firecracker — an open source project that delivers the speed of containers with the security of VMs.

Firecracker’s focus is transient and short-lived processes, so it differs from containers in that it’s optimized for startup speed.

Why can’t we use containers? The answer is simple — slower cold start. While LXC and Docker are certainly faster and lighter than full-blown virtual machines, they still don’t match the speed expected by functions.

There are also some security wins with how Firecracker is architected:

Firecracker takes a radically different approach to isolation. It takes advantage of the acceleration from KVM, which is built into every Linux Kernel with version 4.14 or above. KVM, the Kernel Virtual Machine, is a type-1 hypervisor that works in tandem with the hardware virtualization capabilities exposed by Intel and AMD.

There’s a lot to be intrigued by here. We should probably line up an episode on Firecracker. In the meantime, click through to go deeper on the topic.

(READ ALONG IN YOUR FAVORITE MOVIE TRAILER VOICE) … In a world where serverless is still being demystified, CloudFlare, a company who’s focused on pushing things to the edge, launches a game changer for not only serverless, but for cloud computing at large. Unlike every other cloud computing platforms out there, this platform called Workers, doesn’t use containers or virtual machines. This, is the future of serverless and cloud computing. Join Zach Bloom in this epic tale as he tries to convince you why.

OK, seriously — this news bubbled up to me enough times that I just had to share it. Here’s the tee up of the problem they faced — how they’re going about solving it is truly a great read.

Two years ago we had a problem. We were limited in how many features and options we could build in-house, we needed a way for customers to be able to build for themselves. We set out to find a way to let people write code on our servers deployed around the world (we had a little over a hundred data centers then, 155 as of this writing). Our system needed to run untrusted code securely, with low overhead. We sit in front of ten million sites and process millions and millions of requests per second, it also had to run very very quickly…

Here’s a new way of hosting server-side rendered single-page applications. Instead of paying for servers and doing the tedious work of keeping them safe and up-to-date, deploy your Nuxt.js app to AWS Lambda with Serverless instead.

Follow the walkthrough, or jump straight to the code.

If you’re using EC2 and paying big bucks to do so, you owe it to yourself to check out AutoSpotting:

Once installed and enabled by tagging existing on-demand AutoScaling groups, AutoSpotting gradually replaces their on-demand instances with spot instances that are usually much cheaper, at least as large and identically configured to the group’s members, without changing the group configuration in any way. For your peace of mind, you can also keep running a configurable number of on-demand instances given as percentage or absolute number.

It’s often hard for me to wrap my head around a technology/service until I see some concrete use cases for it. In this article, Rohit does a good job of laying out a bunch of serverless use cases. Maybe one or two will compel you to dig deeper.

One of the oft-toted virtues of serverless infrastructure is metered pricing. Like, super-metered pricing down to function invocations and memory use. That’s awesome, but also harder to predict than flat-rate (or at least flatter-rate) pricing. In this article, The New Stack goes deep into the weeds trying to estimate actual serverless costs across providers.

If you’re building a serverless application to run at scale, then read this post from Paul Johnston on Medium…

Within the community we’ve been debating the best practices for many years, but there are a few that have been relatively accepted for most of that time.

Most serverless practitioners who subscribe to these accepted practices work at scale. The promise of serverless plays out mostly at both high scale and bursty workloads rather than at a relatively low level, so a lot of these best practices come from the scale angle e.g. Nordstrom in retail and iRobot in IoT. If you’re not aiming to scale that far, then you can probably get away without following these best practices anyway.

John Demian:

This tutorial will cover the basics of both the front-end contact form, with vanilla JavaScript, and the serverless back end hosted on AWS Lambda.

A contact form seems like the perfect scope for a serverless tutorial like this one.

If you’ve heard of serverless’ virtues, but have never taken that first step toward trying it out, this crash course is for you. Here’s how you might feel by the end:

What a journey. You have now witnessed the transition from traditional web development into the serverless revolution. With these simple tools we now have everything we need to create awesome, scalable, and reliable applications.

In my humble opinion, this is all still too much work for most of us to go through. AWS needs some serious competition in this space. Said competition is undoubtedly on the way.

Why is serverless a good fit for status page systems? According to the author:

• It eases your pain caused by the scaling / availability issues. It is terrible if your service is down AND heavy traffic from stuck users stops your status page.
• It enables you to pay only for what you use. A status page only occasionally gets huge traffic. The system takes only $1 per 30,000 visitors and almost $0 if no visitors.

Makes sense to me. 💯

A new microsite by Chris Coyier.

Let’s get one thing out of the way: it still involves servers, so that word serverless might feel a bit disingenuous. It’s actually a new way to pay for and work with servers that, in many cases, is cheaper and easier than buying and managing your own servers.

In addition to a nice description of what Serverless is (and isn’t), the site includes lists of service providers, ideas about things you could build, and related resources.