{"id":618,"date":"2026-04-14T18:34:29","date_gmt":"2026-04-14T18:34:29","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-run-functions-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-hosting\/"},"modified":"2026-04-14T18:34:29","modified_gmt":"2026-04-14T18:34:29","slug":"google-cloud-run-functions-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-hosting","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-run-functions-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-hosting\/","title":{"rendered":"Google Cloud Run functions Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application hosting"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Application hosting<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p><strong>Cloud Run functions<\/strong> is Google Cloud\u2019s serverless \u201cfunctions\u201d experience built on top of <strong>Cloud Run<\/strong>. If you previously used <strong>Cloud Functions (2nd gen)<\/strong>, you\u2019re effectively using the same underlying platform; Google has been aligning the product naming and workflow around Cloud Run. In some tools and docs, you may still see \u201cCloud Functions\u201d terminology or commands\u2014especially in the <code>gcloud functions<\/code> CLI. Treat those as part of the same ecosystem and <strong>verify the latest naming and commands in official docs<\/strong>.<\/p>\n\n\n\n<p>In simple terms: <strong>Cloud Run functions lets you deploy a single function (a small piece of code) without managing servers<\/strong>, and you pay based on usage. Your function can be invoked via HTTP requests (webhooks\/APIs) or by events (for example, messages or object changes), and Google Cloud handles scaling, routing, and basic operations.<\/p>\n\n\n\n<p>Technically, Cloud Run functions packages your function source code, builds it (typically via <strong>Cloud Build<\/strong>), stores an artifact (typically in <strong>Artifact Registry<\/strong>), and runs it on Cloud Run\u2019s managed runtime. For event-driven functions, it integrates with event routing (commonly <strong>Eventarc<\/strong>) and other Google Cloud services such as <strong>Pub\/Sub<\/strong>, <strong>Cloud Storage<\/strong>, <strong>Firestore<\/strong>, and more (exact triggers depend on what is supported\u2014verify in official docs).<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> Cloud Run functions is designed for teams who want <strong>fast, low-ops, event-driven or request-driven compute<\/strong>\u2014ideal for small services, automation, glue code, webhooks, lightweight APIs, and asynchronous processing\u2014without the operational overhead of Kubernetes or VM-based hosting.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Cloud Run functions?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Cloud Run functions provides a <strong>function-centric deployment model<\/strong> on Google Cloud where you deploy <strong>a function<\/strong> (not a full microservice application) and run it on <strong>Cloud Run\u2019s serverless infrastructure<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>At a high level, Cloud Run functions typically supports:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>HTTP-triggered functions<\/strong> (invoke via HTTPS endpoint)<\/li>\n<li><strong>Event-triggered functions<\/strong> (invoke in response to events routed from Google Cloud services)<\/li>\n<li><strong>Automatic scaling<\/strong> (including scale-to-zero)<\/li>\n<li><strong>Source-based deployment<\/strong> (build from source)<\/li>\n<li><strong>Fine-grained configuration<\/strong>: environment variables, runtime settings, and scaling controls (availability and exact limits can vary\u2014verify in official docs)<\/li>\n<li><strong>Observability<\/strong>: logs, metrics, and error reporting through Google Cloud\u2019s operations suite<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (how it\u2019s assembled in Google Cloud)<\/h3>\n\n\n\n<p>When you deploy and run Cloud Run functions, you are commonly interacting with:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Run<\/strong>: the managed execution environment that actually runs your function<\/li>\n<li><strong>Cloud Build<\/strong>: builds your function into a runnable artifact<\/li>\n<li><strong>Artifact Registry<\/strong>: stores built images\/artifacts (common in Cloud Run workflows)<\/li>\n<li><strong>Eventing layer<\/strong> (often <strong>Eventarc<\/strong> for many event sources): routes events to your function<\/li>\n<li><strong>IAM<\/strong>: controls who can deploy, configure, and invoke functions<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: operational visibility<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Serverless compute<\/strong> for <strong>functions<\/strong> (function-as-a-service experience) backed by Cloud Run.<\/li>\n<li>Designed for <strong>application hosting<\/strong> use cases where you want minimal infrastructure management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope and location model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run resources are <strong>regional<\/strong>. In practice, Cloud Run functions are typically <strong>deployed to a specific region<\/strong> within a Google Cloud project.<\/li>\n<li>IAM, billing, and quotas are <strong>project-scoped<\/strong>.<\/li>\n<li>Networking behavior (public endpoint, internal access, VPC egress) depends on configuration and supported features\u2014verify in official docs for the specific trigger type and runtime.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Cloud Run functions sits between:\n&#8211; Full containerized microservices on <strong>Cloud Run services<\/strong>\n&#8211; Event-driven \u201csingle-purpose\u201d compute (function model)\n&#8211; Traditional platforms like <strong>App Engine<\/strong>, <strong>GKE<\/strong>, or <strong>Compute Engine<\/strong><\/p>\n\n\n\n<p>It\u2019s commonly used with:\n&#8211; <strong>Pub\/Sub<\/strong> for asynchronous messaging\n&#8211; <strong>Cloud Storage<\/strong> for object events (where supported)\n&#8211; <strong>Cloud Scheduler<\/strong> to trigger periodic tasks (often via HTTP)\n&#8211; <strong>Secret Manager<\/strong> for secrets\n&#8211; <strong>Cloud SQL<\/strong> and other databases (with correct networking and IAM patterns)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Cloud Run functions?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster time to market<\/strong>: deploy small units of functionality quickly.<\/li>\n<li><strong>Lower operational overhead<\/strong>: no servers, clusters, or capacity planning for most workloads.<\/li>\n<li><strong>Cost alignment with usage<\/strong>: scale to zero when idle (for typical request-driven patterns).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Event-driven architecture support<\/strong>: react to changes in data\/services without running always-on workers.<\/li>\n<li><strong>Simple HTTP endpoints<\/strong>: implement webhooks, lightweight APIs, callbacks.<\/li>\n<li><strong>Language runtime convenience<\/strong>: deploy function code without containerizing manually (though it\u2019s still built into a runnable artifact under the hood).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Autoscaling<\/strong>: handle bursty traffic without pre-provisioning.<\/li>\n<li><strong>Managed deployments<\/strong>: integrate with Cloud Build and standard CI\/CD patterns.<\/li>\n<li><strong>Centralized logging and metrics<\/strong>: use Cloud Logging\/Monitoring for operational excellence.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-based invocation<\/strong>: restrict who can call your function (important for internal APIs).<\/li>\n<li><strong>Private networking options<\/strong>: reach private resources using supported VPC connectivity patterns (verify availability per region\/runtime).<\/li>\n<li><strong>Auditability<\/strong>: Cloud Audit Logs for administrative changes and invocations (depending on configuration).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Rapid scale-out<\/strong> for short-lived compute tasks.<\/li>\n<li><strong>Concurrency controls<\/strong> (inherited from Cloud Run concepts) can improve efficiency for some workloads (verify supported configuration for Cloud Run functions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Cloud Run functions<\/h3>\n\n\n\n<p>Choose Cloud Run functions when you need:\n&#8211; A small unit of code triggered by HTTP or events\n&#8211; Glue logic between managed services\n&#8211; Lightweight processing (validation, enrichment, fan-out)\n&#8211; Simple operational model with managed scaling and observability<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid Cloud Run functions (or consider alternatives) when you need:\n&#8211; <strong>Long-running stateful services<\/strong> with always-on connections and strict latency SLOs (Cloud Run services might be better)\n&#8211; Heavy customization of runtime\/OS dependencies (Cloud Run services with custom containers are more flexible)\n&#8211; Complex multi-service deployments requiring service mesh features (GKE is often better)\n&#8211; Strict deterministic performance without cold starts (consider min instances, Cloud Run services, or other compute models)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Cloud Run functions used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SaaS<\/strong>: webhook handlers, billing events, user lifecycle events<\/li>\n<li><strong>Retail\/e-commerce<\/strong>: order events, inventory sync, notification triggers<\/li>\n<li><strong>Media<\/strong>: processing pipelines, metadata extraction, fan-out to workflows<\/li>\n<li><strong>Finance\/fintech<\/strong>: transaction notifications, lightweight compliance checks (with strong security controls)<\/li>\n<li><strong>Healthcare<\/strong>: event-driven processing with careful IAM and audit logging (ensure compliance requirements are met)<\/li>\n<li><strong>IoT<\/strong>: ingestion and routing from messaging systems<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>App developers building APIs and event handlers<\/li>\n<li>Platform engineering teams providing golden paths<\/li>\n<li>DevOps\/SRE teams modernizing scheduled jobs and automation<\/li>\n<li>Data engineering teams building event-driven ingestion and enrichment<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>HTTP endpoints for webhooks\/callbacks<\/li>\n<li>Message-driven processing from queues\/topics<\/li>\n<li>Automation tasks triggered by schedules or events<\/li>\n<li>Integration logic between SaaS and internal systems<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Event-driven microservices<\/strong><\/li>\n<li><strong>Serverless backend<\/strong><\/li>\n<li><strong>Hybrid<\/strong>: Cloud Run functions for glue + Cloud Run services for core APIs + managed databases<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production: strict IAM, private egress, structured logging, SLO monitoring, CI\/CD controls<\/li>\n<li>Dev\/test: rapid iteration, ephemeral deployments, low-cost experiments<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic Cloud Run functions use cases with concrete \u201cwhy it fits\u201d reasoning.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Webhook receiver for SaaS integrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Accept inbound webhooks from Stripe\/GitHub\/Shopify and validate signatures.<\/li>\n<li><strong>Why Cloud Run functions fits:<\/strong> Simple HTTPS endpoint, scales with webhook bursts, minimal ops.<\/li>\n<li><strong>Example:<\/strong> A function receives a \u201cpayment_succeeded\u201d webhook, verifies signature, publishes a message to Pub\/Sub for downstream processing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Event-driven image thumbnail generation (where event triggers are supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Generate thumbnails when a new image is uploaded.<\/li>\n<li><strong>Why it fits:<\/strong> Run only on uploads, autoscale based on spikes.<\/li>\n<li><strong>Example:<\/strong> Object upload event triggers a function that creates thumbnails and stores them in another bucket.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Pub\/Sub message consumer for async processing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Process incoming messages to enrich data or call external APIs.<\/li>\n<li><strong>Why it fits:<\/strong> Stateless processing, autoscaling, retries (behavior depends on trigger semantics\u2014verify).<\/li>\n<li><strong>Example:<\/strong> A function consumes \u201cuser-signup\u201d messages and calls an email provider API.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Scheduled automation via HTTP trigger<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Run periodic tasks without maintaining a cron VM.<\/li>\n<li><strong>Why it fits:<\/strong> Combine Cloud Scheduler + HTTP-triggered function.<\/li>\n<li><strong>Example:<\/strong> Every hour, Cloud Scheduler calls a function that reconciles data between two systems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Lightweight API for internal tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Provide a small endpoint for internal automation or chatops.<\/li>\n<li><strong>Why it fits:<\/strong> IAM-controlled invocation, quick deploy.<\/li>\n<li><strong>Example:<\/strong> A function invoked from Chat app posts deployment status to internal systems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Data validation and transformation gateway<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Validate and normalize payloads from multiple producers.<\/li>\n<li><strong>Why it fits:<\/strong> Encapsulate validation logic, consistent logging, scale as needed.<\/li>\n<li><strong>Example:<\/strong> Incoming payloads are validated and then stored or queued.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Audit and compliance event handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> React to security-related events and trigger incident workflows.<\/li>\n<li><strong>Why it fits:<\/strong> Event-driven compute, integrates with logging\/monitoring.<\/li>\n<li><strong>Example:<\/strong> A function processes events and opens a ticket or sends alerts (exact event sources vary\u2014verify supported triggers).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Backend for mobile or frontend prototypes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Rapidly prototype a backend endpoint.<\/li>\n<li><strong>Why it fits:<\/strong> Minimal setup, scales automatically, easy iteration.<\/li>\n<li><strong>Example:<\/strong> A function returns feature flags for a mobile app.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) ETL \u201cglue\u201d between managed services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Small transformations between ingestion and storage.<\/li>\n<li><strong>Why it fits:<\/strong> Avoid full data pipeline overhead for simple tasks.<\/li>\n<li><strong>Example:<\/strong> A function transforms a JSON record and writes to BigQuery (ensure correct client library usage and permissions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Notification fan-out<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Notify multiple downstream systems when an event happens.<\/li>\n<li><strong>Why it fits:<\/strong> Function can orchestrate fan-out using Pub\/Sub, HTTP calls, or workflows.<\/li>\n<li><strong>Example:<\/strong> On \u201corder created\u201d, publish to multiple topics and call a fulfillment API.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) GitOps\/CI integration callback<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Handle CI system callbacks and store build metadata.<\/li>\n<li><strong>Why it fits:<\/strong> Stateless endpoint, burst handling.<\/li>\n<li><strong>Example:<\/strong> A function receives a callback, writes metadata to Firestore, and posts to Chat.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) \u201cEdge of the VPC\u201d adapter<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Provide a small service that calls internal resources with controlled egress.<\/li>\n<li><strong>Why it fits:<\/strong> Use supported VPC connectivity patterns to reach private endpoints (verify exact options).<\/li>\n<li><strong>Example:<\/strong> An authenticated function fetches data from an internal API and returns a filtered response.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Note: Cloud Run functions is tightly coupled to Cloud Run capabilities and the function deployment experience. Specific knobs and limits can vary by runtime and trigger type\u2014<strong>verify in official docs<\/strong> for your region and language.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) HTTP-triggered functions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Exposes a function as an HTTPS endpoint.<\/li>\n<li><strong>Why it matters:<\/strong> Enables webhooks, small APIs, internal endpoints.<\/li>\n<li><strong>Practical benefit:<\/strong> Simple integration with clients and other services via HTTPS.<\/li>\n<li><strong>Caveats:<\/strong> Public endpoints must be secured (authentication\/authorization). Cold starts can affect latency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Event-triggered functions (event-driven)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Runs code in response to events from Google Cloud services routed through eventing.<\/li>\n<li><strong>Why it matters:<\/strong> Enables reactive, loosely coupled systems.<\/li>\n<li><strong>Practical benefit:<\/strong> No polling workers; scale based on event volume.<\/li>\n<li><strong>Caveats:<\/strong> Trigger availability varies; event delivery semantics (at-least-once vs exactly-once) and retries depend on the trigger\u2014verify per event source.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Source-based builds (buildpacks\/managed build)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> You provide source code; Google Cloud builds a runnable artifact.<\/li>\n<li><strong>Why it matters:<\/strong> Faster developer experience than maintaining Dockerfiles for small functions.<\/li>\n<li><strong>Practical benefit:<\/strong> Standardized builds; integrates with CI\/CD.<\/li>\n<li><strong>Caveats:<\/strong> If you need OS-level dependencies or custom system libraries, consider Cloud Run services with custom containers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Autoscaling (including scale-to-zero)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Scales instances based on incoming load; can scale down to zero when idle (for typical patterns).<\/li>\n<li><strong>Why it matters:<\/strong> Cost efficiency and resilience to traffic bursts.<\/li>\n<li><strong>Practical benefit:<\/strong> Pay for usage rather than idle capacity.<\/li>\n<li><strong>Caveats:<\/strong> Cold starts; some event triggers may keep minimum activity depending on configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Configurable runtime settings (memory\/CPU\/timeouts)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Choose runtime resources and execution limits.<\/li>\n<li><strong>Why it matters:<\/strong> Balance performance and cost; avoid out-of-memory and timeouts.<\/li>\n<li><strong>Practical benefit:<\/strong> Tune functions for workload characteristics.<\/li>\n<li><strong>Caveats:<\/strong> Max values and defaults vary\u2014verify current limits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Concurrency and request handling (Cloud Run model)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows an instance to process multiple requests concurrently (where supported\/configured).<\/li>\n<li><strong>Why it matters:<\/strong> Improves efficiency and cost for IO-heavy workloads.<\/li>\n<li><strong>Practical benefit:<\/strong> Fewer instances needed at a given load.<\/li>\n<li><strong>Caveats:<\/strong> Your code must be concurrency-safe. Some function patterns assume concurrency = 1; verify defaults and supported settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) IAM-based invocation control<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Restrict who can call HTTP functions using IAM roles\/policies.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents accidental public exposure.<\/li>\n<li><strong>Practical benefit:<\/strong> Use service accounts and least privilege.<\/li>\n<li><strong>Caveats:<\/strong> Ensure callers can obtain identity tokens (for HTTP). For events, permissions are service-to-service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Integration with Secret Manager (recommended)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Store secrets centrally and inject them into runtime securely (exact injection method depends on product support\u2014verify).<\/li>\n<li><strong>Why it matters:<\/strong> Avoid secrets in code or plain env vars.<\/li>\n<li><strong>Practical benefit:<\/strong> Rotation, audit logs, centralized management.<\/li>\n<li><strong>Caveats:<\/strong> Access controlled by IAM; secret access may add latency if fetched at runtime.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) VPC connectivity for private resources (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enables reaching private IP resources (databases\/internal APIs) via serverless networking.<\/li>\n<li><strong>Why it matters:<\/strong> Connect functions to private backends securely.<\/li>\n<li><strong>Practical benefit:<\/strong> Avoid exposing databases publicly.<\/li>\n<li><strong>Caveats:<\/strong> Requires networking setup and may add cost\/latency. Verify whether Serverless VPC Access connector or direct VPC egress patterns apply to your configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Observability: logs, metrics, traces<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Emits logs to Cloud Logging and metrics to Cloud Monitoring; supports error reporting and tracing patterns.<\/li>\n<li><strong>Why it matters:<\/strong> Production readiness needs visibility.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster troubleshooting, SLO monitoring, alerting.<\/li>\n<li><strong>Caveats:<\/strong> Logging volume can become a cost driver; structure logs for better querying.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Revisioning and controlled rollout (Cloud Run concepts)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Deployments create new revisions; you can manage traffic (exact UI\/controls depend on \u201cfunctions\u201d experience).<\/li>\n<li><strong>Why it matters:<\/strong> Safe updates and rollback.<\/li>\n<li><strong>Practical benefit:<\/strong> Reduce deployment risk.<\/li>\n<li><strong>Caveats:<\/strong> Function interface may abstract some Cloud Run details; verify operational controls available in your environment.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Cloud Run functions uses a build-and-run lifecycle:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>You write function code.<\/li>\n<li>You deploy from source (Console, CLI, or CI\/CD).<\/li>\n<li>Google Cloud builds the function into a runnable artifact (commonly through Cloud Build).<\/li>\n<li>The artifact is stored (commonly in Artifact Registry).<\/li>\n<li>Cloud Run executes the function and scales instances based on demand.<\/li>\n<li>Requests arrive via HTTPS load balancing\/routing, or events arrive via event routing (often Eventarc).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request \/ data \/ control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> Deployments, IAM policy changes, configuration updates.<\/li>\n<li><strong>Data plane:<\/strong> HTTP requests and event deliveries to the function runtime.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common integrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Eventarc<\/strong> for event routing (commonly used for many sources)<\/li>\n<li><strong>Pub\/Sub<\/strong> for messaging<\/li>\n<li><strong>Cloud Storage<\/strong> for object data (events and storage)<\/li>\n<li><strong>Cloud SQL<\/strong> for relational data (requires correct connectivity)<\/li>\n<li><strong>Secret Manager<\/strong> for secrets<\/li>\n<li><strong>Cloud Logging &amp; Monitoring<\/strong> for ops<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services you should expect<\/h3>\n\n\n\n<p>Even if you \u201conly deploy a function\u201d, these services may be involved:\n&#8211; Cloud Build (build)\n&#8211; Artifact Registry (artifact storage)\n&#8211; Cloud Logging\/Monitoring (ops telemetry)\n&#8211; Event routing services (for event triggers)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deployment permissions<\/strong>: controlled via IAM roles (who can deploy\/update).<\/li>\n<li><strong>Runtime identity<\/strong>: a service account is used by the function to access Google Cloud APIs.<\/li>\n<li><strong>Invocation control<\/strong>:<\/li>\n<li>HTTP: can be public or IAM-protected.<\/li>\n<li>Events: service-to-service invocation typically controlled by IAM between event source\/router and the function.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>HTTP functions have an HTTPS endpoint (public or IAM-controlled).<\/li>\n<li>Outbound egress typically goes to the internet unless configured for private egress patterns.<\/li>\n<li>Private access to VPC resources usually requires serverless networking features (verify current supported options for Cloud Run functions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize logs in Cloud Logging; use structured logs.<\/li>\n<li>Use Cloud Monitoring metrics and alerts (latency, error rate, instance count).<\/li>\n<li>Use Cloud Audit Logs for admin activity (deployments\/permission changes).<\/li>\n<li>Use resource labels\/tags and naming conventions for governance.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Simple architecture diagram (HTTP function)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Client \/ Webhook Sender] --&gt;|HTTPS| F[Cloud Run functions]\n  F --&gt;|Logs| L[Cloud Logging]\n  F --&gt;|Metrics| M[Cloud Monitoring]\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style architecture diagram (event-driven + private resources)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Build_and_Deploy\n    Dev[Developer \/ CI] --&gt;|Deploy from source| CB[Cloud Build]\n    CB --&gt; AR[Artifact Registry]\n  end\n\n  subgraph Runtime\n    AR --&gt; CRF[Cloud Run functions (runs on Cloud Run)]\n    EVT[Event source: Pub\/Sub \/ Storage \/ etc.] --&gt; EA[Event routing (often Eventarc)]\n    EA --&gt; CRF\n    CRF --&gt; SM[Secret Manager]\n    CRF --&gt;|Private egress (if configured)| VPC[Serverless VPC Access \/ VPC egress]\n    VPC --&gt; DB[Private backend (e.g., Cloud SQL via private IP)]\n  end\n\n  CRF --&gt; CL[Cloud Logging]\n  CRF --&gt; CM[Cloud Monitoring]\n  Admin[IAM \/ Policy Admin] --&gt; CRF\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud account\/project<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong> (required for most real deployments).<\/li>\n<li>You should know your desired <strong>region<\/strong> (Cloud Run is regional).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Enable APIs\n&#8211; Deploy Cloud Run functions\n&#8211; View logs and metrics<\/p>\n\n\n\n<p>Common roles (exact least-privilege roles vary by organization and workflow\u2014verify):\n&#8211; Project-level: <code>roles\/serviceusage.serviceUsageAdmin<\/code> (enable APIs) or equivalent\n&#8211; Deployment: Cloud Run \/ Cloud Functions deployment roles (verify current recommended roles)\n&#8211; Build: Cloud Build permissions (often handled by service accounts automatically)\n&#8211; Observability: <code>roles\/logging.viewer<\/code>, <code>roles\/monitoring.viewer<\/code> (for viewing)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Billing must be active.<\/li>\n<li>Be aware of build and artifact storage costs (see Pricing section).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud SDK (<code>gcloud<\/code>)<\/a><\/li>\n<li>Authentication via:\n  <code>bash\n  gcloud auth login\n  gcloud auth application-default login<\/code><\/li>\n<li>Recommended: <code>curl<\/code> for testing endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run is regional; Cloud Run functions availability depends on region and feature support.<\/li>\n<li><strong>Verify region support<\/strong> in official Cloud Run documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits to check before production<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Max instances<\/li>\n<li>Concurrency<\/li>\n<li>Request size limits<\/li>\n<li>Timeout limits<\/li>\n<li>Event delivery quotas<\/li>\n<li>Build quotas (Cloud Build)<\/li>\n<li>Artifact Registry storage<\/li>\n<\/ul>\n\n\n\n<p>Quotas evolve\u2014<strong>verify quotas in the Google Cloud Console<\/strong> (IAM &amp; Admin \u2192 Quotas) and relevant product docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs (commonly required)<\/h3>\n\n\n\n<p>Depending on your trigger and deployment method, you may need to enable:\n&#8211; Cloud Run API\n&#8211; Cloud Build API\n&#8211; Artifact Registry API\n&#8211; Eventarc API (for many event triggers)\n&#8211; Pub\/Sub API (if using Pub\/Sub)\n&#8211; Cloud Logging\/Monitoring (usually available by default)<\/p>\n\n\n\n<p>Exact API names can change\u2014verify in official docs and in the \u201cEnable APIs\u201d console flow.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Cloud Run functions pricing is fundamentally aligned with <strong>Cloud Run\u2019s usage-based model<\/strong>, plus any additional services involved (event routing, messaging, builds, artifact storage, networking).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing sources (start here)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run pricing: https:\/\/cloud.google.com\/run\/pricing<\/li>\n<li>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<li>(If you encounter Cloud Functions pricing pages during research, treat them as legacy\/parallel documentation and confirm the current Cloud Run functions model): https:\/\/cloud.google.com\/functions\/pricing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>You typically pay for some combination of:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Compute while your function runs<\/strong>\n   &#8211; CPU time and memory allocation during request\/event processing\n   &#8211; Potentially additional billing during startup or idle (depends on Cloud Run configuration such as CPU allocation model\u2014verify current behavior for Cloud Run functions)<\/p>\n<\/li>\n<li>\n<p><strong>Requests<\/strong>\n   &#8211; Number of invocations\/requests handled<\/p>\n<\/li>\n<li>\n<p><strong>Build and artifact storage<\/strong>\n   &#8211; <strong>Cloud Build minutes<\/strong> for building from source\n   &#8211; <strong>Artifact Registry storage<\/strong> for images\/artifacts\n   &#8211; Egress from Artifact Registry in certain scenarios (usually internal, but verify if cross-region)<\/p>\n<\/li>\n<li>\n<p><strong>Eventing and messaging<\/strong>\n   &#8211; <strong>Eventarc<\/strong> event delivery charges (where used)\n   &#8211; <strong>Pub\/Sub<\/strong> message ingestion\/delivery charges (if applicable)<\/p>\n<\/li>\n<li>\n<p><strong>Networking<\/strong>\n   &#8211; Outbound internet egress\n   &#8211; Cross-region data transfer\n   &#8211; VPC connectivity (Serverless VPC Access can introduce additional costs\u2014verify pricing)\n   &#8211; Load balancer costs if you place additional front doors (not required for basic HTTPS invocation)<\/p>\n<\/li>\n<li>\n<p><strong>Observability<\/strong>\n   &#8211; Cloud Logging ingestion, retention, and queries can add cost at scale\n   &#8211; Monitoring metrics and alerting are generally low-cost but can grow in large environments<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<p>Cloud Run historically offers a free tier for a certain amount of requests, CPU, and memory. Free tier details can change and can be region-specific.\n&#8211; <strong>Verify current free tier<\/strong> on the official Cloud Run pricing page: https:\/\/cloud.google.com\/run\/pricing<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>High invocation volume (requests\/events)<\/li>\n<li>Large memory\/CPU allocations<\/li>\n<li>Long execution times (timeouts)<\/li>\n<li>High concurrency misconfiguration (too low can cost more; too high can cause throttling or memory pressure)<\/li>\n<li>Frequent deployments\/builds (CI churn)<\/li>\n<li>Excessive logging<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Build costs from frequent builds or large dependencies<\/li>\n<li>Artifact Registry storage growth (old images)<\/li>\n<li>Eventarc and Pub\/Sub charges<\/li>\n<li>Data egress to external APIs or clients outside Google Cloud<\/li>\n<li>VPC connector costs and traffic (if used)<\/li>\n<li>Logging volume (especially debug logs in production)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size memory\/CPU; measure and tune.<\/li>\n<li>Avoid chatty logs; keep INFO logs concise and structured.<\/li>\n<li>Use concurrency appropriately for IO-bound workloads (after verifying it\u2019s supported and safe).<\/li>\n<li>Prefer regional co-location of dependent services (function + database in same region).<\/li>\n<li>Clean up old artifacts and unused deployments.<\/li>\n<li>Use Pub\/Sub batching where it applies (depends on consumer model\u2014verify).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (model, not a fabricated price)<\/h3>\n\n\n\n<p>A typical starter function:\n&#8211; Low request volume (a few thousand requests\/day)\n&#8211; Short execution time (&lt;200 ms average)\n&#8211; Small memory allocation\n&#8211; Minimal egress\n&#8211; Few builds\/week<\/p>\n\n\n\n<p>In many cases, such a workload can remain very low-cost and may partially fall within free tier. The only reliable way to estimate is:\n1. Identify expected invocations\/day\n2. Measure average runtime and memory\n3. Use the Cloud Run pricing calculator and include build\/artifact\/logging<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production workloads, model:\n&#8211; Peak QPS and burst patterns\n&#8211; p95\/p99 runtime\n&#8211; Memory needs under load\n&#8211; Concurrency setting (if used)\n&#8211; Min instances (if configured to reduce cold start latency\u2014this increases baseline cost)\n&#8211; Event routing and message delivery costs\n&#8211; Logging retention requirements (compliance)<\/p>\n\n\n\n<p>A good practice is to run a 1\u20132 week load test and compare:\n&#8211; billed compute time vs observed request metrics\n&#8211; number of instances and scaling behavior\n&#8211; logging volume and cost trends<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab deploys a real HTTP function, tests it, checks logs, and then cleans up. It is designed to be low-cost.<\/p>\n\n\n\n<blockquote>\n<p>Important naming note: In many environments, <strong>Cloud Run functions deployments may still be performed using <code>gcloud functions deploy --gen2<\/code><\/strong> (Cloud Functions 2nd gen) because the underlying platform is Cloud Run. The Console experience may show \u201cCloud Run functions\u201d. <strong>Verify the current recommended CLI workflow<\/strong> in the official documentation: https:\/\/cloud.google.com\/run\/docs\/functions\/overview<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy an <strong>HTTP-triggered Cloud Run function<\/strong> that:\n&#8211; Responds with a greeting\n&#8211; Logs request metadata\n&#8211; Demonstrates environment variable configuration\n&#8211; Can be tested from your terminal<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a new Google Cloud project (or select an existing one)\n2. Enable required APIs\n3. Write a small function (Python)\n4. Deploy it as a Cloud Run function (Gen2\/Cloud Run-based)\n5. Invoke it and view logs\n6. Update configuration (env var), redeploy, and validate\n7. Clean up to avoid charges<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create\/select a project and set defaults<\/h3>\n\n\n\n<p>1) Select or create a project:\n&#8211; Console: IAM &amp; Admin \u2192 Manage resources \u2192 Create Project<br\/>\n  or use an existing project.<\/p>\n\n\n\n<p>2) In your terminal, set the project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<p>3) Choose a region (example: <code>us-central1<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set run\/region us-central1\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>gcloud config list<\/code> shows your project and (optionally) region.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config list\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable APIs<\/h3>\n\n\n\n<p>Enable the common APIs used by Cloud Run functions builds and execution.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  run.googleapis.com \\\n  cloudbuild.googleapis.com \\\n  artifactregistry.googleapis.com \\\n  logging.googleapis.com \\\n  monitoring.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>If you plan event triggers later, you will likely also need (verify based on trigger):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable eventarc.googleapis.com pubsub.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enable successfully.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --format=\"value(config.name)\" | grep -E \"run|cloudbuild|artifactregistry\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create the function code (Python)<\/h3>\n\n\n\n<p>Create a new directory and files:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p cloud-run-functions-hello\ncd cloud-run-functions-hello\n<\/code><\/pre>\n\n\n\n<p>Create <code>main.py<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-python\">import os\nfrom flask import Request\n\ndef hello_http(request: Request):\n    # Basic request metadata\n    user_agent = request.headers.get(\"User-Agent\", \"unknown\")\n    name = request.args.get(\"name\", \"world\")\n\n    # Example env var\n    greeting_prefix = os.environ.get(\"GREETING_PREFIX\", \"Hello\")\n\n    print(f\"Request received. user_agent={user_agent} name={name}\")\n\n    return f\"{greeting_prefix}, {name}!\\n\"\n<\/code><\/pre>\n\n\n\n<p>Create <code>requirements.txt<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-text\">functions-framework==3.*\nFlask==3.*\n<\/code><\/pre>\n\n\n\n<p><strong>Why these dependencies?<\/strong> The Functions Framework is commonly used for local testing and for some build\/deploy paths. Exact dependency requirements can vary by runtime\/build method\u2014verify if your chosen workflow differs.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have two files: <code>main.py<\/code> and <code>requirements.txt<\/code>.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ls -la\n<\/code><\/pre>\n\n\n\n<p>Optional: run locally (helpful before deploying):<\/p>\n\n\n\n<pre><code class=\"language-bash\">python3 -m venv .venv\nsource .venv\/bin\/activate\npip install -r requirements.txt\nfunctions-framework --target=hello_http --port=8080\n<\/code><\/pre>\n\n\n\n<p>Then in another terminal:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl \"http:\/\/localhost:8080\/?name=local\"\n<\/code><\/pre>\n\n\n\n<p>Stop the local server with Ctrl+C.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Deploy as Cloud Run functions<\/h3>\n\n\n\n<p>You can deploy via Console or CLI. The CLI example below uses the Cloud Functions Gen2 command, which deploys to the Cloud Run-based platform.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: Deploy using <code>gcloud<\/code> (common workflow)<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud functions deploy hello-http \\\n  --gen2 \\\n  --runtime=python311 \\\n  --region=us-central1 \\\n  --source=. \\\n  --entry-point=hello_http \\\n  --trigger-http \\\n  --allow-unauthenticated\n<\/code><\/pre>\n\n\n\n<p>Notes:\n&#8211; <code>--gen2<\/code> indicates Cloud Run-based functions (Cloud Run functions \/ Cloud Functions 2nd gen).\n&#8211; <code>--allow-unauthenticated<\/code> makes the endpoint public for learning. For production, prefer IAM-protected invocation.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Deployment completes and prints an HTTPS URL.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud functions describe hello-http --gen2 --region=us-central1 --format=\"value(serviceConfig.uri)\"\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: Deploy using the Google Cloud Console<\/h4>\n\n\n\n<p>If you prefer UI:\n1. Console \u2192 <strong>Cloud Run<\/strong> (or <strong>Cloud Run functions<\/strong>, depending on Console navigation)\n2. Create \u2192 Function\n3. Choose region\n4. Trigger: HTTP\n5. Runtime: Python (choose a supported version)\n6. Paste <code>main.py<\/code> and set entry point <code>hello_http<\/code>\n7. Deploy<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Console shows the function and an endpoint URL.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Invoke the function<\/h3>\n\n\n\n<p>Get the URL (if you didn\u2019t already):<\/p>\n\n\n\n<pre><code class=\"language-bash\">URL=\"$(gcloud functions describe hello-http --gen2 --region=us-central1 --format='value(serviceConfig.uri)')\"\necho \"$URL\"\n<\/code><\/pre>\n\n\n\n<p>Invoke it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl \"${URL}\/?name=cloud\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Response similar to:<\/p>\n\n\n\n<pre><code class=\"language-text\">Hello, cloud!\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: View logs<\/h3>\n\n\n\n<p>View recent logs in the Console:\n&#8211; Console \u2192 Logging \u2192 Logs Explorer\n&#8211; Filter by resource\/function name (UI varies)<\/p>\n\n\n\n<p>Or use <code>gcloud<\/code> to read logs (approach varies by resource type; Cloud Run-backed functions often appear as Cloud Run revisions\/services in logs). A practical approach is to use Logs Explorer and filter by the function name <code>hello-http<\/code>.<\/p>\n\n\n\n<p>A simple CLI query (may need adjustment\u2014verify in your environment):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud logging read \\\n  'resource.type=(\"cloud_run_revision\" OR \"cloud_function\") AND textPayload:\"Request received\"' \\\n  --limit=20 \\\n  --freshness=1h\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see the <code>print(...)<\/code> log entries with <code>user_agent<\/code> and <code>name<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Update configuration (environment variable) and redeploy<\/h3>\n\n\n\n<p>Set an environment variable to customize the greeting:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud functions deploy hello-http \\\n  --gen2 \\\n  --runtime=python311 \\\n  --region=us-central1 \\\n  --source=. \\\n  --entry-point=hello_http \\\n  --trigger-http \\\n  --allow-unauthenticated \\\n  --set-env-vars=GREETING_PREFIX=Hi\n<\/code><\/pre>\n\n\n\n<p>Invoke again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl \"${URL}\/?name=updated\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-text\">Hi, updated!\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) Function exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud functions list --gen2 --region=us-central1\n<\/code><\/pre>\n\n\n\n<p>2) URL resolves:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"${URL}\/?name=validate\"\n<\/code><\/pre>\n\n\n\n<p>You should see an HTTP 200 and expected response text.<\/p>\n\n\n\n<p>3) Logs show invocation:\n&#8211; Logs Explorer shows \u201cRequest received\u2026\u201d<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and realistic fixes:<\/p>\n\n\n\n<p><strong>Issue: API not enabled \/ permission denied<\/strong>\n&#8211; Symptoms: deployment fails with \u201cnot enabled\u201d or \u201cpermission denied\u201d.\n&#8211; Fix:\n  &#8211; Enable APIs (Step 2)\n  &#8211; Confirm your identity and project:\n    <code>bash\n    gcloud auth list\n    gcloud config get-value project<\/code>\n  &#8211; Ensure you have sufficient IAM roles in the project.<\/p>\n\n\n\n<p><strong>Issue: Build fails (dependency error)<\/strong>\n&#8211; Symptoms: Cloud Build fails, missing packages, incompatible versions.\n&#8211; Fix:\n  &#8211; Ensure <code>requirements.txt<\/code> is present and pinned reasonably.\n  &#8211; Avoid OS-level dependencies in this simple lab.\n  &#8211; Check Cloud Build logs in the Console (Cloud Build \u2192 History).<\/p>\n\n\n\n<p><strong>Issue: Wrong entry point<\/strong>\n&#8211; Symptoms: deploy succeeds but runtime errors like \u201cfunction not found\u201d.\n&#8211; Fix:\n  &#8211; Ensure <code>--entry-point=hello_http<\/code> matches the function name in <code>main.py<\/code>.<\/p>\n\n\n\n<p><strong>Issue: 403 Forbidden when invoking<\/strong>\n&#8211; Symptoms: <code>curl<\/code> returns 403.\n&#8211; Cause: endpoint requires authentication (or you removed <code>--allow-unauthenticated<\/code>).\n&#8211; Fix (if you intentionally require auth): use an identity token (for IAM-protected HTTP endpoints):\n  <code>bash\n  curl -H \"Authorization: Bearer $(gcloud auth print-identity-token)\" \"${URL}\/?name=auth\"<\/code>\n  If this still fails, verify IAM bindings for invoker access in the Console and consult Cloud Run IAM docs.<\/p>\n\n\n\n<p><strong>Issue: Slow first request<\/strong>\n&#8211; Symptoms: first call takes noticeably longer.\n&#8211; Cause: cold start.\n&#8211; Fix:\n  &#8211; Consider min instances in production (adds baseline cost).\n  &#8211; Reduce dependency size and improve startup time.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the deployed function:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud functions delete hello-http --gen2 --region=us-central1 --quiet\n<\/code><\/pre>\n\n\n\n<p>Also consider cleaning up build artifacts (optional but recommended for repeated labs):\n&#8211; Check Artifact Registry for images created during builds and delete if not needed.\n&#8211; Review Cloud Build history.<\/p>\n\n\n\n<p>If you created a dedicated project for this lab, you can delete the project (most thorough cleanup):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects delete YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Keep functions small and single-purpose.<\/strong> A function should do one job well (webhook handler, event processor).<\/li>\n<li><strong>Separate ingestion from processing.<\/strong> For heavy work, ingest quickly and push to Pub\/Sub or a workflow engine.<\/li>\n<li><strong>Make processing idempotent.<\/strong> Event delivery can be duplicated; design for at-least-once semantics unless you have guarantees (verify per trigger).<\/li>\n<li><strong>Prefer managed services for state.<\/strong> Store state in Firestore\/Cloud SQL\/BigQuery rather than local filesystem.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use least privilege service accounts<\/strong> for runtime identity.<\/li>\n<li><strong>Avoid public endpoints<\/strong> unless necessary. Prefer IAM-protected invocation for internal services.<\/li>\n<li><strong>Grant invoker permissions explicitly<\/strong> to calling identities (users, service accounts).<\/li>\n<li><strong>Use separate service accounts per environment<\/strong> (dev\/stage\/prod) and per sensitivity domain where practical.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Right-size memory and CPU.<\/strong> Measure runtime and memory usage; tune based on p95.<\/li>\n<li><strong>Control logging volume.<\/strong> Use structured logs and avoid logging entire payloads.<\/li>\n<li><strong>Avoid unnecessary min instances.<\/strong> Use min instances only when latency SLO requires it and cost is justified.<\/li>\n<li><strong>Reduce build frequency<\/strong> in CI by caching dependencies and avoiding unnecessary deployments.<\/li>\n<li><strong>Keep resources regional<\/strong> to reduce data transfer and latency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Optimize cold start time<\/strong>: minimize dependencies; initialize clients lazily when safe.<\/li>\n<li><strong>Reuse connections<\/strong>: keep HTTP sessions and database client objects in global scope (but ensure concurrency safety).<\/li>\n<li><strong>Use concurrency safely<\/strong>: if you configure concurrency &gt; 1, ensure thread-safety and avoid global mutable state.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use retries carefully<\/strong>: distinguish between transient and permanent errors.<\/li>\n<li><strong>Use timeouts<\/strong> for outbound calls; don\u2019t rely on defaults.<\/li>\n<li><strong>Emit metrics or structured logs<\/strong> for business events (success\/failure, latency).<\/li>\n<li><strong>Implement dead-letter patterns<\/strong> for message processing (Pub\/Sub DLQ patterns where applicable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use Cloud Monitoring alerts<\/strong> for:<\/li>\n<li>error rate spikes<\/li>\n<li>latency increases<\/li>\n<li>abnormal scaling behavior<\/li>\n<li><strong>Tag\/label resources<\/strong> for ownership and cost allocation.<\/li>\n<li><strong>Use consistent naming<\/strong>:<\/li>\n<li><code>fn-&lt;domain&gt;-&lt;purpose&gt;-&lt;env&gt;<\/code><\/li>\n<li>Example: <code>fn-billing-webhook-prod<\/code><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use project\/folder structure aligned to environments.<\/li>\n<li>Use labels like:<\/li>\n<li><code>env=prod<\/code><\/li>\n<li><code>team=payments<\/code><\/li>\n<li><code>cost_center=cc123<\/code><\/li>\n<li>Enforce policy using Organization Policy constraints where applicable (verify controls in your org).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<p>Cloud Run functions security is primarily IAM-driven:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deployer identity<\/strong>: who can deploy\/update the function.<\/li>\n<li><strong>Runtime identity (service account)<\/strong>: what the function can access (databases, secrets, APIs).<\/li>\n<li><strong>Invoker identity<\/strong> (HTTP): who can call the endpoint if not public.<\/li>\n<\/ul>\n\n\n\n<p>Recommendations:\n&#8211; Use a <strong>dedicated runtime service account<\/strong> per function or per service boundary.\n&#8211; Grant only required roles (least privilege).\n&#8211; Avoid using broad roles like Owner\/Editor in production.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data in transit: HTTPS for HTTP functions.<\/li>\n<li>Data at rest: Google-managed encryption for many services by default.<\/li>\n<li>For compliance, consider CMEK where supported by dependent services (Cloud Run and surrounding services have evolving CMEK support\u2014verify in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public HTTP endpoints are easy to create and easy to misconfigure.<\/li>\n<li>Prefer:<\/li>\n<li>IAM-protected invocation<\/li>\n<li>Private egress to internal resources (VPC connectivity)<\/li>\n<li>API Gateway \/ Cloud Endpoints patterns when you need API keys, quotas, or advanced auth (verify best fit for your use case)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Secret Manager<\/strong> for secrets rather than embedding them in code or plain env vars.<\/li>\n<li>Restrict secret access to the runtime service account only.<\/li>\n<li>Rotate secrets and audit access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Cloud Audit Logs for admin activity.<\/li>\n<li>Ensure you log security-relevant events (auth failures, signature validation failures).<\/li>\n<li>Avoid logging sensitive payloads (PII, credentials, tokens).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose region based on data residency requirements.<\/li>\n<li>Control access via IAM and VPC.<\/li>\n<li>Retain logs according to your policy; configure log sinks if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploying with <code>--allow-unauthenticated<\/code> for production endpoints<\/li>\n<li>Over-permissioned runtime service accounts<\/li>\n<li>Storing secrets in source code or in environment variables without Secret Manager<\/li>\n<li>Allowing outbound egress to the internet when only private access is needed<\/li>\n<li>Logging entire request bodies containing sensitive data<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use separate projects for dev\/stage\/prod.<\/li>\n<li>Use CI\/CD with approvals for production.<\/li>\n<li>Use vulnerability scanning for artifacts where applicable (Artifact Registry supports scanning in some configurations\u2014verify).<\/li>\n<li>Implement request validation, signature verification, and strict input parsing.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Limits and defaults evolve. Treat this section as a checklist and <strong>verify exact quotas and limits in official docs<\/strong> and the Quotas page in your project.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ common constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cold starts<\/strong>: scale-to-zero can introduce first-request latency.<\/li>\n<li><strong>Execution timeouts<\/strong>: functions have a maximum timeout; Gen2\/Cloud Run-based functions generally support longer timeouts than Gen1, but verify exact values.<\/li>\n<li><strong>Request\/response size limits<\/strong>: large payloads may require using Cloud Storage signed URLs instead of sending large bodies.<\/li>\n<li><strong>Runtime constraints<\/strong>: only supported runtimes\/versions are available.<\/li>\n<li><strong>Event delivery semantics<\/strong>: many event systems are at-least-once; duplicates can happen.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Max instances<\/li>\n<li>Concurrency<\/li>\n<li>Requests per second (soft limits)<\/li>\n<li>Build concurrency (Cloud Build quotas)<\/li>\n<li>Artifact storage size and retention<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all regions support all features (event sources, networking features).<\/li>\n<li>Co-locate your function and dependencies in the same region when possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>High log volume<\/li>\n<li>Frequent CI builds producing many artifacts<\/li>\n<li>Eventarc delivery charges (if used)<\/li>\n<li>Network egress to external APIs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Libraries that require native system dependencies may fail in source-based builds.<\/li>\n<li>Long-lived connections or background threads may not behave as expected in serverless environments.<\/li>\n<li>Concurrency can expose thread-safety issues.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Assuming exactly-once processing<\/li>\n<li>Not implementing idempotency keys<\/li>\n<li>Not setting outbound HTTP timeouts and retries<\/li>\n<li>Treating ephemeral filesystem as durable storage<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from older Cloud Functions (Gen1) to Cloud Run functions (Gen2\/Cloud Run-based) may change:<\/li>\n<li>event trigger configuration<\/li>\n<li>runtime behavior<\/li>\n<li>networking model and egress<\/li>\n<li>timeout and concurrency defaults<\/li>\n<li>IAM bindings and invoker role expectations<br\/>\n  Plan and test carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances (Google Cloud)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The \u201cfunctions\u201d experience is now tightly integrated with Cloud Run resources and concepts.<\/li>\n<li>Some management operations may appear in Cloud Run (revisions, services) even when you think you are managing \u201conly functions\u201d.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Cloud Run functions sits in a landscape of serverless and container platforms.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Cloud Run functions<\/strong> (Google Cloud)<\/td>\n<td>HTTP\/event-driven function workloads<\/td>\n<td>Fast deploy, minimal ops, scales automatically, integrates with Google Cloud eventing<\/td>\n<td>Cold starts, runtime constraints, less control than full containers<\/td>\n<td>Small units of logic, webhooks, event processing<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Run services<\/strong> (Google Cloud)<\/td>\n<td>Full microservices in containers<\/td>\n<td>Full container control, great for APIs and services, Cloud Run scaling<\/td>\n<td>You manage container build and app structure<\/td>\n<td>When you need custom dependencies, frameworks, multiple routes<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Functions (Gen1)<\/strong> (Google Cloud, legacy)<\/td>\n<td>Legacy functions<\/td>\n<td>Simple model<\/td>\n<td>More constraints; many orgs migrate to Gen2\/Cloud Run-based<\/td>\n<td>Only for legacy compatibility; plan migration<\/td>\n<\/tr>\n<tr>\n<td><strong>App Engine<\/strong> (Google Cloud)<\/td>\n<td>PaaS web apps (certain patterns)<\/td>\n<td>Managed platform, mature<\/td>\n<td>Less aligned with modern container workflows; constraints<\/td>\n<td>Existing App Engine apps or specific PaaS needs<\/td>\n<\/tr>\n<tr>\n<td><strong>GKE (Google Kubernetes Engine)<\/strong><\/td>\n<td>Complex platforms and multi-service systems<\/td>\n<td>Maximum control, Kubernetes ecosystem<\/td>\n<td>High ops overhead and cost, requires expertise<\/td>\n<td>When you need Kubernetes primitives, service mesh, custom scheduling<\/td>\n<\/tr>\n<tr>\n<td><strong>Compute Engine<\/strong><\/td>\n<td>VM-hosted apps<\/td>\n<td>Full control, lift-and-shift<\/td>\n<td>Most ops burden<\/td>\n<td>When you require OS control or legacy workloads<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Lambda<\/strong> (AWS)<\/td>\n<td>Serverless functions<\/td>\n<td>Mature ecosystem, many integrations<\/td>\n<td>Different event model\/pricing\/tooling<\/td>\n<td>Multi-cloud strategy or AWS-native workloads<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Functions<\/strong> (Azure)<\/td>\n<td>Serverless functions<\/td>\n<td>Strong MS ecosystem integration<\/td>\n<td>Different triggers and runtime model<\/td>\n<td>Azure-native workloads<\/td>\n<\/tr>\n<tr>\n<td><strong>Knative (self-managed)<\/strong><\/td>\n<td>Serverless on Kubernetes<\/td>\n<td>Portability, open-source<\/td>\n<td>You operate Kubernetes and Knative<\/td>\n<td>When you need portability and accept ops overhead<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Event-driven document processing pipeline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A large enterprise receives documents from multiple systems and needs to classify, extract metadata, and route them to downstream apps with auditability.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Upload documents to Cloud Storage<\/li>\n<li>Event routed to processing using an eventing mechanism (often Eventarc) that triggers Cloud Run functions<\/li>\n<li>Cloud Run functions performs lightweight validation and enqueues a message for heavy processing<\/li>\n<li>Heavy processing runs on Cloud Run services or batch (depending on compute needs)<\/li>\n<li>Metadata stored in a managed database (Firestore\/Cloud SQL)<\/li>\n<li>Centralized logging and monitoring with alerting<\/li>\n<li><strong>Why Cloud Run functions was chosen:<\/strong><\/li>\n<li>Fast-to-deploy event handlers for ingestion and routing logic<\/li>\n<li>Scale with bursts (end-of-month spikes)<\/li>\n<li>Integrates with IAM and audit logging for governance<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced ops overhead compared to VM-based workers<\/li>\n<li>Improved resiliency during spikes<\/li>\n<li>Better audit trails and standardized deployments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Webhook-based user provisioning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup needs to provision users when payments succeed and notify internal systems, without building a full backend.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Payment provider sends HTTPS webhook to a Cloud Run function<\/li>\n<li>Function verifies signature and writes minimal state<\/li>\n<li>Function publishes a message to Pub\/Sub for downstream actions (email, analytics)<\/li>\n<li><strong>Why Cloud Run functions was chosen:<\/strong><\/li>\n<li>Minimal infrastructure and fast iteration<\/li>\n<li>Scale-to-zero reduces idle cost<\/li>\n<li>Simple deployment workflow that fits small-team velocity<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster feature delivery<\/li>\n<li>Lower baseline cost<\/li>\n<li>Cleaner separation of \u201cingest\/validate\u201d vs \u201cprocess asynchronously\u201d<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Cloud Run functions the same as Cloud Functions?<\/strong><br\/>\nCloud Run functions is the Cloud Run-based functions experience aligned with what many people know as Cloud Functions (2nd gen). You may still see Cloud Functions terminology in tools\/docs. Verify current naming in official docs.<\/p>\n\n\n\n<p>2) <strong>When should I choose Cloud Run functions over Cloud Run services?<\/strong><br\/>\nChoose Cloud Run functions for small, single-purpose HTTP or event handlers. Choose Cloud Run services when you need full container control, multiple endpoints, custom OS dependencies, or broader microservice design.<\/p>\n\n\n\n<p>3) <strong>Does Cloud Run functions scale to zero?<\/strong><br\/>\nTypically yes for request-driven workloads. Some configurations (like min instances) or event patterns can change behavior\u2014verify for your use case.<\/p>\n\n\n\n<p>4) <strong>Are Cloud Run functions HTTP endpoints public by default?<\/strong><br\/>\nNot necessarily; you can configure public or IAM-protected access. Many quickstarts allow unauthenticated for simplicity. For production, prefer restricted invocation.<\/p>\n\n\n\n<p>5) <strong>How do I secure an HTTP function?<\/strong><br\/>\nUse IAM-based authentication (require invoker permission) and call it with an identity token from a trusted principal. For public webhooks, use signature verification and strict validation.<\/p>\n\n\n\n<p>6) <strong>How do event triggers work?<\/strong><br\/>\nEvents from Google Cloud services are routed to the function (often through Eventarc). The exact supported event sources and configuration steps depend on your region and product status\u2014verify in official docs.<\/p>\n\n\n\n<p>7) <strong>What are the main cost drivers?<\/strong><br\/>\nInvocation volume, execution time, memory\/CPU sizing, networking egress, logging volume, build frequency, and event routing\/messaging charges.<\/p>\n\n\n\n<p>8) <strong>What languages are supported?<\/strong><br\/>\nCloud Run functions supports multiple runtimes (commonly including Node.js, Python, Go, Java, .NET, and others depending on current support). Verify the supported runtime list in the official docs.<\/p>\n\n\n\n<p>9) <strong>How do I connect to Cloud SQL securely?<\/strong><br\/>\nUse supported private connectivity patterns and IAM. Common approaches include private IP with serverless VPC connectivity and\/or Cloud SQL connectors. Verify recommended pattern for Cloud Run functions.<\/p>\n\n\n\n<p>10) <strong>Do I need to create a container image myself?<\/strong><br\/>\nNot usually. Cloud Run functions can build from source using managed build tooling. If you need full control, consider Cloud Run services with a custom container.<\/p>\n\n\n\n<p>11) <strong>How do I handle retries and duplicate events?<\/strong><br\/>\nAssume duplicates can happen in many event-driven systems. Use idempotency keys, deduplication, and careful transaction boundaries.<\/p>\n\n\n\n<p>12) <strong>How can I reduce cold starts?<\/strong><br\/>\nMinimize dependencies, optimize initialization, and consider min instances (with cost tradeoffs). Keep the function warm only when required by SLO.<\/p>\n\n\n\n<p>13) <strong>How do I observe performance and errors?<\/strong><br\/>\nUse Cloud Logging for structured logs, Cloud Monitoring for metrics and alerts, and error reporting tools. Add trace correlation IDs to logs.<\/p>\n\n\n\n<p>14) <strong>Can I run background threads or long-running processes?<\/strong><br\/>\nServerless environments are designed for request\/event-driven execution. Long-running background processes are better suited to Cloud Run services, Cloud Run jobs, or GKE\u2014depending on requirements.<\/p>\n\n\n\n<p>15) <strong>How do I do CI\/CD for Cloud Run functions?<\/strong><br\/>\nUse Cloud Build or external CI to run tests and deploy using CLI commands. Store configuration in code, use separate environments, and apply approvals for production.<\/p>\n\n\n\n<p>16) <strong>What\u2019s the best way to manage configuration?<\/strong><br\/>\nUse environment variables for non-sensitive config, Secret Manager for secrets, and keep per-environment values in your deployment pipeline.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Cloud Run functions<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud Run functions overview \u2014 https:\/\/cloud.google.com\/run\/docs\/functions\/overview<\/td>\n<td>Canonical overview of what Cloud Run functions is and how it maps to Cloud Run<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud Run documentation \u2014 https:\/\/cloud.google.com\/run\/docs<\/td>\n<td>Core Cloud Run concepts (revisions, scaling, IAM) that also apply to functions<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Cloud Run pricing \u2014 https:\/\/cloud.google.com\/run\/pricing<\/td>\n<td>Up-to-date pricing model and free tier details<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Estimate costs with your region and usage assumptions<\/td>\n<\/tr>\n<tr>\n<td>Official docs (eventing)<\/td>\n<td>Eventarc documentation \u2014 https:\/\/cloud.google.com\/eventarc\/docs<\/td>\n<td>Learn event routing patterns and configuration<\/td>\n<\/tr>\n<tr>\n<td>Official docs (messaging)<\/td>\n<td>Pub\/Sub documentation \u2014 https:\/\/cloud.google.com\/pubsub\/docs<\/td>\n<td>Messaging triggers, patterns, and cost drivers<\/td>\n<\/tr>\n<tr>\n<td>Official docs (build)<\/td>\n<td>Cloud Build documentation \u2014 https:\/\/cloud.google.com\/build\/docs<\/td>\n<td>Understand build logs, triggers, and troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Official docs (artifacts)<\/td>\n<td>Artifact Registry documentation \u2014 https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<td>Manage artifacts\/images produced during builds<\/td>\n<\/tr>\n<tr>\n<td>Official docs (secrets)<\/td>\n<td>Secret Manager documentation \u2014 https:\/\/cloud.google.com\/secret-manager\/docs<\/td>\n<td>Secure secrets storage and access patterns<\/td>\n<\/tr>\n<tr>\n<td>Official docs (networking)<\/td>\n<td>Serverless VPC Access documentation \u2014 https:\/\/cloud.google.com\/vpc\/docs\/serverless-vpc-access<\/td>\n<td>Connect serverless runtimes to VPC resources<\/td>\n<\/tr>\n<tr>\n<td>Official docs (observability)<\/td>\n<td>Cloud Logging documentation \u2014 https:\/\/cloud.google.com\/logging\/docs<\/td>\n<td>Query and manage logs, sinks, retention<\/td>\n<\/tr>\n<tr>\n<td>Official docs (observability)<\/td>\n<td>Cloud Monitoring documentation \u2014 https:\/\/cloud.google.com\/monitoring\/docs<\/td>\n<td>Metrics, dashboards, alerts for production workloads<\/td>\n<\/tr>\n<tr>\n<td>Official docs (legacy reference)<\/td>\n<td>Cloud Functions documentation \u2014 https:\/\/cloud.google.com\/functions\/docs<\/td>\n<td>Useful cross-reference if you see older workflows; confirm Gen2\/Cloud Run alignment<\/td>\n<\/tr>\n<tr>\n<td>Official samples<\/td>\n<td>GoogleCloudPlatform GitHub \u2014 https:\/\/github.com\/GoogleCloudPlatform<\/td>\n<td>Many official samples and reference implementations (search for Cloud Run \/ Functions)<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Google Cloud Tech (YouTube) \u2014 https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Product deep-dives, architecture talks, and walkthroughs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, developers<\/td>\n<td>DevOps practices, CI\/CD, cloud operations, platform engineering basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>SCM, DevOps foundations, tooling and process<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud engineers, operations teams<\/td>\n<td>Cloud operations, deployment, monitoring basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform engineers<\/td>\n<td>Reliability engineering, monitoring, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops\/SRE\/IT teams<\/td>\n<td>AIOps concepts, automation, monitoring-driven operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify offerings)<\/td>\n<td>Beginners to intermediate<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and guidance (verify offerings)<\/td>\n<td>DevOps engineers, students<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps support\/training resources (verify offerings)<\/td>\n<td>Small teams, practitioners<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and enablement resources (verify offerings)<\/td>\n<td>Operations and DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog)<\/td>\n<td>Cloud adoption, CI\/CD, platform setup<\/td>\n<td>Cloud Run functions rollout patterns, CI\/CD pipelines, observability baselines<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify service catalog)<\/td>\n<td>DevOps transformation, tooling, enablement<\/td>\n<td>Standardized serverless deployment workflows, security reviews, ops runbooks<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service catalog)<\/td>\n<td>Implementations, automation, DevOps processes<\/td>\n<td>Build\/deploy automation for Google Cloud serverless, cost optimization assessments<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Cloud Run functions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals: projects, IAM, billing, regions<\/li>\n<li>Basic networking: HTTP, TLS, DNS concepts<\/li>\n<li>Basic application development in one runtime (Python\/Node\/Go\/Java)<\/li>\n<li>Git and CI\/CD basics<\/li>\n<li>Observability basics: logs, metrics, tracing concepts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Cloud Run functions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run services (containers) for more complex microservices<\/li>\n<li>Event-driven architecture patterns with Pub\/Sub and Eventarc<\/li>\n<li>API management (API Gateway or Apigee, depending on needs\u2014verify current options)<\/li>\n<li>Secure networking: VPC design, private connectivity, serverless egress patterns<\/li>\n<li>Infrastructure as Code (Terraform) for repeatable deployments<\/li>\n<li>SRE practices: SLOs, error budgets, incident response<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer<\/li>\n<li>DevOps engineer<\/li>\n<li>SRE \/ Platform engineer<\/li>\n<li>Backend developer<\/li>\n<li>Solutions architect<\/li>\n<li>Cloud security engineer (for IAM, secrets, compliance patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Google Cloud certifications change over time. Common relevant tracks include:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Developer\n&#8211; Professional Cloud DevOps Engineer\n&#8211; Professional Cloud Architect<\/p>\n\n\n\n<p>Verify current certifications: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Build a webhook receiver with signature verification and structured logs.<\/li>\n<li>Implement Pub\/Sub-driven processing with idempotency and a dead-letter topic.<\/li>\n<li>Create a scheduled function that aggregates metrics and writes to BigQuery.<\/li>\n<li>Secure an internal function with IAM and invoke it from another service account.<\/li>\n<li>Build a multi-environment pipeline (dev\/stage\/prod) with separate projects and CI approvals.<\/li>\n<li>Implement cost controls: log sampling, right-sized memory, artifact retention cleanup.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Run functions<\/strong>: Function deployment experience on Google Cloud backed by Cloud Run.<\/li>\n<li><strong>Cloud Run<\/strong>: Fully managed serverless platform to run containers, supporting services and jobs.<\/li>\n<li><strong>Cloud Functions (Gen2)<\/strong>: Cloud Run-based generation of Cloud Functions; closely aligned with Cloud Run functions naming.<\/li>\n<li><strong>Eventarc<\/strong>: Google Cloud service for routing events from sources to targets (like Cloud Run).<\/li>\n<li><strong>Pub\/Sub<\/strong>: Managed messaging service for asynchronous communication.<\/li>\n<li><strong>IAM (Identity and Access Management)<\/strong>: Role-based access control for Google Cloud resources.<\/li>\n<li><strong>Service account<\/strong>: A non-human identity used by workloads to access Google Cloud APIs.<\/li>\n<li><strong>Invoker<\/strong>: IAM permission concept controlling who can call an HTTP endpoint.<\/li>\n<li><strong>Cold start<\/strong>: Latency introduced when a serverless platform starts a new instance from zero.<\/li>\n<li><strong>Concurrency<\/strong>: Number of simultaneous requests a single instance can handle.<\/li>\n<li><strong>Scale to zero<\/strong>: Automatically reducing instances to zero when idle to save cost.<\/li>\n<li><strong>Cloud Build<\/strong>: Managed CI service that builds artifacts from source.<\/li>\n<li><strong>Artifact Registry<\/strong>: Managed registry to store container images and artifacts.<\/li>\n<li><strong>Cloud Logging<\/strong>: Central log management in Google Cloud.<\/li>\n<li><strong>Cloud Monitoring<\/strong>: Metrics, dashboards, and alerting in Google Cloud.<\/li>\n<li><strong>Idempotency<\/strong>: Ability to process the same event multiple times with the same result (critical for at-least-once delivery).<\/li>\n<li><strong>Egress<\/strong>: Outbound network traffic leaving a service to the internet or another network.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Cloud Run functions (Google Cloud) is a serverless <strong>application hosting<\/strong> option for deploying <strong>single-purpose functions<\/strong> triggered by HTTP requests or events, running on <strong>Cloud Run\u2019s managed infrastructure<\/strong>. It matters because it enables fast delivery of small services and event handlers with autoscaling and a low operations footprint.<\/p>\n\n\n\n<p>Architecturally, it fits best for webhooks, lightweight APIs, automation, and event-driven processing\u2014especially when combined with Pub\/Sub, Eventarc, Secret Manager, and Cloud Logging\/Monitoring. Cost is primarily driven by invocation volume, runtime duration, memory\/CPU sizing, build and artifact overhead, logging volume, and any eventing\/messaging\/networking services in the architecture. Security hinges on IAM: use least privilege service accounts, restrict invoker access where possible, and store secrets in Secret Manager.<\/p>\n\n\n\n<p>Use Cloud Run functions when you want function-level simplicity and managed scaling. Move to Cloud Run services or GKE when you need more control, more complex service patterns, or custom runtime dependencies.<\/p>\n\n\n\n<p><strong>Next step:<\/strong> read the Cloud Run functions overview and deploy a second function triggered by an event source relevant to your workflow (Pub\/Sub is a common starting point), using the official docs: https:\/\/cloud.google.com\/run\/docs\/functions\/overview<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Application hosting<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[57,51],"tags":[],"class_list":["post-618","post","type-post","status-publish","format-standard","hentry","category-application-hosting","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/618","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=618"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/618\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=618"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=618"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=618"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}