What is serverless computing?

When it comes to building applications, developers normally have a host of other server management tasks they need to carry out in order to deploy their code, such as defining resources for processing and storage, patching, load balancing, and more. All of these extra items lead to longer provisioning times and additional operational overhead that ultimately slows down development teams. 

Serverless computing attempts to provide an invisible “serverless” experience for developers, eliminating the need to think about servers or anything an application might need to run. Instead, the service provider does all the work behind the scenes to ensure you have the resources to execute your code and meet requirements without being charged for idle capacity. 

Think of serverless like getting water to your home. You could dig your own well, test the water quality, and install and maintain all the external plumbing needed to run it into the house. Or, you can connect to your city’s main water supply. You just turn the water tap and get as much water as you want exactly when you need it, and the city sends you a monthly bill for the exact amount of water you consume. 

Similarly, cloud providers automatically spin up the infrastructure resources and runtime environments needed to execute your serverless apps and automatically scale back down to zero when the execution is complete. Typically, you are charged based on the resources during the execution time. However, this can vary depending on the service and the vendor. 

But wait, don’t other types of cloud computing provide on-demand resources on a pay-as-you-go basis? It’s true that cloud service models like Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) also provide on-demand access to computing resources. 

However, the cloud infrastructure allocated to you remains active even if you’re not using it. It’s also your responsibility to scale server capacity or configure your applications to scale up or down in response to user demand. 

Serverless architectures, on the other hand, are event-driven. Under this model, the provider only gives you resources when an event triggers your code to run and will scale instantly and automatically to requests.

Within serverless cloud computing, there are generally two types of services: Function as a Service (FaaS) and Backend as a Service (BaaS). 

• FaaS provides the computing resources needed to execute application logic in response to requests. These pieces of logic (or functions) are run in containers that are fully managed by the cloud service provider. Serverless applications are typically broken into single functions that perform one action in response to an event. 
• BaaS delivers the entire backend functionality of web or mobile applications as a service, such as authentication services, database management, cloud storage, push notifications, and hosting. BaaS also removes the need to manage servers, containers, or virtual machines. 

Within development, the term “serverless” is usually used to describe FaaS offerings. However, it’s important to note that FaaS is technically a subset of serverless technology. Serverless computing includes any type of service where the server management, configuration, scaling, and billing are abstracted from the end user. This can include databases, storage, event streaming, messaging, and API gateways. 

Some of the most common and emerging serverless computing examples include:

• Use case: Seamlessly sync leads/customers between different business applications (Example, CRM to marketing automation)
• Serverless solution: An HTTP-triggered Cloud Run function receives webhooks from the source system (Example, Salesforce), transforms the data, and calls the destination system's API (Example, HubSpot), often using Secret Manager for credentials
• Google Cloud serverless products: Cloud Run functions and Secret Manager

• Use case: Automate the generation and distribution of routine reports
• Serverless solution: A Cloud Scheduler job triggers a Cloud Run function through Pub/Sub daily; the function queries a data warehouse (Example, BigQuery), processes the data into a report, and sends it through an email API
• Google Cloud serverless products: Cloud Scheduler, Pub/Sub, Cloud Run functions, and BigQuery

• Use case: Reduce cloud costs by automatically identifying and managing idle compute resources
• Serverless solution: A nightly Cloud Scheduler job triggers a Cloud Run function through Pub/Sub; this function uses the Compute Engine API and Cloud Monitoring to identify idle instances and automatically stops or deletes them, logging actions to Cloud Logging
• Google Cloud serverless products: Cloud Scheduler, Pub/Sub, Cloud Run functions, Cloud Monitoring, and Cloud Logging

• Use case: Process and enrich high-volume streaming data (Example, user activity) for immediate insights and actions
• Serverless solution: User clickstream events are streamed to Pub/Sub; a Cloud Run function (or Cloud Run service) consumes these events, enriches them with data from Firestore, and then publishes the enriched data to another Pub/Sub topic for real-time analytics in BigQuery or personalized recommendations
• Google Cloud serverless products: Pub/Sub, Cloud Run functions, Cloud Run, Firestore, and BigQuery

• Use case: Automate the build, test, and deployment of microservices upon code changes
• Serverless solution: A Cloud Build trigger monitors a Git repository (Example, Cloud Source Repositories); upon code commit, Cloud Build runs tests, builds a container image to Artifact Registry, and automatically deploys the new version to Cloud Run
• Google Cloud serverless products: Cloud Build, Cloud Run, Artifact Registry, and Cloud Source Repositories

• Use case: Automatically generate optimized image variants (Example, thumbnails, different formats) upon upload
• Serverless solution: A Cloud Run function is activated when a new image is uploaded to a Cloud Storage bucket; this function processes the image (resizing, format conversion), saves the new versions back to Cloud Storage, and updates metadata in Firestore
• Google Cloud serverless products: Cloud Storage, Cloud Run functions, and Firestore

• Use case: Perform real-time AI inference using LLMs such as Lllama 3.1, Gemma 2, Mistral, and more
• Serverless solution: Cloud Run integrates with AI models such as Gemini API, Vertex AI endpoints, or models hosted on a GPU-enabled Cloud Run service; it can also acts as a scalable API endpoint and host AI agents
• GCP serverless products: Cloud Run, Cloud Storage, Firestore

One of the biggest disadvantages of serverless computing is that it is still a relatively new technology. As a result, it is not yet suitable to meet all potential use cases. 

It’s also clear that some of the current weaknesses that exist will be solved over time as serverless computing continues to evolve. In particular, a lot of work is already being done on open source implementations of serverless and finding ways to make cloud services more open to make solutions portable across different platforms and environments. 

• Limited use case suitability: Serverless architectures are not always suitable for applications with specific requirements, such as long-running processes or very low latency needs
• Performance constraints: Serverless functions may experience cold starts (delayed initial execution) and may have limitations on execution time and memory
• Vendor lock-in: Migrating serverless applications between cloud providers can be complex due to differences in APIs and configurations
• Reduced server visibility: Developers have limited visibility into the underlying infrastructure, making it difficult to troubleshoot performance issues or optimize resource utilization
• Slow startup: Serverless functions can sometimes experience a "cold start" where there is a delay in invoking the function, which can impact latency