Taking Run for a spin

In the recently concluded Google Cloud Next ’19 event at San Francisco, Google announced a slew of new services and updates to existing services. And of all the new services announced, the one that caught our eye immediately was Google Cloud Run.

Before we dig into the hows, lets just look a little at the what. What is Google Cloud Run?

Cloud Run is a managed compute platform that enables you to run stateless containers that are accessed via HTTP requests. It abstracts away all infrastructure management such as provisioning, configuring, and managing servers. It automatically scales up and down from zero depending on traffic almost instantaneously, so you don’t have to worry about scale configuration ever.

But don’t we already have a few options in serverless? What about Cloud Functions? What about App Engine? And then there’s App Engine Flex. These were the first thoughts that came up when we heard about Run.

Cloud Functions are meant for event based processing and right now are somewhat constrained by the languages that are supported.(Only Node.js and python). App Engine standard brings its own constraints in terms of sand boxed and limited set of environments. App Engine Flex allowed us to bring custom run-times in terms of Dockerfiles coupled with app.yaml files. However App engine flex is more of a PaaS solution and seems to be meant for applications. In this mix comes Run. Google Cloud Run is a serverless environment for you to run your containers.While you deploy your code to app engine, with Run you deploy containers.

With Google Cloud Run you can Run any language, any library, any binary in a fully managed serverless environment. So lets take Run for a spin and see how one works with this.

Working with Cloud Run is fairly simple. Here’s what you need to do:

1. Write code for your service
2. Create a Dockerfile for your service
3. Build the container and push it to Google Container Repository (GCR)
4. Create a service with this container.

We developed a simple Spring boot application, that has only one POST request. This takes user information and stores it in the datastore. A simple application with a pom.xml for building the jar that we will deploy.

We wrote a Dockerfile that looks like this (a standard one for spring-boot):

FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY <path to application jar> app.jar
ENTRYPOINT [“java”,”-Djava.security.egd=file:/dev/./urandom”,”-jar”,”/app.jar”]

After compiling the code and building the application jar, the next step was to build the container and push it to GCR. That was done simply using this command:

gcloud builds submit — tag gcr.io/<project-name>/<application-name>

The next step was to create the service. Although we have CLI for this, we choose to use the console for this. In the google cloud console, navigate to the Run service and click on “Create Service”.

In the above window provide the URL of the container image, the one you used in the gcloud builds command above. Give your service a name. For our trial we allowed unauthenticated invocations. In a future blog we will talk about authorization options. In the optional setting, you can set memory requirements as well. The default is 256 MB, however this is not sufficient for a spring boot application to load, so we set this to 1 GB. Click on save and the service is deployed.

Once the service is deployed, Run generates a URL with which to access the service.

Your service is now available for everyone to use. The service will also scale based on number of requests coming in. You can control scaling by setting the maximum number of concurrent requests that an instance can handle before a new instance is started. All application logs can be viewed from the console.

Using Google Cloud Run sure feels simple. The first spin has left us wanting to dig deeper and see how far we can push Google Cloud Run. We will be back with our findings.