Serverless AND Containers

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

CONTAINERS VS SERVERLESS and

Slide 4

Slide 4 text

Donna Malayeri Product Manager, Google Cloud @lindydonna Ahmet Alp Balkan Developer Advocate, Google Cloud @ahmetb

Slide 5

Slide 5 text

What do we agree on

Slide 6

Slide 6 text

SERVERLESS > FUNCTIONS no ops fast autoscaling pay-per-use built-in security

Slide 7

Slide 7 text

When we say "serverless," we're referring to services that run without the need for infrastructure provisioning and scaling, have built-in availability and security, and use a pay-for-valuebilling model. Serverless isn't just Lambda—it's the entire application stack. -Werner Vogels, CTO Amazon.com

Slide 8

Slide 8 text

There are serverless containers. Google Cloud Run, Knative, AWS Fargate ...

Slide 9

Slide 9 text

Functions vs Containers ⚔

Slide 10

Slide 10 text

ABSTRACTION LAYER Runtime+infrastructure as commodity. Write snippets of code. Give up control over low-level details in favor of simplicity. Infrastructure as commodity. Write complete programs, packaged as "images" ● HTTP server ● Graceful termination, signal handling ● Concurrency control Access to low-level properties: ● OS/kernel options, network protocols ● build/compilation/runtime options FUNCTIONS CONTAINERS

Slide 11

Slide 11 text

DEPENDENCIES & PATCHING Container images are: ● highly customizable ● hermetic and reproducible OS is patched by the platform Runtime patches require rebuild/redeploy. OS/Runtime patches provided by the platform. Can be customizable, if you can maintain a custom runtime. FUNCTIONS CONTAINERS

Slide 12

Slide 12 text

LANGUAGE SUPPORT Supported language/versions are often limited. Maintain your custom runtime to have more languages/frameworks. FUNCTIONS Run any language/framework. (x86 application binary interface) Bring custom dependencies/libs, existing apps. CONTAINERS

Slide 13

Slide 13 text

Method signature Invoked with a "harness" added by the platform. ● Payload: in-memory event object (event payload is already parsed) ● Response: in-memory object INVOCATION CONTRACT Fully executable program Invoked via proxy/load balancer. ● Payload: HTTP request (doesn't need an API Gateway) ● Response: HTTP response FUNCTIONS CONTAINERS

Slide 14

Slide 14 text

But I hate docker and don't want to learn containers

Slide 15

Slide 15 text

Debunking Container image myths 1. You need to learn docker and write Dockerfiles to build container images → CNCF Buildpacks → Language-specific builders: ko (Go), Jib (Java), … 2. Container images contain libraries/binaries you need to patch. → You can build minimal container images → static compilation, distroless

Slide 16

Slide 16 text

VENDOR PORTABILITY Event objects are cloud/vendor specific Move horizontally or down. functions → functions functions → containers (Google functions-framework) Events are standardized via CloudEvents (a CNCF sandbox project). Hybrid-cloud: bare metal ⇔ VMs ⇔ Kubernetes ⇔ serverless FUNCTIONS CONTAINERS

Slide 17

Slide 17 text

LOCAL TEST/DEV/DEBUG Write a test harness to invoke it locally. Learn and use serverless frameworks/SDKs FUNCTIONS CONTAINERS You write complete programs, which you can run locally. Use existing developer tools. (IDEs, profilers, debuggers, …)