What is serverless computing?
Serverless is a cloud computing execution model that provisions computing resources on demand, and offloads all responsibility for common infrastructure management tasks (e.g., scaling, scheduling, patching, provisioning, etc.) to cloud providers and tools, allowing engineers to focus their time and effort on the business logic specific to their applications or process.
The most useful way to define and understand serverless is focusing on the handful of core attributes that distinguish serverless computing from other compute models, namely:
- The serverless model requires no management and operation of infrastructure, giving developers more time to optimize code and develop innovative new features and functionality
- Serverless computing runs code on-demand only, typically in a stateless container, on a per-request basis, and scales transparently with the number of requests being served.
- Serverless computing enables end users to pay only for resources being used, never paying for idle capacity.
Amazon Web Services introduced serverless in 2014 with AWS Lambda; today every leading cloud service provider offers a serverless platform including Azure (Azure Functions), Google Cloud (Google Cloud Functions) and IBM Cloud (IBM Cloud Code Engine). Together with microservices and containers, serverless forms a triumvirate of technologies typically considered to be at the core of cloud-native application development.
Are there servers in serverless computing?
Perhaps the biggest controversy associated with serverless computing is not around its value, use cases, or which vendor's serverless frameworks are the right fit for specific serverless applications, but rather the name itself.
There are most definitely servers in serverless computing. The term "serverless" persists because it describes the customer's experience of servers: They're essentially invisible, because the customer doesn't see them, manage them, or interact with them in any way.
Serverless vs. FaaS
Serverless and Functions-as-a-Service (FaaS) are often conflated with one another. But FaaS is actually a subset of serverless. The reason is that FaaS is the compute paradigm central to serverless, wherein application code or containers run only in response to events or requests. Serverless refers to FaaS plus all the other associated cloud services and resources, such as storage, databases, and networks - for which configuration, management and billing of services are invisible to the user.
IBM's Ashher Syed provides a detailed explanation of serverless and its benefits (6:37):
Serverless pros and cons
While there are many individual technical and business benefits of serverless computing (see Figure 1) there are four primary advantages:
- It enables developers to focus on code, not infrastructure. (It's also a polyglot environment, enabling developers to code in any language or framework - Java, Python, node.js - with which they're comfortable.)
- Customers pay for execution only. Pricing is done on a per-request basis, meaning customer pay only for the resources they use during execution.
- For certain workloads, such as ones that require parallel processing, serverless can be both faster and more cost-effective than other forms of compute.
- Serverless application development platforms provide almost total visibility into system and user times and can aggregate that information systematically
With so much to like about serverless computing, organizations are using it for a wide variety of applications (see Figure 2 below). However, there are certain applications for which serverless is not favorable, and technical and business trade-offs to consider:
- Stable or predictable workloads: FaaS and serverless workloads are designed to scale up and down perfectly in response to workload, offering significant cost savings for spiky workloads. But serverless doesn't offer these savings for workloads characterized by predictable, steady or long-running processes, and managing a traditional server environment might be simpler and more cost-effective.
- Cold starts: Because serverless architectures forgo long-running processes in favor of scaling up and down to zero, they also sometimes need to start up from zero to serve a new request. For certain applications, this delay isn’t much of an impact, but for others - for example, a low-latency financial application - this delay wouldn’t be acceptable.
- Monitoring and debugging: These operational tasks are challenging in any distributed system, and the move to both microservices and serverless architectures (and the combination of the two) has only exacerbated the complexity associated with managing these environments carefully.
- Vendor lock-in: Serverless architectures are designed to take advantage of an ecosystem of managed cloud services and, in terms of architectural models, go the furthest to decouple a workload from something more portable, like a virtual machine (VM) or Docker container. For some companies, deeply integrating with the native managed services of cloud providers is where much of the value of cloud can be found; for other organizations, these patterns represent material lock-in risks that need to be mitigated.
Understanding the serverless stack
Defining serverless as a set of common attributes, instead of an explicit technology, makes it easier to understand how the serverless approach can manifest in other core areas of the stack.
- Functions as a Service (FaaS): Again, FaaS is widely understood as the central/foundational technology in the serverless category. It represents the core compute/processing engine in serverless and sits in the center of most serverless architectures. See "What is FaaS?" for a deeper dive into the technology.
- Serverless databases and storage: Databases (SQL and NoSQL) and storage (particularly object storage) are the foundation of the data layer. A “serverless” approach to these technologies involves transitioning away from provisioning “instances” with defined capacity, connection and query limits - and moving toward models that scale linearly with demand in both infrastructure and pricing.
- Event streaming and messaging: Serverless architectures are well-suited for event-driven and stream-processing workloads most notably open source Apache Kafka event streaming platform.
- API gateways: API gateways act as proxies to web actions and provide HTTP method routing, client ID and secrets, rate limits, CORS, viewing API usage, viewing response logs, and API sharing policies.
Comparing FaaS to PaaS, containers, and VMs
While FaaS, Platform as a Service (PaaS), containers, and virtual machines (VMs) all play a critical role in the serverless ecosystem, FaaS is the most central and most definitional; because of that it’s worth exploring how FaaS differs from other common models of compute on the market today across the following key attributes:
- Provisioning time: Milliseconds, compared to minutes and hours for the other models.
- Ongoing administration: None, compared to a sliding scale from easy to hard for PaaS, containers, and VMs respectively.
- Elastic scaling: Instant and inherent, compared to the other models which offer automatic—but slow—scaling that requires careful tuning of auto-scaling rules. Notably, serverless autoscales to zero - that is, to no instances, when none are called.
- Capacity planning: None required, compared to the other models requiring a mix of some automatic scaling and some capacity planning.
- Persistent connections and state: Limited. Serverless is inherently stateless; state must be kept in an external service or resource. The other models can leverage http, keep an open socket or connection for long periods of time, and can store state in memory between calls.
- Maintenance: All maintenance managed by the provider. This is also true for PaaS; containers and VMs require significant maintenance that includes updating/managing operating systems, container images, connections, etc.
- High availability (HA) and disaster recovery (DR): Inherent in the FaaS model with no extra effort or cost. The other models require additional cost and management effort. In the case of both VMs and containers, infrastructure can be restarted automatically.
- Resource utilization: 100% efficient. With serverless resources are never idle—they are invoked only upon request. All other models feature at least some degree of idle capacity.
- Charging granularity and billing: Per blocks of 100 milliseconds, compared to by the hour (and sometimes minute) of other models.
Figure 1: Organizations will continue to invest in serverless. 95 percent of users plan to maintain or increase their serverless investments during the next year. (Source: Source: 'Serverless in the enterprise, 2021')
Use cases and applications
Given its unique combination of attributes and benefits, serverless architectures are well-suited for use cases around microservices, mobile backends, and data and event stream processing.
Serverless and microservices
The most common use case of serverless today is supporting microservices architectures. The microservices model is focused on creating small services that do a single job and communicate with one another using APIs. While microservices can also be built and operated using either PaaS or containers, serverless has gained significant momentum given its attributes around small bits of codes that do one thing, inherent and automatic scaling, rapid provisioning, and a pricing model that never charges for idle capacity.
Any action (or function) in a serverless platform can be turned into a HTTP endpoint ready to be consumed by web clients. When enabled for web, these actions are called web actions. Once you have web actions, you can assemble them into a full-featured API with an API Gateway that brings additional security, OAuth support, rate limiting, and custom domain support.
For hands-on experience with API backends, try the tutorial “Serverless web application and API.”
Serverless is well-suited to working with structured text, audio, image, and video data, around tasks such as data enrichment, transformation, validation, cleansing; PDF processing; audio normalization; image processing (rotation, sharpening, noise reduction, thumbnail generation); optical character recognition (OCR); and video transcoding. For a detailed image process use case, read “How SiteSpirit got 10x faster, at 10% of the cost.”
Massively parallel compute/“Map” operations
Any kind of embarrassingly parallel task is a good use case for a serverless runtime, with each parallelizable task resulting in one action invocation. Sample tasks include everything from data search and processing (specifically Cloud Object Storage), Map(-Reduce) operations and web scraping to hyperparameter tuning, Monte Carlo simulations and genome processing.
For a detailed example, read "How a Monte Carlo simulation ran over 160x faster on a serverless architecture vs. a local machine."
Stream processing workloads
Combining managed Apache Kafka with FaaS and database/storage offers a powerful foundation for real-time buildouts of data pipelines and streaming apps. These architectures are ideally suited for working with all sorts of data stream ingestions (for validation, cleansing, enrichment, transformation), including IoT sensor data, application log data, financial market data and business data streams (from other data sources).
In a recent IBM survey, IT professionals reported using serverless across a wide range of applications, including customer relationship management (CRM), analytics and business intelligence, finance and more. See Figure 2 for a detailed breakdown.
Figure : How serverless is being used. Survey respondents identified over a dozen serverless applications in use. The most commonly cited applications included CRM, data analytics/business intelligence, finance, database, HR, engineering, streaming media and ERP. (Source: Source: 'Serverless in the enterprise, 2021')
Tutorials: Get started with serverless computing
Expand your serverless computing skills with these tutorials:
- Getting started with IBM Cloud Code Engine: Visit our “Hello world” tutorial to see for yourself how easy it is to create and deploy an IBM Cloud Code Engine application.
- Build a container image from source with the Code Engine CLI: The build process uses the buildpacks strategy and stores the image from the build process on Docker Hub. Code Engine supports building from a Dockerfile and Cloud Native Buildpacks
- Run batch jobs: Learn how to run a batch job using the Code Engine console. A job runs one or more instances of your executable code. Unlike applications, which handle HTTP requests, jobs are designed to run one time and exit.
- Serverless web app and eventing for data retrieval and analytics. Create an application to automatically collect GitHub traffic statistics for repositories and provide the foundation for traffic analytics.
- Quick lab: No infrastructure, just code. See the simplicity of serverless: In this 45-minute lab, you'll create an IBM Cloud account and then use Node.js to create an action, an event-based trigger, and a web action.
Serverless and IBM Cloud
A serverless computing model offers a simpler, more cost-effective way of building and operating applications in the cloud. And it can help smooth the way as you modernize your applications on your journey to cloud.
Take the next step:
- Learn about IBM Cloud Code Engine, a pay-as-you-use serverless platform that lets developers deploy their apps using source code, container images or creating batch jobs with no Kubernetes skills needed.
- Explore other IBM products and tools that can be used with IBM Cloud Code Engine, including IBM Watson APIs, Cloudant, Object Storage, and Container Registry.
Get started with an IBM Cloud account today.
Serverless in the enterprise, 2021
New research uncovers insights on the real-world opportunities and challenges of serverless computing.
Intro to IBM Cloud Code Engine
Go beyond functions to run all your containerized workloads - including web apps, microservices, and batch jobs - on this fully managed serverless platform.