After over a year of time to digest the idea of serverless computing, I've started to wonder why the concept is only compared to functions as a service (FaaS) and not platform as a service (PaaS) as well. It is time to expand the definition of serverless computing.
SEE: AWS vs Microsoft Azure: Understanding the serverless application trend (TechRepublic)
At this point in the relationship between IT Infrastructure and application development, we know the dance well. A developer opens a new project request. Infrastructure asks four questions:
- How much RAM is needed?
- How many CPUs are required?
- How much storage needs provisioning?
- How many IOPS are required?
The truth is that developers shouldn't need to understand infrastructure requirements to that depth. The developer needs to understand the business problem they are solving and the coding tools needed to solve the problem. The desire to fix the broken relationship between developers and infrastructure highlights the appeal of serverless.
Functions as a Service
To date, the concept of serverless equates to event-driven computing. The typical use cases involve the hot new FaaS solutions like AWS Lambda, Google Cloud Functions, or Microsoft Azure Functions. The traditional solutions rely on events to trigger code execution. A typical example is a video encoding workflow.
In the video encoding use case, the uploading of an image file to S3 triggers a Lambda function that encodes the video. The developer's only concern is writing the encoding function. The underlying infrastructure handles the placement of the function within the infrastructure and management of scaling for capacity. The developer focuses on code and the cloud provider worries about servers.
Not every function or service within an application is event driven. Developer advocates for these platforms don't recommend building an entire complex application on FaaS such as Google Cloud Functions. Cloud providers recommend a combination of traditional application platforms alongside FaaS solutions. However, the combination of FaaS and traditional server abstractions bring us full circle to the original problem—developers needing to understand infrastructure. How exactly do you achieve a serverless architecture for an application if developers must define the attributes of a server?
PaaS is Serverless
It seems obvious to me the solution is PaaS. Solutions such as Microsoft Azure App Service and Pivotal Cloud Foundry provide examples of sophisticated serverless models. In the case of Pivotal Cloud Foundry, a developer writes an entire application that may even call FaaS via some API gateway on their laptop. When the application is ready for production, the developer issues a CF Push command and the application deploys to production. The developer doesn't know any of the details of the underlying infrastructure. The underlying PaaS infrastructure management handles scaling.
Regardless of whether it's called PaaS, FaaS, or serverless, the relationship between infrastructure and development requires some abstraction. I'm a firm believer, based on today's technology, that the right level of abstraction is the PaaS layer.
Share your thoughts: Is PaaS a form of serverless compute, or something else? Tell us in the comments.
- AWS Lambda: The smart person's guide (TechRepublic)
- Why VMware's NSX must evolve to keep up in a serverless future (TechRepublic)
- Why OpenStack is the wrong cloud for Red Hat to be building its future on (TechRepublic)
- Cloud-to-client, direct: serverless computing reduces the middle (ZDNet)
- Where AWS is headed: Every function as a managed cloud service (ZDNet)
Keith Townsend is a technology management consultant with more than 15 years of related experience designing, implementing, and managing data center technologies. His areas of expertise include virtualization, networking, and storage solutions for Fortune 500 organizations. He holds a BA in computing and a MS in information technology from DePaul University.