Serverless is one of the more interesting developments in cloud computing. The serverless cloud story began back in 2014 with Amazon launch of AWS Lambda, but it has more recently become a hot topic with impressive growth predictions. A recent Business Wire report, for example, has estimated a CAGR of 32.7% from 2016 to 2021 for the technology.
A support ecosystem for serverless is also emerging. In three years since launch, no shortage of serverless offerings, open source projects (e.g., Apache OpenWhisk, IronFunctions), books, technical articles, conferences and industry hype have emerged. But despite this rapid advance, serverless is still not well understood.
But, what is all the fuss? Is serverless worthy of the industry buzz it’s generating? More importantly, is ‘traditional’ cloud computing already being displaced by this recent wave of innovation?
The serverless difference
First, the basics – serverless is NOT a resurgence of 1970s-era mainframes aiming to replace servers!
Rather, serverless refers to a cloud service that masks (also called abstracting) the details of the cloud-based processor from its user. Serverless does not mean servers are no longer needed, just that they are not user-specified or controlled.
In a June 2016 article, Badri Janakiraman, developer with ThoughtWorks Studios, explained that “serverless architectures are Internet based systems where the application development does not use the usual server process. Instead they rely solely on a combination of third-party services, client-side logic, and service hosted remote procedure calls (FaaS or Function-as-a-Service).”
The ability to execute code without concern for the underlying server type, configuration or capacity is very attractive to IT operations. Servers are not eliminated; they just remain the service provider’s responsibility.
Currently, infrastructure cloud services such as Amazon EC2 deliver a period of server availability for a specified virtual or physical server model, with a pre-defined configuration and scalable capacity. According to Amazon, with EC2 “You have the choice of multiple instance types, operating systems, and software packages. Amazon EC2 allows you to select a configuration of memory, CPU, instance storage, and the boot partition size that is optimal for your choice of operating system and application.”
In contrast, serverless offers a period of code execution. The AWS Lambda description states:
“AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second. You pay only for the compute time you consume – there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service – all with zero administration.”
Since serverless is a new software model, it could be classified as a type of cloud native platform. Serverless comes close to the definition for Platform as a Service (PaaS), which in ISO/IEC 17788 is defined as: “cloud capabilities type in which the cloud service customer can deploy, manage and run customer-created or customer-acquired applications using one or more programming languages and one or more execution environments supported by the cloud service provider.”
Functions versus applications
Although the serverless offering is usually described as the execution of “functions,” the definition of a function remains imprecise. One type of function is a back-end program (referred to as Backend-as-a-Service, or BaaS); another is task-oriented code (Function-as-a-Service, or FaaS). BaaS can include third-party components such as databases, identity and access management or cybersecurity. FaaS is support for executing application-specific code on a suitable underlying environment.
Serverless services and their functions are not standardized offerings (yet). While Microsoft states that Azure Functions is a solution for running small pieces of code, or “functions,” in the cloud, Google states that applications are constructed from “bite-sized business logic.” IBM Cloud Functions “accelerates development as a set of small, distinct, and independent actions.” With AWS Lambda, Amazon says you can run code for virtually any type of application or backend service.
Functions are event-driven and activated by external triggers. They are also called “ephemeral,” which means the program is short-lived, especially in comparison with traditional applications. To achieve this, functions need to be relatively simple and stateless (i.e., they do not retain knowledge across executions). Functions can be implemented with containers and microservices.
Examples of serverless services
The primary service providers today are Amazon AWS Lambda, Microsoft Azure Functions (available on both Azure’s public and private clouds), Google Cloud Functions (currently a beta release) and IBM Bluemix Cloud Functions (which is based on open source OpenWhisk). Serverless is clearly a competitive offering that major providers believe will be strategic!
The main features of current offerings include execution of simple, single-purpose, stateless functions; various types of event trigger (e.g., a message arrival notification); support for multiple programming languages; integration with other services from the same provider (serverless is not interoperable); and execution time billing. Given reliance on M2M or other short communications, the Internet of Things (IoT) may prove to be a “killer app” for serverless.
Serverless architectures and services are at an early stage of development, deployment and maturation, which restricts serverless to early adopters for now. But going forward, ecosystems are likely to emerge for function development, application integration, container hosting, additional language support and use-case patterns. Serverless Inc., for example, has created the Serverless Framework, an open source project to help with building web, mobile, and IoT applications with FaaS.
The value of the serverless model
For suitable workloads, the serverless service can be cost-effective. First, it reduces the user’s operational involvement, and hence operating costs. Second, it simplifies the developers job by managing the processing platform, which in turn allows the provider to optimize resource use (it will not not leave programs to sit idle for long periods of time. Third, it really is a metered, pay-as-you-go service based on capabilities delivered rather than available resources.
With serverless services, the cloud provider optimizes the infrastructure to matches the dynamic processing demands of the business application. The automation tools to achieve this are more complex than what the typical user would have, and because these are shared, cost can also be shared (as can the expert support staff).
Application developers can take advantage of serverless architectures to increase agility, promote DevOps (or DevNoOps) or make use of third party backend services. Serverless would reduce the time required to get feedback on new application components, leading ultimately to reduced time-to-market for business applications.
Despite these promised benefits, early adoption of new technologies can have drawbacks. For example, activation latency for a function could turn out to be an issue. Diagnosing operational problems may be more complicated when the code is short-lived. Perhaps more importantly, serverless represents a new application architecture that can involve multiple vendors, third-party components and independent development teams, which adds its own level of complexity.
The bottom line
Serverless (aka FaaS) and functions could be the basis for the next generation of cloud native computing. It is about more than servers – it is an early step towards Everything-as-a-Service. As with many emerging technologies, the “proof will be in the putting” but the potential advantages to developers and ops alike are clear.
