Sometimes when working with new technology it's easy to focus on the implementation details and the minutiae of simply: how do I get this to work. Obviously, with serverless (as with all new technologies) there are a lot of nuts-and-bolts basics to figure out. It's also true that the community is still new and we're still coalescing around the "right" way to do things. There are a lot of interesting approaches and philosophies emerging, and I'll leave it to brighter minds than mine to figure out the patterns and solutions that we should gravitate toward.

Rather, I want to stop and look ahead at the path before us; to set aside, for a minute, the immediate task of ramping up on serverless architectures and think about where this all could lead.

Serverless is rapidly approaching it's heyday. Companies of all sizes and across many industries are turning to serverless. And while many factors have led them to serverless, ultimately it's the same story as with any significant technology shift: it enables us to do more. Better, quicker, cheaper... you name it. As I think is often the case, enablement creates change. Was cost preventing you from running a low-throughput service? Run serverless for pennies. Is your traffic bursty and unpredictable? Scale dynamically without tons of capacity planning. Need to build for massive scale? Serverless is, at least in theory, any easy way to do that.

So if, as I predict, serverless drives significant changes in the way we consume infrastructure, what can we expect?

There are two patterns in modern application development, that serverless is well suited to support.

Asynchronous, evented workloads

Whether working through a queue of non-realtime requests or parallelizing large workloads, a lot of computing jobs fit well into an asynchronous model. Serverless absolves you of the need to overprovision -- keeping your utilization rates up and your costs down without sacrificing availability. And the ability for new compute capacity to scale up in seconds means that you can parallelize large job bursts for essentially the same cost.

Evented architectures have been around for awhile, but anyone who has managed a message bus or Kafka stream would probably admit that it's not always easy. Serverless enables a much broader adoption by reducing the complexity of implementing and managing an evented system. Function products like AWS Lambda are inherently designed around responding to events. This approach fulfills one of the long-time goals of the old message bus: allowing developers (or teams) to break apart complex applications and be responsible for more easily maintainable components.

If enablement really does drive change, we can expect a growing interest in event-driven architectures backed by serverless infrastructure.

(Almost) All Web Requests

Fundamentally, serverless infrastructure does well with short-lived transactions and unpredictable traffic. If you set aside Netflix video streaming, static assets, and the occasional need for long-lived connections, it's safe to say that the majority of compute-driven web traffic is inherently composed of short-lived request-response cycles. This traffic fluctuates by everything from time of day to what's at the top of Reddit at the moment, so traffic continuously scales up and down. Enter serverless.

Serverless is an ideal fit for this traffic. So why hasn't it taken over the market? I'd point to ecosystem maturity as the culprit. We have decades of experience building applications for servers. And whether you're running bare metal, VMs, or containers, you're essentially still running a server, until, with serverless, we completely abstract it away. Now your favorite web framework doesn't work. The tools you use don't work. Local development doesn't work. There are some assumptions we've built into the very fabric of our engineering ecosystem that we're going to need to shake.

The Future

The key point here is that we're at the beginning of the serverless paradigm shift. Many are already seeing benefits from serverless-based evented workflows, but soon people will also start to see real value from building serverless-base request/response apps. When that happens, serverless could power (almost) the whole internet.