KBall interviews Brian Leroux in a wide-ranging discussion covering “Progressive Bundling” with native ES Modules, building infrastructure as code, and what the future of JamStack and serverless deployment might look like.
This stack was created out of frustration due to the fact that to this day there’s no easy way to have a full email server without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages. We wanted something simple, with no interface and no server management, so we came up with S3-Email. This included AWS SES as our email server (receive and send) and S3 as our database and interface. Then we tied everything together with a bit of code via AWS Lambda.
All of this functionality and the repo is just some JSON, Yaml, and text files. Maybe 2020 really is the year of #nocode… 😉
A story of an internal tool – Replicator. It involves AWS Lambda, one of the hardest things in Computer Science, and Star Trek.
Jean-Luc Picard quotes FTW. I’d love to see this tool open sourced.
LocalStack looks like an excellent way to develop & test your serverless apps without leaving your local host. It appears they are basically mocking 20+ AWS services which is undoubtedly a lot of work and I would expect to be error prone. Is anybody out there using LocalStack on the regular and can let us know if it actually works as advertised?
Johnny, Mat, Jaana, and special guest Stevenson Jean-Pierre discuss serverless in a Go world. What is serverless, what use cases is serverless good for, what are the trade offs, and how do you program with Go differently in the context of serverless?
Serverless doesn’t mean “less” security, instead we should fine-tune our focus area to security implications that accompany a serverless architecture.
If you’re developing serveless functions on Azure, Google or AWS you probably want to make sure you follow these security best practices.
We’re talking with Alex Ellis, the founder of OpenFaaS — serverless functions made simple for Docker and Kubernetes. We talked about the back story and details of OpenFaaS, “the curious case of serverless on Kubernetes,” the landscape of open source serverless platforms, how Alex is leading and building this community, getting involved, and maintainership vs leadership.
Lambcycle is a middleware for lambda functions. It defines a configurable life-cycle and allows you to focus on your application’s logic. It has a “Feature as Plugin” approach, so you can easily create your own plugins or reuse your favorite packages with very little effort 🐑 🛵.
The author goes deep on why Lambcycle solves a serious problem over on Medium.
Now you can easily build, deploy, and distribute Slack apps for free with serverless on ZEIT Now.
We recently built a simple Slack app. The app allows users to type
In this blog post, we will show you exactly how we did it. We will demonstrate how you can easily build, deploy and distribute similar Slack apps for free, leveraging the power of serverless on Now.
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…
Disclaimer: no servers were harmed in the taping of this show. We hosted a special discussion with Jeremy Daly, Kevin Ball, Nick Nisi, and Christopher Hiller on the ideas around serverless, managed services, Functions as a Service (FaaS), micro-services, nano-services, all-the-services!
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.
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.