Serverless Containers with Knative & Cloud Run How can they help for app modernization? Mete Atamel Developer Advocate at Google @meteatamel speakerdeck.com/meteatamel 

Introduction 

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

Containers Any language Any library Ecosystem around containers .js .rb .go .py .sh … 0 1 0 1 0 0 1 1 1 

Containers Flexibility Serverless Velocity 

Cloud Run Fully managed, deploy your workloads and don’t see the cluster. Cloud Run on Anthos Deploy into Anthos, run serverless side-by-side with your existing workloads. Knative Everywhere Use the same APIs and tooling anywhere you run Kubernetes with Knative. Serverless containers with Knative and Cloud Run 

Knative 

Confidential & Proprietary What is Knative? Kubernetes based open source building blocks for serverless github.com/knative 

Knative and Cloud Run Stack Serving Eventing Kubernetes Platform Products Components Cloud Run Cloud Run on Anthos Istio Gateway *No eventing * * 

Confidential & Proprietary Knative Serving What is it? Rapid deployment of serverless containers Automatic (0-n) scaling Configuration and revision management Traffic splitting between revisions Pluggable Connect to your own logging and monitoring platform, or use the built-in system Auto-scaler can be tuned or swapped out for custom code 

Confidential & Proprietary Knative Serving Knative Service High level abstraction for the application Configuration Current/desired state of an application Code & configuration separated (a la 12-factor) Revision Point in time snapshots for your code and configuration Route Maps traffic to revisions 

Confidential & Proprietary Knative Eventing What is it? For loosely coupled, event-driven services with on/off cluster event sources Bind declaratively event sources, triggers and services Scales from just few events to live streams Uses standard CloudEvents Event type Flow Event source Event type Event type Event consumer(s) 

Confidential & Proprietary Knative Eventing Namespace subscribe Trigger Service (Callable) Broker Trigger Service (Callable) subscribe filter= filter= ✓ ✓ ✓ Source Events Source Events ingress ingress publish 

Confidential & Proprietary Knative Event Sources Name Description Apache Camel Allows to use Apache Camel components for pushing events into Knative Apache Kafka Brings Apache Kafka messages into Knative AWS SQS Brings AWS Simple Queue Service messages into Knative Cron Job Uses an in-memory timer to produce events on the specified Cron schedule. GCP PubSub Brings GCP PubSub messages into Knative GitHub Brings GitHub organization/repository events into Knative GitLab Brings GitLab repository events into Knative. Google Cloud Scheduler Google Cloud Scheduler events in Knative when jobs are triggered Google Cloud Storage Brings Google Cloud Storage bucket/object events into Knative Kubernetes Brings Kubernetes cluster/infrastructure events into Knative https://github.com/knative/docs/tree/master/docs/eventing/sources 

Confidential & Proprietary Knative Events { "specversion": "0.2", "type": "com.github.pull.create", "source": "https://github.com/cloudevents/spec/pull/123", "id": "A234-1234-1234", "time": "2019-04-08T17:31:00Z", "datacontenttype": "application/json", "data": "{ GitHub Payload... }" } FTP GitHub GCS Broker FTP Receive Adapter GitHub Receive Adapter GCS Receive Adapter CloudEvent 

Confidential & Proprietary Cloud Storage Events to Vision API Cloud Storage Bucket Cloud Storage -> Cloud PubSub -> Knative -> Vision API Cloud PubSub Topic Knative Eventing Knative Service Cloud Vision API Labels 1 2 3 4 5 6 

Cloud Run 

Container to production in seconds Natively Serverless One experience, where you want it Cloud Run Bringing serverless to containers 

HTTPS Endpoint Public • Website • API endpoint Private • Internal services • Async tasks • Mobile backend • Webhook 

Container contract Listen on 0.0.0.0 on port $PORT (default 8080) HTTP server must start < 4 min (timeout → 504) Request time < 15 min (default → 5 min) Stateless (in-memory file system, doesn’t persist) Computation only within request (No background activity) 

Container resources 1 vCPU per container instance (configurable to 2vCPU) 256 MiB of memory up to a max of 2 GiB (configurable) 80 concurrent requests per container (configurable 1-80) 1000 max containers by default (configurable 1-1000) Access to a Metadata Server Sandboxed by gVisor 

Pay per use CPU / Memory / Requests 100ms 

Billable time Instance Billable Time Request 1 Start Request 1 End Request 2 Start Request 2 End Instance Time Billable Non-billable 

Concurrency: up to 80 concurrent requests concurrency = 1 concurrency = 80 

Pub/Sub triggered internal services Cloud Run Cloud Pub/Sub Queue Queue Queue 

Storage triggered internal services Cloud Run Cloud Pub/Sub Queue Queue Queue Cloud Storage 

Scheduled services Command Line Interface (CLI) User Interface (UI) Scheduler API Cloud Run Cloud Scheduler 

Services part of async tasks Cloud Tasks user_registration user_levelcompleted user_inapppurchase user_statechange Daily activity metrics service User profile service Payment processing service Game state service 

An app modernization story Monolith to microservices with .NET Core, containers and Cloud Run 

Stage 0: Prototype (Late 2015) Reader Transformer Web API ASP.NET (4.6) Windows app on IIS hosting +Worked, easy to understand and deploy, cheap -Too much coupling, bad DevEx (FTP to see logs!), no redundancy, no persistence, no resilience 

Stage 1: Lift & Shift (2016/2017) Deploy to Compute Engine on Google Cloud +Easy to move, redundancy, load-balancing, possiblity of autoscaling, better DevEx with Stackdriver logging, VM snapshots etc. -Expensive Compute Engine Compute Engine Cloud Load Balancer 

Stage 2: Containarization (Early 2019) Re-write in ASP.NET Core (2.2), containerize w/ Docker & deploy to App Engine Flex (Linux) +Windows license fees out, hassle-free autoscaling, revision management -Still VM based (expensive), slow deploys App Engine 

Stage 3: Serverless (Mid 2019) Update to ASP.NET Core (3.0) & deploy to Cloud Run + Serverless billing (no more VMs), much cheaper, awesome DevEx (fast deploys, integrated logging, etc.) - Cold starts Cloud Run 

Stage 4: Monolith to microservices (Early 2020) Cloud Scheduler Reader (Private) Cloud Pub/Sub Cloud Storage Converter (Private) Web (Public) Cloud Firestore 

Stage 4: Monolith to microservices (Early 2020) Update to ASP.NET Core (3.1) & decompose to 3 microservices, introduce persistence + Loosely coupled architecture, ability to update individual pieces (eg. Converter), ability to use different languages, better utilization, persistence - Many moving parts, more expensive 

Lessons Learned ● Transformation does not have to be all or nothing ● Even simple lift & shift can have huge benefits ● Non-optimal solutions can be a stepping stone to more optimal solutions ● Monolith decomposition is hard! Need a good reason beyond separation of concerns 

@meteatamel github.com/meteatamel/knative-tutorial knative.dev github.com/meteatamel/cloudrun-tutorial cloud.google.com/run github.com/meteatamel/amathus Thank you!