What 15 Minute Lambda Functions Tells Us About the Future of Serverless

Amazon Web Services recently announced that they increased the maximum execution time of Lambda functions from 5 to 15 minutes. In addition to this, they also introduced the new "Applications" menu in the Lambda Console, a tool that aggregates functions, resources, event sources and metrics based on services defined by SAM or CloudFormation templates. With AWS re:Invent just around the corner, I'm sure these announcements are just the tip of the iceberg with regards to AWS's plans for Lambda and its suite of complementary managed services.

While these may seem like incremental improvements to the casual observer, they actually give us an interesting glimpse into the future of serverless computing. Cloud providers, especially AWS, continue to push the limits of what serverless can and should be. In this post, we'll discuss why these two announcements represent significant progress into serverless becoming the dominant force in cloud computing.

The arbitrary limits of serverless

As many have been arguing for quite some time (myself included), most of the limitations of serverless are completely arbitrary. Sure, there may be some technical limitations in the implementation (for now), but things like execution time, memory constraints, latency concerns, and even distributed state, are all solvable problems.

I suspect that most of these limits are imposed due to conscientious capacity planning. Long-running processes that tie up CPU cycles and available memory on virtual instances introduces new provisioning challenges for cloud providers. The serverless promise of, "never pay for idle", switches the risk of over-provisioning from the customer to the cloud provider. This is perhaps one of the biggest benefits of serverless, but nothing is without limits, including the pockets of cloud providers.

Even soft limits, like function concurrency, are imposed in order to avoid maxing out a complex choreography of hardware, memory, network capacity, and available storage. However, 15 minute execution times tell us that AWS has either decided to provision more resources, or has figured out a clever way to stretch resources more efficiently. I would guess it's actually a combination of both. AWS has invested heavily in the development of serverless technology, and I'd assume that 15 minute Lambdas are in response to customers figuring out that FaaS (Functions-as-a-Service) goes well beyond running simple scripts in the cloud.

FaaS is more that just executing a few lines of code

I have little doubt that the vast majority of serverless applications are simply using functions to execute a few lines of a developer's programming language of choice. Whether interacting with a datasource, transforming data from an event, or responding to an API call, FaaS provides us with the ability to run our code without the need to provision servers. As powerful a concept this is, there's actually much more to it. Lambda functions are basically just mini-servers (or containers), capable of executing any properly compiled binary for its corresponding runtime.

There are plenty of complex, single-threaded processing tasks that require dedicated resources to run for several minutes (or even hours) to complete. Serverless is perfect for fanning-out and scaling tasks that can be run in parallel, but a 12 minute video transcoding task was beyond its capabilities. This meant provisioning enough virtual machines or containers to handle some fixed level of processing capacity. We could certainly add more complexity by implementing some sort of auto-scaling, but that takes time to configure, and would be slow to scale both up and down to meet demand. This leads to a combination of idle resources and delayed processing.

15 minute Lambda executions obviously begin to change the math for some of these longer running tasks. Now we can spin up hundreds of these "mini-servers", within just a few seconds, to perform processing tasks with perfectly planned capacity and resource utilization. And, of course, we also no longer need to worry about maintaining the servers or containers that they run on. Plus we get auto-scaling for free. 😎 I'm not sure I can overstate the significance of this and the simplicity it creates for development teams.

Scalable nanoservices are redefining microservices

Now that we know why 15 minute Lambdas are significant, let's discuss why an aggregate view of a few functions and resources is such a big deal. A microservices architecture is generally the preferred method for building distributed systems. The separation of resources, along with their independent deployability, make them much easier to manage and scale.

Traditional microservices, however, at least in terms of their scalability, are monolithic. This means that an entire service is typically tied to the compute resources it runs on. In order to increase the capacity of a service, you either need to scale vertically with more server power, or horizontally across multiple machines. While this works well under most circumstances, there are a number of instances where parts of a service require more resources than the rest do. Depending on the size and requirements of your service, scaling the entire thing becomes overkill at best, and a costly exercise in over-provisioning at worst.

Serverless introduces us to the relatively new concept of nanoservices, which allows us to break our microservices down even further. It could be as small as a single function, or a few functions coupled with a managed service or two, but regardless of its composition, a nanoservice can scale independently of your larger service. This means that services built with serverless become highly scalable and incredibly efficient in terms of leveraging compute resources, but it also means that they become more complex and harder to manage. Ask anyone who has worked with complex serverless applications and they'll tell you that observability is a major challenge.

Tracing in distributed systems has always been a challenge, but the ephemeral nature of serverless functions makes this even more difficult. A number of startups have popped up over the last few years that are trying to address this, but it's been a bit strange to see that AWS and other cloud providers were noticeably absent in this space. AWS has their X-Ray service, of course, but it lacks the sort of holistic view of what you would consider an entire serverless microservice. So why is the new "Applications" menu so important? Because it shows us that AWS is finally taking steps towards helping us visualize and logically organize the ever growing list of systems and services that power our applications. It's nowhere near perfect, but it is much needed progress that will help speed up serverless adoption.

The future of serverless

I've written several times before that serverless wasn't perfect. And I've come across several use cases that serverless just wasn't ready to handle. However, I've also said (in the spirit of Atwood's Law), that "anything that can be written in serverless, will eventually be written in serverless." Everytime I read announcements like the ones above, I feel more and more confident that this statement will come to pass. Whether you're building a simple form submission script, or a complex ETL processing engine that needs to handle hundreds of millions of records in near real-time, serverless can support it.

The future of serverless isn't merely about running short-lived functions in the cloud or gluing together some managed services. Instead, these announcements show us that arbitrary limits and other arguments against serverless are actively being solved for. Yes, servers will always need to exist, but how efficiently we utilize them, and how effectively we orchestrate and understand our applications, will be driven by the serverless paradigm. I, for one, am very excited.