Thinking Serverless (Big and Small)

I've been reading and writing a lot of about serverless lately, and one of the things I realized, is that most articles talk about how SCALABLE serverless architectures are. This, of course, is one of the major benefits of using serverless to build your applications. The ability to scale to thousands of concurrent requests per second without needing to manage your own servers, is simply amazing. 🙌

However, not needing to manage any servers has other benefits beyond the capabilities to achieve web scale. Having on-demand compute space also make serverless the perfect candidate for smaller workloads. In this post, let's discuss how we can utilize serverless to handle our "less than unicorn 🦄" services and the benefits this can bring.

Two Serverless Extremes

So what you're saying essentially is, is that with infinite space, which extends beyond perpetual bigness, there's also infinite smallness? ~ Arnold Poindexter 🤓

If there's one thing you can take away from Revenge of the Nerds II (beyond how to hotwire the Hotel Coral Essex sign), is that perpetual bigness exists simultaneously with perpetual smallness. Or in serverless terms, infinitely scalable functions can coexist with infinitely idle ones. 😴

As Harold Wormser explains, "Take an asymptotic line and extend it outward."  😃

But seriously, my point is that low-traffic, low frequency functions are just as practical with serverless as are massively scalable deployments. One of the main benefits (and promises) of serverless is that you don't pay for idle time. You only incur fees when your code is actually running. If you couple this with the scalability aspect, using serverless to perform infrequent tasks (especially ones with spiky traffic) saves you from needing to provision extra capacity and waste money on all that unused compute power.

Think smaller 🤔

"We're running 150 Lambda functions that connect all of our microservices with event triggers for Kinesis, SNS, S3, SQS and DynamoDB and we're handle over a gazillion web requests each hour." ~ Some Cloud Architect crushing it with Serverless

I've seen some of these architectures and I've worked with some of them. The event-driven orchestration of processes, near real-time messaging channels, built-in automatic retries, and all the other cool things that the AWS team thought of, makes building large, distributed, massively scalable architectures like this so much easier. But not every application needs to be this scalable, or distributed, or… this cool. 😎

I love reading articles about people who are pushing the limits of serverless and finding new and interesting ways to solve real world problems with it. But I love serverless in generally, and while the aforementioned deployments are amazing, I'm also interested in how people are using serverless to solve simpler problems.

Where are the stories of the support tech at a small manufacturing company that automated a Lambda function to send daily production numbers to management? Or the small marketing agency that used API Gateway and a Lambda function to merge information from a lead form, send it to multiple marketing automation platforms, and return a protected download to the customer? Or a photographer that uploads 3,000 wedding photos to S3 and has a Lambda function process, resize, and publish them to a browsable web album in just a few minutes? Or maybe just a simple ETL task that was powered by Lambda to push a few logs into an RDS database each night?

Many of the things I mentioned are the types of custom applications my old web agency used to build for clients all the time. Sure, they aren't the most exciting things we've ever seen, but they are real problems that real small and medium-sized businesses need to solve. And while these applications don't need to support millions of requests per day, serverless would still be my top choice for building these.

Benefits of small (and boring) 😐

There have been a number of "discussions" around the web about whether or not serverless makes sense in certain situations. For example, some argue that steady workloads handled by a pair of EC2 servers might be more "cost effective" than going serverless. There was a great study done about the Economics of Serverless that looked at this question in depth. TLDR; if you have high, steady traffic AND you don't include additional server maintenance costs and fault tolerance, then at certain scales, serverless might be more expensive. But regardless of that argument, the vast majority of infrastructures (even those that handle significant load) are often overprovisioned to handle traffic spikes. Auto-scaling typically isn't fast enough, which requires you to pay for a lot of idle resources.

Serverless certainly provides many benefits for these types of large, heavy-load applications. However, overprovisioning isn't a mutually exclusive problem for applications at high scale. Even running a small EC2 instance to handle some periodic workloads will cost $20 per month and could a) be overkill (like handling low-volume form processing) or b) lack the capacity for performing periodic high capacity tasks (like a nightly ETL job). And while, granted, we're not talking about a lot of money in this example, costs can certainly add up when you start to require different resources for different types of workloads.

From a security standpoint, an organization might not want all of their small jobs running on a single server or to grant access to outside developers. Lots of SMBs are bound by SLAs as well, so even small scale services need to provide some level of redundancy, fault tolerance, and high-availability. Now we're introducing ELBs (Elastic Load Balancers), multiple EC2 instances, probably a VPC, and a deployment process that can automate code delivery to running servers. Our $20 just turned into well over $100. 💰

But what if we used serverless to handle these jobs for us? Let's look at five key benefits:

1. Pay only for what you use

AWS Lambda (and other serverless services) charge you using subsecond metering. If you only use 100ms of compute time a few times an hour, you only pay for that compute time.

2. Zero server maintenance

No server patching or capacity planning needed. Set it and forget it.

3. Continuous scaling

Whether you have 5 requests one hour and then 5 million the next, serverless will automatically scale capacity to meet demand. No ELBs or auto-scaling groups required.

4. Built-in high-availability and fault tolerance

AWS Lambda functions are served up across multiple availability zones. Unlike with a single server (or even a small cluster), your serverless code will remain available (and scalable) even if a major part of the infrastructure fails.

5. Programming language agnostic

AWS Lambda currently supports multiple versions of Node.js, Java, Python, .NET Core and Go. This type of flexibility makes hiring outside resources easier since you are not limited to specific runtime requirements. It also means you can likely migrate existing applications to serverless without rewriting them.

You get a tremendous amount of compute power on-demand. You can separate workloads into different functions and different runtimes for both isolation and security reasons. You can update and experiment with different jobs and tasks without having any effect on other services that would normally be running on the same server. And best of all, you get this for a couple of bucks a month. 🤩

Size doesn't matter 😜

If you ARE using serverless to build small applications or handle periodic workflows, please email me or DM me on Twitter. I'd love to hear about your use cases and how serverless is saving you time and money (and eliminating the 2 AM server outage text messages 🤦🏻‍♂️).

If you are NOT using serverless to handle these types of tasks, I suggest that you give it a go. If you think you can't use serverless, I'd really love to know why. Please send me a note as well.

Good luck with your serverless applications, and I look forward to hearing from you all. 🤘🏻

---

If you're new to serverless, read my post 10 Things You Need To Know When Building Serverless Applications and check out 5 Reasons Why Your Serverless Application Might Be A Security Risk.