Serverless beyond functions Mete Atamel Developer Advocate at Google @meteatamel atamel.dev speakerdeck.com/meteatamel

Serverless Operational Model Programming Model No Infra Management Managed Security Pay only for usage Service-based Event-driven Stateless

Different phases of serverless 00|Serverless, before it was called serverless 01|Simple functions 02|Containers and serverless maturity 03|Expansion and integration of serverless

Serverless, before it was called serverless 00|Phases of Serverless

App Engine Launched by Google in 2008 Make it easy for developers to build, manage, and scale web applications Write some Python, run a command line tool to upload the code to Google, and that was it Fully managed: No servers to provision, no database to manage, no networking to configure

00|State of fully managed ✅ Paved the way and the vision for serverless ❌ Very limited languages & versions ❌ Only HTTP ❌ Very limited ecosystem, vendor lock-in ❌ On-prem VMs → fully managed App Engine was a big step

Simple Functions 01|Phases of Serverless

AWS Lambda, Google Cloud Functions, Azure Functions AWS Lambda popularized serverless (2014) Google Cloud Functions Azure Functions (2016) /** * Google Cloud Functions responding to any HTTP request. * * @param {!express:Request} req HTTP request context. * @param {!express:Response} res HTTP response context. */ exports.helloWorld = (req, res) => { let message = req.body.message || 'Hello World!'; res.status(200).send(message); };

Languages & versions Google Cloud Functions AWS Lambda* Azure Functions** Node.js 10, 12, 14, 16 10, 12, 14 6, 8, 10, 12, 14, 16 Python 3.7, 3.8, 3.9 2.7, 3.6, 3.7, 3.8, 3.9 3.6, 3.7, 3.8, 3.9 Go 1.11, 1.13, 1.16 1.x ? Java 11 8, 11 8, 11 C# 3.1 2.1, 3.1 2.1, 3.1, 5, 6 Ruby 2.6, 2.7 2.5, 2.7 ? PHP 7.4 ? ? * Supports custom runtimes and containers ** Supports F#, PowerShell and Typescript via transpiling to Javascript

HTTP and other handful triggers Cloud Functions (gen1) Cloud Storage Cloud Pub/Sub HTTPS Firebase Cloud Scheduler Cloud Tasks

● HTTP request based (no background/non-HTTP tasks) ● Request processing time: default 1 min and max 9 mins ● Max 8 GB memory and 2 vCPU Execution model, time, and resources Cloud Functions (gen1)

No concurrency + no min instances = cold start concurrency = 1 Cloud Functions (gen1)

Grouping HTTP functions AWS: API Gateway (2015) Google: API Gateway, Apigee Azure: API Management Used to be the only way to expose HTTP functions in AWS One function one path: API Gateway to group functions into APIs

01|State of serverless ❌ Limited languages & versions ❌ Limited triggers ❌ Limited execution model, time, and resources ❌ No concurrency + no min instances = cold start ❌ Limited local development ❌ Some grouping for HTTP functions but no orchestration

Containers and serverless maturity 02|Phases of Serverless

Proprietary + Confidential .js Any language Rich ecosystem Any library .rb .go .py .sh … 0 1 0 1 0 0 1 1 1 Containers Containers Flexibility Serverless Velocity

Serverless Containers Google: Cloud Run AWS: App Runner, AWS Fargate, AWS Lambda Azure: Container Instances

Serverless containers with Knative and Cloud Run Cloud Run Serverless containers, fully managed, no cluster Cloud Run on GKE/Anthos Serverless containers on GKE/Anthos in Google Cloud Knative everywhere Serverless containers on everywhere you run Kubernetes

Proprietary + Confidential Container contract & resources ● Listen on 0.0.0.0 on port $PORT (default 8080) ● HTTP server must start < 4 min (timeout → 504) ● Request time < 5 min (default → 5 min, up to 60 min) ● Stateless (in-memory file system) ● Computation only within request (No background activity) ● 1 vCPU per container instance (configurable to 4 vCPU) ● 256 MiB of memory up to a max of 8 GiB (configurable, soon 16 GiB) ● 80 concurrent requests per container (configurable 1-80, soon 250) ● 100 max containers by default (configurable 1-1000, support overridable) ● Sandboxed by gVisor ● Ability to listen on multiple paths

Concurrency + min instances = Much improved cold start concurrency = 1 concurrency = 80 (default) - 1000 (max) Cloud Functions (gen1) Cloud Functions (gen2) Cloud Run

Local Development Containers Buildpacks Google: Functions Framework Google: Emulators for Pub/Sub, Datastore AWS: LocalStack

Other improvements Request processing time max 60 mins (Cloud Run & Functions gen2) Max memory 16 GB and CPU 8 vCPU (Cloud Run & Functions gen2) Always-on CPU for background processing (Cloud Run) Source based deployment / Buildpacks (Cloud Run) Richer protocols: Websockets, gRPC (client, server, bidirectional streaming) and server-sent events (Cloud Run)

Basic orchestration Drawing: Priyanka Vergadia AWS: CloudWatch Azure: Scheduler AWS: SQS Azure: Service Bus

02|State of serverless ✅ Any language & version ❌ Limited triggers ❓ Improved execution model, time, and resources ✅ Concurrency + min instances = Much improved cold start ✅ Some local development ❓ Some grouping & basic orchestration for HTTP functions

Expansion and integration of serverless 03|Phases of Serverless

Drawing: Priyanka Vergadia

AWS: SQS, SNS, EventBridge Azure: Event Grid, Event Hubs, Service Bus Drawing: Priyanka Vergadia

Targets Eventarc 60 gcp services 3K event types One Platform integration giving high quality event sources Cloud Functions Gen2 Preview Workflows Preview Cloud Run GA GKE Preview GCE SPR Anthos SPR HTTP, Google, 2P/3P apps Vision Eventarc Cloud Audit Logs GA Pub/sub GA Google Cloud Direct SPR Active SaaS connectors SPR Passive SaaS connectors SPR Custom apps SPR Google Vision Sources GA SPR Vision

AWS: Step Functions Azure: Durable Functions, Logic Apps Drawing: Priyanka Vergadia

Serverless Compute External API’s Google API’s etc... Workflows - orchestrate & integrate SaaS API’s Private API’s Other Clouds github.com/GoogleCloudPlatform/workflows-demos/tree/master/service-chaining

Choreography + Orchestration github.com/GoogleCloudPlatform/eventarc-samples/tree/main/processing-pipelines/image-v3

Serverless + Serverful You can combine Serverless orchestration and VMs for best of both worlds 1. Containerize the long-running task, so it can run anywhere. 2. Plan to run the container on a Compute Engine VM with no time limitations. 3. Automate the creation of the VM, running of the container on the VM, and deletion of the VM with Workflows. github.com/GoogleCloudPlatform/workflows-demos/tree/master/long-running-container

Non-HTTP / run-to-completion containers Cloud Run jobs (beta) enables non-HTTP containers to run to completion in serverless This enables batch/data processing kind of workloads that run to completion without the need to provision VMs github.com/GoogleCloudPlatform/jobs-demos

03|State of serverless ✅ Any language & version ✅ Rich triggers ✅ Improved execution model, time, and resources ✅ Concurrency + min instances = Much improved cold start ✅ Some local development ✅ Some grouping and rich orchestration

We didn’t even talk about serverless/managed data and services NoSQL: Google Firestore, Amazon DynamoDB, Azure Cosmos DB SQL: Google Spanner, Amazon Aurora, Azure SQL Database Data warehouse: Google BigQuery, Amazon Redshift Cache: Google Memorystore, Amazon ElastiCache, Azure Cache for Redis Services such as SendGrid, Twilio, etc.

Thank you! Mete Atamel Developer Advocate at Google @meteatamel atamel.dev speakerdeck.com/meteatamel Feedback? bit.ly/atamel