Google Cloud Functions
Google Cloud Functions is a serverless execution environment for building and connecting cloud services.
Each Cloud Function runs in its own isolated secure execution context, scales automatically, and has a lifecycle independent from other functions.
It is a function-as-a-service approach.
Use case: Single-purpose, stand-alone code that runs in response to an event (HTTP request, new message on a queue, a new file on a cloud store bucket). Funtions to run quickly (less than 5 minutes).
It is a fully-managed, serverless environment where Google handles infrastructure, operating systems, and runtime environments
Furthermore, provisioning of resources happens automatically in response to events.
This means that a function can scale from a few invocations a day to many millions of invocations without any work from you.
They scale down to zero, so user only pays when they are actually run.
Integrations with other Google Cloud Services
Cloud Functions provides a connective layer of logic that lets you write code to connect and extend cloud services, e.g. listen and respond to a file upload to Cloud Storage, a log change, or an incoming message on a Cloud Pub/Sub topic.
They have access to the Google Service Account credential and are thus seamlessly authenticated with the majority of Google Cloud Platform services.
Cloud Functions are supported by numerous Google Cloud client libraries, which further simplify these integrations.
Events are things that happen within your cloud environment that you might want to take action on (triggers).
Triggers are related to functions in a many to one basis. Every function has one single trigger, that can be shared across functions.
When an event triggers the execution of your Cloud Function, data associated with the event is passed via the function's parameters.
The trigger determines the parameters passed to your function.
Currently, Cloud Functions supports events from the following providers:
- HTTP—invoke functions directly via HTTP requests.
- Cloud Storage, specifying bucket name
- Cloud Pub/Sub, specifying topic name
- Cloud Firestore
- Firebase (Realtime DB, Storage, Analytics, Auth), specifying event type.
- Stackdriver Logging - forwarding log entries to a Pub/Sub topic by creating a sink. You can then trigger the function.
Cloud Function Creation
- Trigger. With HTTP trigger, capability to authenticate requests with Google Cloud IAM
- Memory allocated.
- Max number of instances
- Capability to restrict ingress traffic to internal traffic.
- Capability to egress traffic through VPC.
Users need to be added as team members to project and grant them permissions using IAM roles: owner, editor, viewer. In addition, Cloud Functions curated roles developer and viewer are also supported.
Go 1.11, Go 1.13, Java 11, Node 8, Node 10, Node 12, Python 3.7, Python 3.8.
The environment running a function is typically resilient and reused buy subsequent function executions.
One instance per request, running all instances in parallel.
Different function instances do not share variables nor local memory.
Functions must be stateless (no memory/state shared across executions).
In order to share state across executions, state should be externally stored in Cloud Datastore, Cloud Firestore or Cloud Storage.
Starting instances involves loading runtime and code.
A new function instance is started after deploying, automatically to scale up the load, and occasionally to replace an existing instance.
Function scope contains only the body of function to be executed.
Global scope contains also the function definition, and it is executed on every cold start, unless the instance is already initialized.
Requests requiring function instance startup can be slower than requests hitting existing function instances, so it is not appropriate to rely on timing of global scope.
Function execution timeline
During function execution, function can use requested resources (vCPU and memory), but code run outside function execution is not guaranteed to execute.
Functions are typically invoked once per event.
HTTP functions are invoked at most once. Client should retry on failure, if needed.
Background functions are invoked at least once. Retries on failure, can be setup during a retry window (default to 7 days). Retried functions should be idempotent.
- Data Processing and ETLs: triggers over Cloud Storage
- Webhooks: HTTP triggers
- Lightwight APIs: applications from lightweight, loosely coupled bits of logic
- Mobile backend: events from Firebase Analytics, Realtime Database, Authentication and Storage.
- IoT: process, transform and store data for lot events from Pub/Sub
Cloud functions for Firebase
They extend behavior of Firebase and integrate Firebase features through addition of server-side code.
Firebase SDK to configure functions through code.
Integrated with Firebase CLI.
Same triggers than Google Cloud Functions plus Firebase Real Database, Firebase Authentication and Firebase Analytics triggers.