Cloud Run
1. Cloud Run
MIKE DUNKER: Next is Cloud Run. Cloud Run is a fully-managed compute platform that allows you to run request or event-driven stateless workloads without having to worry about servers. It abstracts away all infrastructure management, such as provisioning, configuring, and managing servers, so you can focus on writing code. It automatically scales up and down from zero, almost instantaneously, depending on traffic, so you never have to worry about scale configuration. Cloud Run also charges you only for the resources you use, rounded up to the nearest hundred milliseconds, so you never pay for overprovisioned resources. Cloud Run services and functions can also use GPUs. GPU on Cloud Run is fully managed with no extra drivers or libraries needed. The GPU feature offers on-demand availability without requiring reservations. Instances of a Cloud Run service that has been configured to use GPU can scale down to zero for cost savings when not in use. You can configure one GPU per Cloud Run instance. Cloud Run services and functions with configured GPUs are well suited for running AI inference workloads with large language models. They are also appropriate for compute-intensive non-AI use cases, like video transcoding and 3D rendering. Many serverless platforms add constraints around support for languages and libraries or even restrict the way you code. Cloud Run enables you to write code your way by letting you easily deploy any stateless containers that listen for requests or events delivered over HTP or gRPC. Containers offer flexibility and portability of workloads. With Cloud Run, you can build your applications in any language using whatever frameworks and tools you want and deploy them in seconds. You can use a single command to deploy containerized applications. After that, Cloud Run horizontally scales your container image automatically in order to handle receive requests, then scales it down when demand decreases. You only pay for the CPU, memory, and networking that are consumed during request handling. Cloud Run offers several deployment options. All deployment options result in a container image that runs on Google Cloud's fully-managed and highly-scalable infrastructure. The first deployment type is a container. You can supply any container that uses any base image and runs code written in the programming language of your choice, provided that the container and app it runs follow specific rules. For example, the container and app should listen for requests on a port at 0.0.0.0, and the container should use HTP without Transport Layer Security, or TLS. TLS is terminated by Cloud Run, and requests are proxied to the container without TLS. You can directly deploy container images stored in Artifact Registry or Docker Hub. The second deployment type is source code. Cloud Run lets you build and deploy source code from a single gcloud run deploy command. When deploying source code, Cloud Build transforms the code into a container image stored in Artifact Registry. You can deploy sources that include a Dockerfile. If no Dockerfile is present in the source code directory, source code must be written in one of the languages supported by Google Cloud buildpacks. The supported languages are Python, Node.js, Go, Java, Ruby, PHP, or . NET. The deploy command uses Google Cloud buildpacks and Cloud Build to automatically build container images from your source code. If a Dockerfile is present in the source code directory, the uploaded source code is built using that Dockerfile. If no Dockerfile is present, the language you're using is automatically detected, dependencies of the code are fetched, and a production-ready container image using a secure base image is built. The built container images are stored in Artifact Registry. Third, you can deploy single-purpose functions that trigger when events are emitted from your Cloud infrastructure and services or from supported third-party providers. For functions, you provide only the function code in one of the supported languages, and a buildpack creates the container. Functions are deployed as Cloud Run services. Finally, you can use continuous source deployment from a GitHub repository to deploy a Cloud Run service or function. Cloud Build can automate builds and deployments to Cloud Run when new commits are pushed to a specific branch of a Git repository. You can deploy source code stored in the repository that includes a Dockerfile or is written in one of the programming languages supported by Google Cloud buildpacks. For other repository providers, you can use Cloud Build and Cloud Deploy to set up your own CI/CD continuous deployment to Cloud Run. The Cloud Run developer workflow is a straightforward, three-step process. First, use your favorite programming language to write your application. This application should listen for web requests. Second, build and package your application into a container image. Finally, deploy the container image to Cloud Run. When you deploy your container image, you get a unique HTPS URL. Cloud Run starts your container on demand to handle requests and dynamically adds and removes containers to ensure capacity to handle all incoming requests. When you build a container image, you have full control over how the software is built and how every file is added. Sometimes you need this control. However, building an application is difficult enough already, and sometimes you just want to turn source code into an HTPS endpoint. You want to ensure that your container image is secure, well configured, and built in a consistent way. With Cloud Run, you can choose either approach. You can use a container-based workflow or a source-based workflow. When you use the source-based approach, you deploy your source code instead of a container image. Cloud Run then builds your source and packages the application into a secure container image for you automatically. Cloud Run uses buildpacks to automatically build container images. Buildpacks transform your application source code into container images that can run on any cloud. Cloud Run can be used for many use cases. Cloud Run is an excellent choice for data-processing applications. Because you pay for usage, not provisioned resources, you only pay when data is being processed. Cloud Run can also host small or large web applications and web APIs. Cloud Run scales up when necessary and scales down to zero when it's not in use. Jobs that must be run in response to Pub/Sub or Eventarc events are good candidates for Cloud Run. Functions deployed to Cloud Run are single purpose and are appropriate for many use cases. You can use functions for lightweight Extract Transferred Load, or ETL, operations, or for processing messages that are published to a Pub/Sub topic. Functions can also serve as a target for webhooks, which allow applications or services to make direct HTP calls to invoke microservices. Functions are ideal for microservices that require a small piece of code to quickly process data in response to an event. Functions let you focus on code. Let's look at Node.js as an example. When you use the Node.js runtime, your function's source code must be exported in a Node.js module. You do not need to upload zip files with package dependencies. You can specify any dependencies for your Node.js function in a package.json file. Cloud Run automatically installs all dependencies before running your code. You can use Cloud Client Libraries to programmatically interact with other Google Cloud Services. Cloud Run jobs work differently from HTP Cloud Run services. A Cloud Run job doesn't listen for and serve HTP requests. There is no need to list it on a port or start a web server. Instead, the job is executed as a one-off task or as part of a workflow. You can also use Cloud Scheduler to run a job on a regular schedule. When a Cloud Run job finishes, the job exits. Each job can be composed of a single task or multiple independent tasks. Because multiple tasks within a job are independent, the task can be run in parallel. Each task execution is aware of its task index, which is provided to the task in an environment variable. In addition, tasks that fail can be automatically retried. The maximum number of parallel tasks can be specified so that you don't overwhelm backend services with too many concurrent tasks. Each task within a job runs a single container image. This container runs to completion. Like Cloud Run services, Cloud Run jobs run on a fully serverless platform. You don't need to manage any infrastructure to run your jobs.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.