How do Cloud Functions work?

Serverless computing is one of the fastest-growing trends of the decade. Cloud Functions is the Function-as-a-Service (FaaS) offerings from Google. Serverless minimizes DevOps complexity while maintaining high elasticity.
With Cloud Functions, you only write the business logic without thinking about infrastructure.

Building blocks

Components of a Cloud Function

1. Trigger
   The entry point of the cloud function. It could be an HTTP request, Pub-sub message, or a Cloud Scheduler event.

2. Configuration
   The runtime configuration for your function. These include values like env variables and max number of parallel executions allowed.

3. Code
   The business logic and the dependencies for your function. The event arguments are passed in the request object of the function.

Common use-cases

1. Integration with 3rd Party Apps
   Interacting with 3rd Party Apps like Slack, SendGrid pretty much any 3rd API.

2. Serverless Backends
   This is a common use-case for mobile where the usage is highly elastic.

3. DevOps triggers
   Triggering a code build in response to a pull request approval.

4. Data processing / ETL
   Basic ETL use cases like file processing as soon as a new file is created. Cloud Function has a Cloud Storage trigger available.

5. Webhooks
   A common use-case for OAuth2 flows like server-side redirections.

Internal Working

Cloud Functions are simple executable Linux Containers.

The lifecycle stages of a Cloud Function

Build

The cloud function is converted to an executable container in the build process. The container is automatically created from the code in the build stage. This container is stored in the Google Container Registry. During execution, the container is pulled from the registry.

Source: Google Cloud

Let’s understand each of the layers.

Operating System
This operating system image to run the function. Maintainance activities like patching and updating are handled by Google.

Runtime
The runtime will be installed on the image during execution. This is the same runtime configured during creation.

Functions Framework
This is the piece that actually runs your code (also open-source) on the trigger.

Function Code and dependencies
This is the actual business logic function we want to run as a response to the trigger.

Role of Functions Framework

It acts as a mediator between the trigger and your source code. It abstracts the trigger objects to appropriate req and res objects.

Deploy

We get an executable container at the end of the build stage. On triggering a function, a container is deployed to an instance. An instance could be Linux / Windows machine.

Run

The container execution occurs in the following steps:

1. Download and Deploy the container image

2. Run the container with arguments.

The above steps are necessary for each execution.
Now let’s say we are making a fresh call to the function. The executor will look for an instance that already has this container(“hot start”).
If it cannot find such an instance, then it has to request an instance and deploy the container. As a result, a delay in form of latency is introduced to spin up the container. This is also known as a “cold” start.

Limitations

Cloud Functions greatly make your project needs serverless. However, there are some important limitations to be mindful of.

1. Max Execution Time
   The maximum duration for which a cloud function can run is 9 mins. The limits are frequently updated, so be sure to check the latest limits.

2. Memory Limit
   The runtime memory limits are ranging from 128 Mb to 2 Gb.

3. Number of accessible CPU cores
   During execution, the function has only one CPU core available. Thus, there are limits to parallel processing use cases. A good practice is to trigger additional cloud functions for parallel processing.

Best Practices

1. Think like a Functional Programmer
   Functional Programming concepts like Immutability and Pure Functions would prove to be beneficial here.

2. Remove unwanted files and dependencies
   Decreasing container size helps reduce cold start time and overall resource usage. A case study shows that reducing dependencies gave helped 2x in reducing cold start times.

3. Test with Functions Framework
   The Functions Framework runs the business logic at runtime. For local development and testing make use of Functions Framework.