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.