Importance of Natural Resources

Say hello to serverless containers with Cloud Run


STEPHANIE WONG: We, as
developers, love serverless. We love that we can
focus on code, deploying, and let the platform
take care of the rest. But we also keep
asking, what else can we deploy on serverless? What about going beyond
simple functions? Well, you can today
with Cloud Run, which lets you run any stateless
container on serverless. With Cloud Run, you can
forget about infrastructure. It focuses on fast, automatic
scalings that’s request-aware, so you can scale down
to zero and only pay when it’s being used. To demo this, I’m
going to deploy a serverless microservice
that transforms Word documents to PDFs. To perform this
transformation, does anyone remember OpenOffice? I’m going to simply add
OpenOffice inside my container, and then run it in a
serverless environment. Let’s see how easy it is to run
it in a container on Cloud Run. From the console,
go to Cloud Run and open the Deployment page. Select or paste the URL
of the container image and click Create. That’s all we needed to
create a serverless container. No infrastructure to provision
in advance, no YAML file, and no servers. Cloud Run has imported my image,
made sure that it started, and gathered a stable and
secure HTTPS endpoint. What we just deployed is
a scalable microservice that transforms a
document into a PDF. Let’s see it in action. Let’s give it a doc to convert. And we get a PDF back. OpenOffice is not exactly
a modern piece of software. It’s about a 15-year-old binary,
and it’s about 200 megabytes. And we just took that
binary and deployed it as a serverless
workload with Cloud Run, because Cloud Run supports
Docker containers. That means you can run any
programming language you want or any software in
a serverless way. Let’s look at the code. We have a small
piece of Python code that listens for
incoming HTTP requests and calls OpenOffice to
convert our document. And we also have a
very small Docker file. It starts by defining
our base image. In our case, it’s the
official Python-based image. Later, we installed OpenOffice
and we specified our start command. Then, we packaged all
of this into a container image using Cloud Build and
deployed it to Cloud Run. On Cloud Run, our
microservice can automatically be scaled to thousands of
containers or instances in just a few seconds. We just took a legacy
app and deployed it to a microservice environment
without any change in code. But sometimes you might want to
have a little bit more control. For example, bigger CPU
sizes, access to GPUs, more memory, or maybe have it
running on a Kubernetes Engine cluster. With Cloud Run on GKE, it
uses the exact same interface. I’m going to deploy the
exact same container image, this time in GKE. And instead of a
fully-managed region, I’m now picking our GKE cluster. We get the same Cloud
Run developer experience. It’s deploying, and our
microservice is creating. As before, we get a
stable and secure endpoint that automatically
scales our microservice. Behind the scenes, Cloud
Run and Cloud Run on GKE are powered by Knative– an opensource project
to run serverless workloads that we
launched last year. This means we can
actually deploy the exact same microservice to
any Kubernetes cluster running on Knative. Let’s take a look. I exported the microservice
into a file, service.yaml. Then, using the
kubectl command, I’ll deploy it to a managed Knative
on another cloud provider. I’ll enter “kubectl get kservice
to retrieve the URL endpoint.” And voila! We have it now on
another cloud provider. Let’s look into
the service that’s running by entering “gcloud
beta run services describe pdf service.” If you’re familiar
with Kubernetes, these API version and kind
fields may look familiar. In this case, we’re
not using Kubernetes. But since Cloud Run implements
the Knative API, an extension of Kubernetes, this
is an API object that looks like Kubernetes. Knative enables services
to be run portably between environments
without vendor lock-in. Cloud Run gives you everything
you love about serverless. There are no servers to manage,
you get to stay in the code, and there’s fast scale-up,
and more importantly, scale down to zero. You get to pay nothing when
there are no cycles being run. Use any binary or
language, because it’s on the flexibility
of containers. And it gives you access to
the Google Cloud ecosystem and APIs. And you get a
consistent experience wherever you want it– in a fully-managed
environment or on GKE. Thanks for watching. Check out more in the
description below. And subscribe to stay up-to-date
with the latest in serverless on Google Cloud. [MUSIC PLAYING]


Reader Comments

  1. Cloud run is so efficient and effortless to deploy! This was a fantastic example, easy to understand and easy to follow! Thanks Stephanie! 👍

  2. Is traffic splitting coming to Cloud Run? Being able to do canary deployments is something I'm extremely interested in.

    Also, cost capping. It's the main reason I'm still using App Engine as my compute platform.

Leave a Reply

Your email address will not be published. Required fields are marked *