An introduction to Cloud Run functions
1. An introduction to Cloud Run functions
Welcome to the first module of this course on Cloud Run functions. In this module, we introduce Cloud Run functions and discuss their features, and benefits. We also review some of the use cases for Cloud Run functions, and do a lab to create your first function in the Google Cloud console. In this module, you learn about Cloud Run functions, their features and benefits, and their use cases. We’ll discuss the supported language runtimes and regions for deploying Cloud functions, and how they’re built and deployed on Google Cloud. You’ll also complete a lab to develop and deploy Cloud Run functions from the Google Cloud console and the gcloud CLI. Finally, we review what was discussed in this module. Let’s start by first discussing what are Cloud Run functions. Cloud Run functions is a fully managed serverless execution environment on Google Cloud for you to build, deploy, and run functions. It is a scalable functions-as-a-service platform, where there is no need to provision any infrastructure or manage individual servers. Depending on your requirements, you can connect to other cloud services from Cloud Run functions. It’s fully integrated with Cloud Cloud Observability for observability and diagnosis. There are two versions of Cloud Run functions: Cloud Run functions, formerly known as Cloud Functions (2nd generation), which deploys your functions as services on Cloud Run, allowing you to trigger them using Eventarc and Pub/Sub. Cloud Run functions (1st generation), formerly known as Cloud Functions (1st generation), the original version of functions with limited event triggers and configurability. See Cloud Run functions version comparison for more information. Cloud Run is a managed compute platform that lets you run containers directly on top of Google's scalable infrastructure. You can deploy code written in any programming language on Cloud Run if you can build a container image from it. You can use the source-based deployment option that builds the container for you, when developing your application in Go, Node.js, Python, Java, . NET Core, or Ruby. Cloud Run works well with other services on Google Cloud, so you can build full-featured applications without spending too much time operating, configuring, and scaling your Cloud Run service. A cloud function is simple code that you write that serves a single piece of functionality. It’s triggered by an event that is generated by cloud infrastructure and other services. Cloud functions execute in a fully managed serverless environment. You can develop Cloud functions in any supported language. Cloud Run functions provides a connective layer of logic that lets you write code to connect and extend cloud services. For example, a Cloud function can respond to a file upload to Cloud Storage, or an incoming message on a Pub/Sub topic. To set up and use Cloud Run functions, you: Develop the function code or logic in one of the supported programming languages. Deploy the function. You can deploy the function using the Google Cloud console or the gcloud CLI. Set up a trigger for the function to execute in response to HTTP requests or supported cloud events. Let’s now discuss the features and benefits of Cloud Run functions, and the use cases for deploying them. Here are some of the features and benefits of using Cloud Run functions. Features of Cloud Run functions include: Local development and testing: You can develop and test functions in a local development environment before deploying to Cloud Run functions. Seamlessly authenticate your cloud functions with other Google Cloud services using service accounts. HTTP and event-driven: Cloud Run functions execute in response to cloud events and HTTP requests. Integration with Cloud SQL, Bigtable, Spanner, and Firestore databases. Portability: A function can run in any standard runtime environment for one of the supported languages. Benefits of Cloud Run functions include: Augmenting and extending existing cloud services with programming logic. Serverless. The software and infrastructure are fully managed by Google. You don’t need to manage servers, update frameworks, or patch operating systems. Autoscaling. Resources are automatically provisioned in response to events. A function can scale from a few invocations a day to many millions of invocations without requiring any additional work. Observable. Cloud Run functions are integrated with Google Cloud Observability monitoring and logging tools for observability and error diagnosis. Pricing. A pay as you go pricing model is used. The cost is based on the number of function invocations, how long the function runs (compute time), and any data transfer fees for outbound network traffic. There are two types of Cloud Run functions: HTTP functions, which handle HTTP requests, and Event-driven functions, which handle events from your cloud environment. Use HTTP functions with HTTP triggers when you want to invoke a function with an HTTP(S) request. When you specify an HTTP trigger for a function, the function is assigned a URL at which it can receive requests. An HTTP trigger enables a function to run in response to HTTP(S) requests. A good use case for using HTTP functions is to implement a webhook or API that handles http requests from other services. By default, requests to HTTP functions require authentication. You can choose to allow unauthenticated requests during function deployment. We discuss securing Cloud Run functions in more detail in a later module of this course. To implement an HTTP function, you write an HTTP handler function and register it with the functions framework for your programming language. The handler accepts the request and response arguments, processes the request based on the request method, and sends back an HTTP response. If the function creates any background tasks like threads, processes, or Promise objects, they must be terminated before the response is sent. Use event-driven functions when you want a function to be invoked automatically in response to an event that occurs in your cloud environment. You implement event-driven functions using CloudEvent functions or Background functions depending on your chosen language runtime, and if you’re using Cloud Run functions or Cloud Run functions (1st generation). Event-driven functions use event triggers which react to events within your Google Cloud project. Event triggers are supported by many Google Cloud services based on if the cloud function is from Cloud Run functions or Cloud Run functions (1st generation). You can use event triggers for: Pub/Sub, Cloud Storage, Firestore, Firebase, and Eventarc sources. You can also integrate Cloud Run functions with any other Google Cloud service that supports Pub/Sub as an event bus. We discuss triggers in more detail in a later module of this course. Event-driven functions are executed in response to an event like receipt of a new Pub/Sub message or deletion of a file in Cloud Storage. You implement an event-driven function as a CloudEvent function or a Background function. CloudEvent functions are: Based on the CloudEvents industry standard specification for describing event data. Registered with the Functions Framework, an open source library that wraps user functions within a persistent HTTP application. Used by Cloud Run functions with all language runtimes. Used by Cloud Run functions (1st generation) with . NET, Ruby, and PHP. Background functions are: Older style event-driven functions that receive event data based on the type of event. Used by Cloud Run functions (1st generation) with Node.js, Python, Go, and Java runtimes. Cloud Run functions have the following features: Function instances with up to 32 GB of RAM and 4 vCPUs. Process up to 1000 concurrent requests with a single function instance. This capability reduces cold starts and improves overall latency when scaling. Run time limit of up to 60 minutes for HTTP functions, and up to 10 minutes for event-driven functions to process longer request workloads. With a new revision created every time you deploy your function, you can split traffic between different revisions or rollback your function to a prior revision. Leverage Cloud Run’s scalable container platform to move your function to Cloud Run or to Kubernetes. With Eventarc, event-driven functions can be triggered from more than 90 Google, external SaaS event sources, and custom sources by publishing to Pub/Sub. With the industry-standard CloudEvents format, you can simplify your event handling code. In Google Cloud console configure your function’s triggers, track deployments, and test your functions, and view function metrics. View the documentation on the comparison between Cloud Run functions and Cloud Run functions 1st generation. Some of the use cases for Cloud Run functions include: Data processing By responding to Cloud Storage events on files and objects, you can validate and transform data, process images and videos for further downstream processing. Webhooks and APIs With HTTP functions, you can support webhook and API calls that originate from external systems by processing HTTP requests. Mobile device backend that responds to events triggered by Firebase. With Cloud Run functions, you can develop mobile device backend services that responds to events triggered by Firebase and Firestore. IoT You can develop IoT (internet-of-things) applications with Cloud Run functions by processing and storing data from devices streamed into Pub/Sub. In this section, we discuss the language runtimes and regions supported by Cloud Run functions. You can develop Cloud Run functions in any of these supported languages. There are specific versions of each language runtime that is supported. Please refer to the Cloud Run functions documentation for the version numbers. The language runtime that you choose and the type of function that you want to write determine the structure of your code and function implementation. For Cloud Run functions to locate your function definition, each language runtime has specific requirements for structuring your source code. Here are the basic directory structures for some of the languages. For Node.js, by default, Cloud Run functions loads source code from a file named index.js at the root of your function directory. To specify a different main source file, use the main field in your package.json file. The package.json file also includes the Functions Framework for Node.js as a dependency, along with any additional library dependencies needed by your function. For Python, Cloud Run functions loads source code from a file named main.py at the root of your function directory. The requirements.txt file also includes the Functions Framework for Python as a dependency and any additional library dependencies needed by your function. For Go, your function must be in a Go package at the root of your project. The go.mod file includes the Functions Framework for Go as a dependency, and any additional library dependencies needed by your function. For more details on creating your source code directory structure for your preferred language, refer to the Cloud Run functions documentation. The function entry point is the code that is executed when the Cloud Run function is invoked. Your source code must define an entry point for your function and must be defined in your main file or root package. Depending on the programming language, the entry point is a function or a class. You specify this entry point when you deploy your function. The infrastructure that runs Cloud Run functions is located in a specific region and is managed by Google to be redundantly available across all the zones within that region. When selecting a region to run your Cloud Run functions, your primary considerations should be latency and availability. You can generally select the region closest to your Cloud Run function's users, but you should also consider the location of the other Google Cloud products and services that your app uses. Using services across multiple locations can affect your app's latency, and pricing. Cloud Run functions and Cloud Run functions 1st generation, have different regional availability.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.