Serverless software architectures have generated a lot of interest. How much interest? Like, 2000 people at a conference breakout session —that level of interest. The photo below shows Datadog devops evangelist Matt Williams delivering a session about Lambda at AWS re:Invent last December. The jam-packed venue was originally designed to house “Phantom of the Opera.”
Hyun Auh I’ve been going to tech conferences for 25 years, and I have never been to a breakout that required a mezzanine before. Serverless is catching like wildfire.
But why? What does serverless really mean, given that we all know there is indeed a piece of hardware underneath the hood somewhere? Is function-as-a-service different from serverless? What are the mechanics of services such as AWS Lambda, IBM OpenWhisk, Azure Functions, and Google Cloud Functions? And where is this all going?
Serverless vs. function-as-a-service
I was among the attendees at Serverlessconf in Austin recently, and among the most striking things about the keynote presentations were how many different definitions of serverless are being tossed around. That’s a sign of how early it is in the lifecycle of this technology, but generally speaking, most people involved in this movement would agree that “serverless” refers to the software architecture, whereas “function-as-a-service” (FaaS) describes the key mechanism by which a developer implements the business logic in that architecture.
For example, you could run a static HTML website on the AWS S3 service, and that would qualify as serverless (architecture). But without business logic to react to user interactions with customized data, that site doesn’t do a whole lot. That’s where FaaS runtimes from the Big Four cloud providers (AWS, IBM, Microsoft, and Google) and some open source players (e.g. Iron.io and Fission) come in.
The best definition of FaaS I’ve seen came courtesy of Serverless Framework CEO Austen Collins, whose company might be the hottest startup in this space. For Collins, the defining characteristics of FaaS are illustrated by this diagram:
Austen Collins The ability to build microservices that react to events, that auto-scale, that you pay for per-execution, and that take advantage of a larger ecosystem of services like Amazon DynamoDB or IBM Watson is what FaaS platforms provide to developers. Some of those goodies, namely the ecosystem and the microservices approach, FaaS platforms share with the container world. Once you peer inside and understand how the FaaS platforms work, it becomes clear why those similarities exists.
FaaS platform inner workings
It’s helpful to think about FaaS runtimes in a historical context, in terms of how long it has taken to make a unit of compute available to a piece of code. In the early 1990s, we only had bare metal hardware available to run our code, and getting a new unit of compute took months. With the invention of the hypervisor, virtualization shrunk that down to minutes. Using different Linux kernel resource separation techniques that don’t require the overhead of a hypervisor, containers now give us a compute unit in seconds.
How do FaaS platforms get that down to milliseconds? Imagine an assembly line of already spun-up containers that have language runtimes in them, like Node.js or Python, but no business logic code yet.
When an event gets triggered, and only then, the function housing the business logic you wrote to respond to that event is read from disk and inserted into the pre-warmed container with the appropriate language already inside. Your function executes, your code is removed, and that same container is available to be reused for the next event.
There are variations on that sequence, of course, including keeping your code in a fully warmed container for the next time that same event is handled. But the key concept is that FaaS platforms use containers in a creative way and let you map function executions to specific events. The power comes when you chain those events, such as a database write or an IoT device signal, to create a larger application out of those much smaller components.
Where is all this going?
When viewed through the prism of the Rogers Innovation Adoption Curve, serverless is still a young market, most likely at the beginning of its early adopter phase. But it has some big players behind it (that a traditional IT decision maker wouldn’t get fired for betting on), a healthy number of open source alternatives, and the beginnings of a market for startups providing complimentary tooling.
One intriguing aspect of serverless is its potential to turn the notion of vendor lock-in on its head. Suppose you really like Amazon Polly for voice-to-text but you prefer IBM Watson for text sentiment analysis. Your front-end application could record spoken words, send the recording to a Polly function on AWS, and send the resulting text to Watson. So instead of being locked into a single vendor or ecosystem, you can embrace finding exactly the right tool for the specific job. When you build with function-as-a-service, the individual pieces are small enough and loosely coupled enough to pick and choose each provider as you please.
At Serverlessconf, companies like iRobot, Nordstrom, and Capital One discussed how they are using the technology successfully today, proving that it is not just for startups but for mature enterprises too. While many of these early adopters aren’t using serverless for user facing workloads yet, the day when you interact with a serverless application is coming soon. At the rate this technology is moving, it might have been yesterday.