Pro Yearly is on sale from $80 to $50! »

Google Cloud for Serverless Compute

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.

A1af6e45dfb6e6cb9a64834484adf788?s=128

Sandeep Parikh

May 15, 2019
Tweet

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