Google Cloud for Serverless Compute

A rundown of Cloud Run, Cloud Run on GKE, and Knative. And a little bit of history of how we got here.

Transcript

1. Google Cloud for Serverless Compute Sandeep Parikh, Cloud Native Advocate
2. Today we’re going to cover the what, why, and how of serverless compute on Google Cloud.
3. About me I’m a Cloud Native Advocate at Google. I focus on helping developers and operators use Kubernetes and Istio. Before Google, I worked at MongoDB, Apple, and a bunch of other places. You can find me on Twitter @crcsmnky Github @crcsmnky Hi!
4. How did we get here?
5. First, some history
6. Wind the clocks back to 2008 In the beginning, there was App Engine. You could write code and deploy your app within minutes.
7. Not As Good Only certain runtimes Support for specific services Sandboxing Lack of VPC connectivity App Engine Good From code to app in minutes Scale to zero Traffic splitting, versions, etc. No instances to manage
8. Over time, the product line grew into App Engine and App Engine Flex. Next came Flex
9. Not As Good Lengthy startup times No support for scale to zero Higher costs (building images, running instances) App Engine Flex Good Containers and custom runtimes Traffic splitting, versions, etc. VPC connectivity Easy access to GCP services
10. Cloud Functions for event-driven serverless compute. Along came Functions
11. Not As Good Few runtimes Basic authn/authz Few event-driven integrations Function-level granularity Cloud Functions Good Great developer experience Autoscaling, no instances Pay only when your code runs Event-driven integrations
12. But wait, there’s more! App Engine added support for 2nd generation runtimes, which combined the flexibility of Flex and stability of Standard.
13. App Engine 2nd Generation Runtimes Standard Standard 2nd generation Flexible Python 2.7 Java 8 PHP 5.5 Go 1.9 and Go 1.11 Python 3.7 PHP 7.2 Node.js Go 1.12 (beta) Ruby (alpha) Node.js, Ruby, Java, Python, Go, PHP, .NET & custom container images Sandboxed processes Runs on managed VMs GAE specific APIs + GCP APIs Use GCP APIs directly No binary modules/libraries any extension, binary, or framework open-source, idiomatic experience
14. App Engine 2nd Generation Runtimes Standard Standard 2nd generation Flexible Python 2.7 Java 8 PHP 5.5 Go 1.9 and Go 1.11 Python 3.7 PHP 7.2 Node.js Go 1.12 (beta) Ruby (alpha) Node.js, Ruby, Java, Python, Go, PHP, .NET & custom container images Sandboxed processes Runs on managed VMs GAE specific APIs + GCP APIs Use GCP APIs directly No binary modules/libraries any extension, binary, or framework open-source, idiomatic experience
15. Where did that leave us?
16. { your containers your code { containers existing systems web applications* web applications Kubernetes Engine Compute Engine App Engine Flex App Engine Cloud Functions event driven * app containers too
17. So what comes next?
18. Operational Model No Infra Management Fully Managed Security Pay only for usage Programming Model Service-based Event-driven Open Stateless Let’s start with the basics of serverless
19. Containers Flexibility Serverless Velocity
20. Introducing Cloud Run The next step in bringing serverless to containers
21. Cloud Run Container to production in seconds Natively Serverless One experience, where you want it
22. Cloud Run Just ‘deploy’ Any stateless container Any language, any library URL in seconds Focus on writing code Scale up fast Scale down to zero Pay for exact usage No servers to manage
23. Autoscaling based on requests Scales up fast Scales down to zero
24. Pay only for what you use 100ms CPU / Memory / Requests
25. Billable time Instance Billable Time Request 1 Start Request 1 End Request 2 Start Request 2 End Instance Time Billable Non-billable
26. Cloud Run use cases Public • Website • API endpoint • Mobile backend • Webhook Private • Microservices • Asynchronous tasks
27. Cloud Run What does this mean? Container to production in seconds Natively Serverless One experience, where you want it
28. Introducing Cloud Run on GKE Same great Cloud Run, but on Kubernetes More flexibility and control, operator required. Integrates with k8s-based policy, control & mgmt Custom nodes, hardware accelerators, VPC Build on your existing investment in Kubernetes
29. Cloud Run Fully serverless, no cluster Pay for what you use Cloud Run on GKE Serverless developer experience Runs in your GKE cluster Serverless containers, where you want them
30. Cloud Run on GKE: Fixed Price Priced as part of Kubernetes Engine Uses the provisioned resources in your cluster Works with GKE Usage Metering Instances $
31. Runs in your GKE cluster Provisioned resources Kubernetes operations Custom machine types Hardware accelerators (GPUs) Fully managed, no cluster Pay-per-use Minimal operations Limited instance size Autoscaling Stackdriver UI & CLI Custom URLs Knative Cloud Run Cloud Run on GKE
32. One experience, where you want it
33. Serverless + Portability
34. Knative open source building blocks for serverless on Kubernetes
35. Activates & scales up/down based on requests Manages code and config revisions Service mesh integration for request path/service access control Custom domains, certificate management Orchestrates on/off cluster resources Bindings for event sources, triggers, and services Scales from few events to full streaming Builds on CloudEvents Reproducible builds Source to serving URL templates No need for Docker or cross-compilation Supports de-coupled CI/CD Support for policy and audit controls What you kneed to know about Knative Serving Eventing Build
36. Cloud Run & Knative Portable via common API and runtime environment. Cloud Run implements Knative Serving and Knative Runtime Contract.
37. Products Google Cloud Run Red Hat OpenShift SAP Kyma Google Cloud Run on GKE IBM Cloud Kubernetes Service TriggerMesh Build Serving Kubernetes Platform Primitives Events ... Knative ecosystem
38. Knative community 20% MoM Participation Growth >50 Companies contributing 3.7K Pull Requests 400+ Contributors 9 Working Groups v0.5 Released late April!
39. You probably want more details about Cloud Run
40. Authorization
41. GCP Invoker permissions Service IAM Requests Auth check: "allUsers" "user:mail@domain.com" "serviceAccount:..."
42. Public service Frontend IAM: role: "roles/run.invoker" member: "allUsers"
43. Leverage "Invoker" IAM role and service identity. Private service to service Frontend Backend IAM: role: "roles/run.invoker" member: "serviceAccount:frontend@..." header:"Authorization: Bearer ID_TOKEN"
44. Push Events with Pub/Sub Pub/Sub push to Cloud Run URL with authentication token. Leverage "Invoker" IAM role to authorize push. No need to validate URL. Cloud Run Service Cloud Pub/Sub IAM: role: "roles/run.invoker" member: "serviceAccount:pubsub@..." gcloud alpha pubsub subscriptions create my-sub --topic my-topic --push-endpoint=https://service.run.app --push-auth-service-account=pubsub@...
45. Async tasks Cloud Tasks HTTP targets (Beta soon) push to Cloud Run URL with authentication token Leverage "Invoker" IAM role. Service Cloud Tasks IAM: role: "roles/run.invoker" member: "serviceAccount:tasks@..." HTTP target
46. Scheduled services Cloud Scheduler with authentication token Leverage "Invoker" IAM role. Service Cloud Scheduler IAM: role: "roles/run.invoker" member: "serviceAccount:scheduler@..."
47. Concurrency
48. Concurrency in Cloud Run Each Service is autoscaled to many container instances. Concurrency = "maximum number of requests that can be sent at the same time to a given container instance" AWS Lambda or Google Cloud Functions: only one request at a time to each instance, "concurrency = 1". With Cloud Run: set concurrency value from 1 to 80 (default: 80) → optimized resource consumption → optimized costs concurrency = 1 concurrency = 80
49. concurrency = 1 concurrency = 80 400 clients, making 3 req/sec
50. Other details
51. Container runtime contract State Listen for HTTP requests on $PORT CPU outside of requests
52. Monitoring & Logging ✓ Monitoring Out of the box: ✓ Error Reporting ✓ Logging Stackdriver
53. gVisor Container sandbox runtime gvisor.dev Secure container isolation. Most applications run well. Contact GCP support if you encounter a limitation due to unsupported system call. Container gVisor Host System calls Limited system calls Secure isolation }
54. Current limits • Max to 1 vCPU and 2GB RAM • No access to GPUs • No Cloud SQL Coming Soon • No VPC access Coming Soon → No Cloud Memorystore • No Global Load Balancer Cloud Run on GKE Solution
55. Demo time (if there’s time)
56. Thank you! You can find Sandeep on Twitter @crcsmnky Github @crcsmnky