Google Cloud Functions

From Luis Gallego Hurtado - Not Another IT guy
Jump to: navigation, search


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.

Microsecond billing.

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).

Serverless

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

Events are things that happen within your cloud environment that you might want to take action on (triggers).

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

  • Region
  • Trigger. With HTTP trigger, capability to authenticate requests with Google Cloud IAM
  • Timeout
  • Memory allocated.
  • Max number of instances
  • Capability to restrict ingress traffic to internal traffic.
  • Capability to egress traffic through VPC.

Access Control

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.

Execution Environment

Runtimes

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.

Concurrency

One instance per request, running all instances in parallel.

Different function instances do not share variables nor local memory.

Stateless functions

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.

Performance

Starting instances involves loading runtime and code.

Cold starts

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.

Execution guarantees

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.

Use Cases

  • 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.

Retrieved from "https://www.luisgallegohurtado.com/w/index.php?title=Google_Cloud_Functions&oldid=712"