Automatic Deployment of Hugo Sites on Firebase Hosting and Drafts on Cloud Run

Posted by James Ward, Developer Advocate

Recently I completed the migration of my blog from WordPress to Hugo and I wanted to take advantage of it now being a static site by hosting it on a Content Delivery Network (CDN). With Hugo the source content is plain files instead of rows in a database. In the case of my blog those files are in git on GitHub. But when the source files change, the site needs to be regenerated and redeployed to the CDN. Also, sometimes it is nice to have drafts available for review. I setup a continuous delivery pipeline which deploys changes to my prod site on Firebase Hosting and drafts on Cloud Run, using Cloud Build. Read on for instructions for how to set all this up.

Step 1a) Setup A New Hugo Project

If you do not have an existing Hugo project you can create a GitHub copy (i.e. fork) of my Hugo starter repo:

Step 1b) Setup Existing Hugo Project

If you have an existing Hugo project you’ll need to add some files to it:

.firebaserc

{
  "projects": {
    "production": "hello-hugo"
  }
}

cloudbuild-draft.yaml

steps:
- name: 'gcr.io/cloud-builders/git'
  entrypoint: '/bin/sh'
  args:
  - '-c'
  - |
    # Get the theme git submodule
    THEME_URL=$(git config -f .gitmodules --get-regexp '^submodule..*.url$' | awk '{ print $2 }')
    THEME_DIR=$(git config -f .gitmodules --get-regexp '^submodule..*.path$' | awk '{ print $2 }')
    rm -rf themes
    git clone $$THEME_URL $$THEME_DIR

- name: 'gcr.io/cloud-builders/docker'
  entrypoint: '/bin/sh'
  args:
  - '-c'
  - |
    docker build -t gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:$COMMIT_SHA -f - . << EOF
    FROM klakegg/hugo:latest
    WORKDIR /workspace
    COPY . /workspace
    ENTRYPOINT hugo -D -p $$PORT --bind $$HUGO_BIND --renderToDisk --disableLiveReload --watch=false serve
    EOF
    docker push gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:$COMMIT_SHA

- name: 'gcr.io/cloud-builders/gcloud'
  args:
  - run
  - deploy
  - --image=gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:$COMMIT_SHA
  - --platform=managed
  - --project=$PROJECT_ID
  - --region=us-central1
  - --memory=512Mi
  - --allow-unauthenticated
  - $REPO_NAME-$BRANCH_NAME

cloudbuild.yaml

steps:
- name: 'gcr.io/cloud-builders/git'
  entrypoint: '/bin/sh'
  args:
  - '-c'
  - |
    # Get the theme git submodule
    THEME_URL=$(git config -f .gitmodules --get-regexp '^submodule..*.url$' | awk '{ print $2 }')
    THEME_DIR=$(git config -f .gitmodules --get-regexp '^submodule..*.path$' | awk '{ print $2 }')
    rm -rf themes
    git clone $$THEME_URL $$THEME_DIR

- name: 'gcr.io/cloud-builders/curl'
  entrypoint: '/bin/sh'
  args:
  - '-c'
  - |
    curl -sL https://github.com/gohugoio/hugo/releases/download/v0.69.2/hugo_0.69.2_Linux-64bit.tar.gz | tar -zxv
    ./hugo

- name: 'gcr.io/cloud-builders/wget'
  entrypoint: '/bin/sh'
  args:
  - '-c'
  - |
    # Get firebase CLI
    wget -O firebase https://firebase.tools/bin/linux/latest
    chmod +x firebase
    # Deploy site
    ./firebase deploy --project=$PROJECT_ID --only=hosting

firebase.json

{
  "hosting": {
    "public": "public"
  }
}

Step 2) Setup Cloud Build Triggers

In the Google Cloud Build console, connect to your newly forked repo: Select the newly forked repo: Create the default push trigger: Edit the new trigger: Set the trigger to only fire on changes to the ^master$ branch: Create a new trigger: Give it a name like drafts-trigger, specify the branch selector as .* (i.e. any branch), and the build configuration file type to “Cloud Build configuration file” with a value of cloudbuild-draft.yaml Setup permissions for the Cloud Build process to manage Cloud Run and Firebase Hosting by visiting the IAM management page, locate the member with the name ending with @cloudbuild.gserviceaccount.com, and select the “pencil” / edit button: Add a role for “Cloud Run Admin” and another for “Firebase Hosting Admin”: Your default “prod” trigger isn’t read to test yet, but you can test the drafts on Cloud Run by going back to the Cloud Build Triggers page, and clicking the “Run Trigger” button on the “drafts-trigger” line. Check the build logs by finding the build in the Cloud Build History. Once the build completes visit the Cloud Run console to find your newly created service which hosts the drafts version of your new blog. Note that the service name includes the branch so that you can see drafts from different branches.

Step 3) Setup Firebase Hosting

To setup your production / CDN’d site, login to the firebase console and select your project:

Now you’ll need your project id, which can be found in the URL on the Firebase Project Overview page. The URL for my project is:

console.firebase.google.com/project/jw-demo/overview

Which means my project id is: jw-demo

Now copy your project id go into your GitHub fork, select the .firebaserc file and click the “pencil” / edit button:

Replace the hello-hugo string with your project id and commit the changes. This commit will trigger two new builds, one for the production site and one for the drafts site on Cloud Run. You can check the status of those builds on the Cloud Build History page. Once the default trigger (the one for Firebase hosting) finishes, check out your Hugo site running on Firebase Hosting by navigating to (replacing YOUR_PROJECT_ID with the project id you used above): https://YOUR_PROJECT_ID.web.app/

Your prod and drafts sites are now automatically deploying on new commits!

Step 4) (Optional) Change Hugo Theme

There are many themes for Hugo and they are easy to change. Typically themes are pulled into Hugo sites using git submodules. To change the theme, edit your .gitmodules file and set the subdirectories and url. As an example, here is the content when using the mainroad theme:

[submodule "themes/mainroad"]
 path = themes/mainroad
 url = https://github.com/vimux/mainroad.git

You will also need to change the theme value in your config.toml file to match the directory name in the themes directory. For example:

theme = "mainroad"

Note: At the time of writing this, Cloud Build does not clone git submodules so the cloudbuild.yaml does the cloning instead.

Step 5) (Optional) Setup Local Editing

To setup local editing you will first need to clone your fork. You can do this with the GitHub desktop app. Or from the command line:

git clone --recurse-submodules https://github.com/USER/REPO.git

Once you have the files locally, install Hugo, and from inside the repo’s directory, run:

hugo -D serve

This will serve the drafts in the site. You can check out the site at: localhost:1313

Committing non-draft changes to master and pushing those changes to GitHub will kick off the build which will deploy them on your prod site. Committing draft to any branch will kick off the build which will deploy them on a Cloud Run site.

Hopefully that all helps you with hosting your Hugo sites! Let me know if you run into any problems.

4 Aug, 2020
(0) Comments
By editor
GCP, Google, Google Cloud, serverless, Static Sites

13 Most Common Google Cloud Reference Architectures

Posted by Priyanka Vergadia, Developer Advocate

Google Cloud is a cloud computing platform that can be used to build and deploy applications. It allows you to take advantage of the flexibility of development while scaling the infrastructure as needed.

I’m often asked by developers to provide a list of Google Cloud architectures that help to get started on the cloud journey. Last month, I decided to start a mini-series on Twitter called “#13DaysOfGCP” where I shared the most common use cases on Google Cloud. I have compiled the list of all 13 architectures in this post. Some of the topics covered are hybrid cloud, mobile app backends, microservices, serverless, CICD and more. If you were not able to catch it, or if you missed a few days, here we bring to you the summary!

Series kickoff #13DaysOfGCP

#1: How to set up hybrid architecture in Google Cloud and on-premises

Day 1

#2: How to mask sensitive data in chatbots using Data loss prevention (DLP) API?

Day 2

#8: How to set up Continuous Integration and Continuous Delivery (CICD) pipeline on Google Cloud?

Day 8

#9: How to build serverless microservices in Google Cloud?

Day 9

#10: Machine Learning on Google Cloud

Day 10

#11: Serverless image, video or text processing in Google Cloud

Day 11

#12: Internet of Things (IoT) on Google Cloud

Day 12

#13: How to set up BeyondCorp zero trust security model?

Day 13

Wrap up with a puzzle

Wrap up!

We hope you enjoy this list of the most common reference architectures. Please let us know your thoughts in the comments below!

23 Jun, 2020
(0) Comments
By editor
AI, Artificial Intelligence, cloud-computing, Data Science, GCP, Google, machine learning, microservices, ml, serverless

Sip a cup of Java 11 for your Cloud Functions

Posted by Guillaume Laforge, Developer Advocate for Google Cloud

With the beta of the new Java 11 runtime for Google Cloud Functions, Java developers can now write their functions using the Java programming language (a language often used in enterprises) in addition to Node.js, Go, or Python. Cloud Functions allow you to run bits of code locally or in the cloud, without provisioning or managing servers: Deploy your code, and let the platform handle scaling up and down for you. Just focus on your code: handle incoming HTTP requests or respond to some cloud events, like messages coming from Cloud Pub/Sub or new files uploaded in Cloud Storage buckets.

In this article, let’s focus on what functions look like, how you can write portable functions, how to run and debug them locally or deploy them in the cloud or on-premises, thanks to the Functions Framework, an open source library that runs your functions. But you will also learn about third-party frameworks that you might be familiar with, that also let you create functions using common programming paradigms.

The shape of your functions

There are two types of functions: HTTP functions, and background functions. HTTP functions respond to incoming HTTP requests, whereas background functions react to cloud-related events.

The Java Functions Framework provides an API that you can use to author your functions, as well as an invoker which can be called to run your functions locally on your machine, or anywhere with a Java 11 environment.

To get started with this API, you will need to add a dependency in your build files. If you use Maven, add the following dependency tag in pom.xml:

<dependency>
    <groupId>com.google.cloud.functions</groupId>
    <artifactId>functions-framework-api</artifactId>
    <version>1.0.1</version>
    <scope>provided</scope>
</dependency>

If you are using Gradle, add this dependency declaration in build.gradle:

compileOnly("com.google.cloud.functions:functions-framework-api")

Responding to HTTP requests

A Java function that receives an incoming HTTP request implements the HttpFunction interface:

import com.google.cloud.functions.*;
import java.io.*;

public class Example implements HttpFunction {
    @Override
    public void service(HttpRequest request, HttpResponse response)
            throws IOException {
        var writer = response.getWriter();
        writer.write("Hello developers!");
    }
}

The service() method provides an HttpRequest and an HttpResponse object. From the request, you can get information about the HTTP headers, the payload body, or the request parameters. It’s also possible to handle multipart requests. With the response, you can set a status code or headers, define a body payload and a content-type.

Responding to cloud events

Background functions respond to events coming from the cloud, like new Pub/Sub messages, Cloud Storage file updates, or new or updated data in Cloud Firestore. There are actually two ways to implement such functions, either by dealing with the JSON payloads representing those events, or by taking advantage of object marshalling thanks to the Gson library, which takes care of the parsing transparently for the developer.

With a RawBackgroundFunction, the responsibility is on you to handle the incoming cloud event JSON-encoded payload. You receive a JSON string, so you are free to parse it however you like, with your JSON parser of your choice:

import com.google.cloud.functions.Context;
import com.google.cloud.functions.RawBackgroundFunction;

public class RawFunction implements RawBackgroundFunction {
    @Override
    public void accept(String json, Context context) {
        ...
    }
}

But you also have the option to write a BackgroundFunction which uses Gson for unmarshalling a JSON representation into a Java class (a POJO, Plain-Old-Java-Object) representing that payload. To that end, you have to provide the POJO as a generic argument:

import com.google.cloud.functions.Context;
import com.google.cloud.functions.BackgroundFunction;

public class PubSubFunction implements BackgroundFunction<PubSubMsg> {
    @Override
    public void accept(PubSubMsg msg, Context context) {
        System.out.println("Received message ID: " + msg.messageId);
    }
}

public class PubSubMsg {
    String data;
    Map<String, String> attributes;
    String messageId;
    String publishTime;
}

The Context parameter contains various metadata fields like timestamps, the type of events, and other attributes.

Which type of background function should you use? It depends on the control you need to have on the incoming payload, or if the Gson unmarshalling doesn’t fully fit your needs. But having the unmarshalling covered by the framework definitely streamlines the writing of your function.

Running your function locally

Coding is always great, but seeing your code actually running is even more rewarding. The Functions Framework comes with the API we used above, but also with an invoker tool that you can use to run functions locally. For improving developer productivity, having a direct and local feedback loop on your own computer makes it much more comfortable than deploying in the cloud for each change you make to your code.

With Maven

If you’re building your functions with Maven, you can install the Function Maven plugin in your pom.xml:

<plugin>
    <groupId>com.google.cloud.functions</groupId>
    <artifactId>function-maven-plugin</artifactId>
    <version>0.9.2</version>
    <configuration>
        <functionTarget>com.example.Example</functionTarget>
    </configuration>
</plugin>

On the command-line, you can then run:

$ mvn function:run

You can pass extra parameters like --target to define a different function to run (in case your project contains several functions), --port to specify the port to listen to, or --classpath to explicitly set the classpath needed by the function to run. These are the parameters of the underlying Invoker class. However, to set these parameters via the Maven plugin, you’ll have to pass properties with -Drun.functionTarget=com.example.Example and -Drun.port.

With Gradle

With Gradle, there is no dedicated plugin, but it’s easy to configure build.gradle to let you run functions.

First, define a dedicated configuration for the invoker:

configurations { 
    invoker
}

In the dependencies, add the Invoker library:

dependencies {
    invoker 'com.google.cloud.functions.invoker:java-function-invoker:1.0.0-beta1'
}

And then, create a new task to run the Invoker:

tasks.register("runFunction", JavaExec) {
    main = 'com.google.cloud.functions.invoker.runner.Invoker'
    classpath(configurations.invoker)
    inputs.files(configurations.runtimeClasspath, 
                 sourceSets.main.output)
    args('--target', 
         project.findProperty('runFunction.target') ?:        
         'com.example.Example',
         '--port', 
         project.findProperty('runFunction.port') ?: 8080
    )
    doFirst {
        args('--classpath', files(configurations.runtimeClasspath, 
                                  sourceSets.main.output).asPath)
    }
}

By default, the above launches the function com.example.Example on port 8080, but you can override those on the command-line, when running gradle or the gradle wrapper:

$ gradle runFunction -PrunFunction.target=com.example.HelloWorld 
                     -PrunFunction.port=8080

Running elsewhere, making your functions portable

What’s interesting about the Functions Framework is that you are not tied to the Cloud Functions platform for deploying your functions. As long as, in your target environment, you can run your functions with the Invoker class, you can run your functions on Cloud Run, on Google Kubernetes Engine, on Knative environments, on other clouds when you can run Java, or more generally on any servers on-premises. It makes your functions highly portable between environments. But let’s have a closer look at deployment now.

Deploying your functions

You can deploy functions with the Maven plugin as well, with various parameters to tweak for defining regions, memory size, etc. But here, we’ll focus on using the cloud SDK, with its gcloud command-line, to deploy our functions.

For example, to deploy an HTTP function, you would type:

$ gcloud functions deploy exampleFn 
    --region europe-west1 
    --trigger-http 
    --allow-unauthenticated 
    --runtime java11 
    --entry-point com.example.Example 
    --memory 512MB

For a background function that would be notified of new messages on a Pub/Sub topic, you would launch:

$ gcloud functions deploy exampleFn 
    --region europe-west1 
    --trigger-topic msg-topic 
    --runtime java11 
    --entry-point com.example.PubSubFunction 
    --memory 512MB

Note that deployments come in two flavors as well, although the above commands are the same: functions are deployed from source with a pom.xml and built in Google Cloud, but when using a build tool other than Maven, you can also use the same command to deploy a pre-compiled JAR that contains your function implementation. Of course, you’ll have to create that JAR first.

What about other languages and frameworks?

So far, we looked at Java and the plain Functions Framework, but you can definitely use alternative JVM languages such as Apache Groovy, Kotlin, or Scala, and third-party frameworks that integrate with Cloud Functions like Micronaut and Spring Boot!

Pretty Groovy functions

Without covering all those combinations, let’s have a look at two examples. What would an HTTP function look like in Groovy?

The first step will be to add Apache Groovy as a dependency in your pom.xml:

<dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy-all</artifactId>
    <version>3.0.4</version>
    <type>pom</type>
</dependency>

You will also need the GMaven compiler plugin to compile the Groovy code:

<plugin>
    <groupId>org.codehaus.gmavenplus</groupId>
    <artifactId>gmavenplus-plugin</artifactId>
    <version>1.9.0</version>
    <executions>
        <execution>
            <goals>
                <goal>addSources</goal>
                <goal>addTestSources</goal>
                <goal>compile</goal>
                <goal>compileTests</goal>
            </goals>
        </execution>
    </executions>
</plugin>

When writing the function code, just use Groovy instead of Java:

import com.google.cloud.functions.*

class HelloWorldFunction implements HttpFunction {
    void service(HttpRequest request, HttpResponse response) {
        response.writer.write "Hello Groovy World!"
    }
}

The same explanations regarding running your function locally or deploying it still applies: the Java platform is pretty open to alternative languages too! And the Cloud Functions builder will happily build your Groovy code in the cloud, since Maven lets you compile this code thanks to the Groovy library.

Micronaut functions

Third-party frameworks also offer a dedicated Cloud Functions integration. Let’s have a look at Micronaut.

Micronaut is a “modern, JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications”, as explained on its website. It supports the notion of serverless functions, web apps and microservices, and has a dedicated integration for Google Cloud Functions.

In addition to being a very efficient framework with super fast startup times (which is important, to avoid long cold starts on serverless services), what’s interesting about using Micronaut is that you can use Micronaut’s own programming model, including Dependency Injection, annotation-driven bean declaration, etc.

For HTTP functions, you can use the framework’s own @Controller / @Get annotations, instead of the Functions Framework’s own interfaces. So for example, a Micronaut HTTP function would look like:

import io.micronaut.http.annotation.*;

@Controller("/hello")
public class HelloController {

    @Get(uri="/", produces="text/plain")
    public String index() {
        return "Example Response";
    }
}

This is the standard way in Micronaut to define a Web microservice, but it transparently builds upon the Functions Framework to run this service as a Cloud Function. Furthermore, this programming model offered by Micronaut is portable across other environments, since Micronaut runs in many different contexts.

Last but not least, if you are using the Micronaut Launch project (hosted on Cloud Run) which allows you to scaffold new projects easily (from the command-line or from a nice UI), you can opt for adding the google-cloud-function support module, and even choose your favorite language, build tool, or testing framework:

Be sure to check out the documentation for the Micronaut Cloud Functions support, and Spring Cloud Function support.

What’s next?

Now it’s your turn to try Cloud Functions for Java 11 today, with your favorite JVM language or third-party frameworks. Read the getting started guide, and try this for free with Google Cloud Platform free trial. Explore Cloud Functions’ features and use cases, take a look at the quickstarts, perhaps even contribute to the open source Functions Framework. And we’re looking forward to seeing what functions you’re going to build on this platform!

26 May, 2020
(0) Comments
By editor
cloud, cloud-functions, GCP, Google, Groovy, java, Kotlin, Micronaut, Scala, serverless, Spring

Connect to your VPC and managed Redis from App Engine and Cloud Functions

Do you wish you could access resources in your Virtual Private Cloud (VPC) with serverless applications running on App Engine or Cloud Functions? Now you can, with the new Serverless VPC Access service.

Available now, Serverless VPC access lets you access virtual machines, Cloud Memorystore Redis instances, and other VPC resources from both Cloud Functions and App Engine (standard environments), with support for Cloud Run coming soon.

How it works

App Engine and Cloud Functions services exist on a different logical network from Compute Engine, where VPCs run. Under the covers, Serverless VPC Access connectors bridge these networks. These resources are fully managed by Google Cloud, requiring no management on your part. The connectors also provide complete customer and project-level isolation for consistent bandwidth and security.

Serverless VPC Access connectors allow you to choose a minimum and maximum bandwidth for the connection, ranging from 200–1,000 Mbps. The capacity of the connector is scaled to meet the needs of your service, up to the maximum configured (please note that you can obtain higher maximum throughput if you need by reaching out to your account representative).

While Serverless VPC Access allows connections to resources in a VPC, it does not place your App Engine service or Cloud Functions inside the VPC. You should still shield App Engine services from public internet access via firewall rules, and secure Cloud Functions via IAM. Also note that a Serverless VPC Access connector can only operate with a single VPC network; support for Shared VPCs is coming in 2020.

You can however share a single connector between multiple apps and functions, provided that they are in the same region, and that the Serverless VPC Access connectors were created in the same region as the app or function that uses them.

Using Serverless VPC Access

You can provision and use a Serverless VPC Access connector alongside an existing VPC network by using the Cloud SDK command line. Here’s how to enable it with an existing VPC network:

Then, for App Engine, modify the App.yaml and redeploy your application:

To use Serverless VPC Access with Cloud Functions functions, first set the appropriate permissions then redeploy the function with the vpc- connector flag:

Once you’ve created and configured a VPC connector for an app or function, you can access VMs and Redis instances via their private network IP address (e.g. 10.0.0.123).

Get started

Serverless VPC Access is currently available in Iowa, South Carolina, Belgium, London, and Tokyo, with more regions in the works. To learn more about using Serverless VPC Access connectors, check out the documentation and the usage guides for Cloud Functions and App Engine.

8 production-ready features you’ll find in Cloud Run fully managed

Since we launched Cloud Run at Google Cloud Next in April, developers have discovered that “serverless” and “containers” run well together. With Cloud Run, not only do you benefit from fully managed infrastructure, up and down auto-scaling, and pay-as-you-go pricing, but you’re also able to package your workload however you like, inside a stateless container listening for incoming requests, with any language, runtime, or library of your choice. And you get all this without compromising portability, thanks to its Knative open-source underpinnings.

Many Google Cloud customers already use Cloud Run in production, for example, to deploy public websites or APIs, or as a way to perform fast and lightweight data transformations or background operations.

“Cloud Run promises to dramatically reduce the operational complexity of deploying containerized software. The ability to put an automatically scaling service in production with one command is very attractive.” – Jamie Talbot, Principal Engineer at Mailchimp.

Cloud Run recently became generally available, as both a fully managed platform or on Anthos, and offers a bunch of new features. What are those new capabilities? Today, let’s take a look at what’s new in the fully managed Cloud Run platform.

1. Service level agreement
With general availability, Cloud Run now comes with a Service Level Agreement (SLA). In addition, it now offers data location commitments that allow you to store customer data in a specific region/multi-region.

2. Available in 9 GCP regions
In addition to South Carolina, Iowa, Tokyo, and Belgium, in the coming weeks, you’ll also be able to deploy containers to Cloud Run in North Virginia, Oregon, Netherlands, Finland, and Taiwan, for a total of nine cloud regions.

3. Max instances
Auto-scaling can be magic, but there are times when you want to limit the maximum number of instances of your Cloud Run services, for example, to limit costs. Or imagine a backend service like a database is limited to a certain number of connections—you might want to limit the number of instances that can connect to that service. With the max instance feature, you can now set such a limit.

Use the Cloud Console or Cloud SDK to set this limit:

gcloud run services update SERVICE-NAME --max-instances 42

4. More secure: HTTPS only
All fully managed Cloud Run services receive a stable and secure URL. Cloud Run now only accepts secure HTTPS connection and redirects any HTTP connection to the HTTPS endpoint.

But having an HTTPS endpoint does not mean that your service is publicly accessible—you are in control and can opt into allowing public access to your service. Alternatively, you can require authentication by leveraging the “Cloud Run Invoker” IAM role.

5. Unary gRPC protocol support
Cloud Run now lets you deploy and run unary gRPC services (i.e., non-streaming gRPC), allowing your microservices to leverage this RPC framework.

To learn more, read Peter Malinas’ tutorial on Serverless gRPC with Cloud Run using Go, as well as Ahmet Alp Balkan’s article on gRPC authentication on Cloud Run.

6. New metrics to track your instances
Out of the box, Cloud Run integrates with Stackdriver Monitoring. From within the Google Cloud Console, the Cloud Run page now includes a new “Metrics” tab that shows charts of key performance indicators for your Cloud Run service: requests per second, request latency, used instance time, CPU and memory.

A new built-in Stackdriver metric called container/billable_instance_time gives you insights into the number of container instances for a service, with the billable time aggregated from all container instances.

7. Labels
Like the bibs that identify the runners in a race, GCP labels can help you easily identify a set of services, break down costs, or distinguish different environments.

You can set labels from the Cloud Run service list page in Cloud Console, or update labels with this command and flag:

gcloud run services update SERVICE-NAME --update-labels KEY=VALUE

8. Terraform support
Finally, if you practice Infrastructure as Code, you’ll be glad to know that Terraform now supports Cloud Run, allowing you to provision Cloud Run services from a Terraform configuration.

Ready, set, go!
The baton is now in your hands. To start deploying your container images to Cloud Run, head over to our quickstart guides on building and deploying your images. With the always free tier and the $300 credit for new GCP accounts, you’re ready to take Cloud Run for a spin. To learn more, there’s the documentation of course, as well as the numerous samples with different language runtimes (don’t miss the “Run on Google Cloud” button to automatically deploy your code). In addition, be sure to check out the community-contributed resources on the Awesome Cloud Run github project. We’re looking forward to seeing what you build and deploy!

Expanding the serverless ecosystem for Cloud Run

Increasingly, organizations want to write applications in containers, without having to worry about provisioning, managing and scaling the underlying infrastructure. They also want to pay only for what they use. Cloud Run, which recently became generally available, makes this possible, with additional facilities like built-in logging and monitoring through Stackdriver.

Organizations also want to leverage their existing tools and workflows with Cloud Run’s native serverless capabilities, or add tools or third-party services that enhance the developer experience. This means being compatible with CI/CD tooling, third-party observability tools for monitoring the serverless stack, and integrating open source DevOps and security tools.

Building on strong partnerships with leading ISVs, we are proud to have a variety of partners that support Cloud Run, focusing on three key use cases:

CI/CD – Our partner ecosystem ensures that an application that is deployed on Cloud Run is supported natively in the build, test, deploy, and run stages.
Observability – Integrations with APM/logging or monitoring solutions ensure that they can collect telemetry and provide insights into any application that is deployed on Cloud Run.
Security – Our integrations ensure the security and policy enforcement of the applications deployed on Cloud Run.

Below are some of the solutions our partners have built in these areas:

CI/CD

CircleCI – A new Cloud Run orb by CircleCI helps execute a CI/CD pipeline that tests application code and automatically builds a Docker image, subsequently deploying the image as a Cloud Run service on GCP. More here.
Cloudbees – Cloudbees Core can be used to deploy a serverless preview environment with GitHub and Cloud Run, allowing developers to test their changes before a PR merge and deploying to production. More here.
GitLab – GitLab provides templates allowing developers to easily build and deploy Knative services that can be deployed to Cloud Run. More here.
JFrog – Developers can build serverless functions as Docker containers using JFrog Pipelines, which pushes them into JFrog Container Registry and deploys them to Cloud Run for Anthos. More here.

Observability

Datadog – Datadog’s Cloud Run integration allows you to collect metrics, logs and traces from across your cluster and view these in real-time as your application scales up and down. More here.
Dynatrace – Dynatrace’s automated monitoring supports Cloud Run fully managed and Anthos and provides full visibility of your applications—including issues that affect performance—enabling management of operations and costs across the environment. More here.
New Relic – The New Relic Kubernetes solution for Google Cloud on Anthos gives you infrastructure and application-centric views into your Kubernetes clusters. More here.

Security

Octarine – Octarine takes a service mesh approach to runtime visibility and security for Kubernetes, either by leveraging Istio or by deploying a standalone, lightweight Envoy-based service mesh. More here.
Palo Alto Networks – Using capabilities from Palo Alto subsidiary Twistlock,
Palo Alto’s Prisma Cloud provides security for both Cloud Run fully managed as well as Cloud Run for Anthos. More here.
Sumo Logic– Sumo Logic integrates metrics and logs for Kubernetes clusters via FluentD, FluentBit, Prometheus, Falco, and Stackdriver for GKE control plane logs. More here.
Sysdig – Sysdig’s open platform provides a DevSecOps workflow for Cloud Run that embeds security, maximizes availability and validates compliance across the serverless lifecycle. More here.

If your teams use any of these tools, they should find it easy to adopt their workflow with Cloud Run. Over time, we hope to build broader and deeper partnerships for both Cloud Run fully managed and Cloud Run for Anthos.

We would like to thank Anil Dhawan, Product Manager, for his sustained guidance in serverless product integrations.

You can cook turkey in a toaster oven, but you don’t have to

When I was in college and couldn’t make it home for the Thanksgiving holiday, I would get together with other students in the same situation and do the next best thing: cook a traditional Thanksgiving feast of roast turkey, mashed potatoes and gravy, stuffing, and green beans by ourselves. In a dorm room. Using the kitchen equipment we had available: a toaster oven and a popcorn popper.

The resulting dinner wasn’t terrible, but it didn’t hold a candle to the meal my family was enjoying back home, made with the benefit of an oven, high-BTU range, food processor, standing mixer—you get the idea.

Software development teams are sometimes in a similar situation. They need to build something new and have a few tools, so they build their application using what they have. Like our dorm-room Thanksgiving dinner, this can work, but it is probably not a good experience and may not get the best result.

Today, with cloud computing, software development teams have a lot more resources available to them. But sometimes teams move to the cloud but keep using the same old tools, just on a larger scale. That’s like moving from a toaster oven to a wall of large ovens, but not looking into how things like convection or microwave ovens, broilers, sous-vide cooking, instant pots, griddles, breadmakers, or woks can help you make a meal.

In short, if you’re an application developer and you’ve moved to the cloud, you should really explore all the new kinds of tools you can use to run your code, beyond configuring and managing virtual machines.

Like the number of side dishes on my parents’ holiday table, the number of Google Cloud Platform products you might use can be overwhelming. Here are a few you might want to look at first:

App Engine Standard Environment is a serverless platform for web applications. You bring your own application code and let the platform handle the web server itself, along with scaling and monitoring. It can even scale to zero, so if there are idle periods without traffic, you won’t be paying for computer time you aren’t using.
Some of the code you need might not be an application, but just a handler to deal with events as they happen, such as new data arriving or some operation being ready to start. Cloud Functions is another serverless platform that runs code written in supported languages in response to many kinds of events. Cloud Run can do similar tasks for you, with fewer restrictions on what languages and binaries you can run, but requiring a bit more management on your part.
Do you need regular housekeeping tasks performed, such as generating daily reports or deleting stale data? Instead of running a virtual machine just so you can trigger a cron job, you can have Cloud Scheduler do the triggering for you. If you want to get really fancy (like your aunt’s bourbon pecan pie), you can implement it with another serverless offering such as Cloud Functions, at specified intervals.
Instead of installing and managing a relational database server, use Cloud SQL instead. It’s reliable and secure, and handles backups and replication for you.
Maybe you don’t need (or just don’t want to use) a relational database. Cloud Firestore is a serverless NoSQL database that’s easy to use and that will scale up or down as needed. It also replicates your data across multiple regions for extremely high availability.
After Thanksgiving dinner, you may feel like a blob. Or you may just need to store blobs of data, such as files. But you don’t want to use a local filesystem, you want replicated and backed up storage. Some teams put these blobs into general purpose databases, but that’s not a good fit and can be expensive. Cloud Storage is designed to store and retrieve blob-format data on demand, affordably and reliably.

These products are great starting points in rethinking what kind of infrastructure your application could be built on, once you have adopted cloud computing. You might find they give you a better development experience and great outcomes relative to launching and managing more virtual machines. Now if you’ll excuse me, dinner’s ready!

Google Kubernetes Engine or Cloud Run: which should you use?

When it comes to managed Kubernetes services, Google Kubernetes Engine (GKE) is a great choice if you are looking for a hybrid container orchestration platform that offers advanced scalability and configuration flexibility. GKE gives you complete control over every aspect of container orchestration, from networking, to storage, to how you set up observability—in addition to supporting hybrid application use cases. However, if your application does not need that level of cluster configuration and monitoring, then fully managed Cloud Run might be the right solution for you.

Fully managed Cloud Run is an ideal serverless platform for containerized microservices that don’t require advanced Kubernetes features like namespaces, co-location of containers in pods (sidecars) or node allocation and management.

Why Cloud Run?

The managed serverless compute platform Cloud Run provides a number of features and benefits:

Easy deployment of microservices. A containerized microservice can be deployed with a single command without requiring any additional service-specific configuration.
Simple and unified developer experience. Each microservice is implemented as a Docker image, Cloud Run’s unit of deployment.
Scalable serverless execution. A microservice deployed into managed Cloud Run scales automatically based on the number of incoming requests, without having to configure or manage a full-fledged Kubernetes cluster. Managed Cloud Run scales to zero if there are no requests, i.e., uses no resources.
Support for code written in any language. Cloud Run is based on containers, so you can write code in any language, using any binary and framework.

Cloud Run is available in two configurations: as a fully managed Google Cloud service, and as Cloud Run for Anthos (this option deploys Cloud Run into Anthos GKE cluster). If you’re already using Anthos, Cloud Run for Anthos can deploy containers into your cluster, allowing access to custom machine types, additional networking support, and GPUs to enhance your Cloud Run services. Both managed Cloud Run services and GKE clusters can be created and managed completely from the console as well as from the command line.

The best part is you can easily change your mind later, switching from managed Cloud Run to Cloud Run for Anthos or vice versa without having to reimplement your service.

A Cloud Run use case

To illustrate these points, let’s take a look at an example use case, a service that adds, updates, deletes and lists addresses.

You can implement this address management service by creating one containerized microservice for each operation. Then, once the images have been created and registered in a container registry, you can deploy them to managed Cloud Run with a single command. After executing four commands (one deployment for each microservice), the service is up and running on a completely serverless platform. The following figure shows the deployment using Cloud Spanner as the underlying database.

For use cases such as this one, managed Cloud Run is a great choice as the address management service does not require complex configurations as supported by Kubernetes. Nor does this address management service need 24/7 cluster management and operational supervision. Running this address management service as containers in managed Cloud Run is the better production workload strategy.

As a managed compute platform, managed Cloud Run supports essential configuration settings: the maximum concurrent requests a single container receives, the memory size to be allocated to the container as well as request timeout can be configured. No additional configurations or management operations are required.

The right tool for the job

Both managed Cloud Run and GKE are powerful offerings for different use cases. Make sure to understand your functional and non-functional service requirements like ability to scale to zero or ability to control detailed configuration before choosing one over the other.

In fact, you might want to use both at the same time. An enterprise might have complex microservice-based applications that require advanced configuration features of GKE, and some that do not, but that still want to take advantage of Cloud Run’s ease of use and scalability.

To learn more about Cloud Run, visit our website and follow the quickstart.

Cloud Run, a managed Knative service, is GA

We want to empower developers no matter where their businesses are in their cloud journey, whether that’s on-prem, operating in a managed Kubernetes environment, or running on a fully managed serverless computing platform. Today, we’re announcing that Cloud Run is generally available, helping developers focus on writing high-value code, regardless of where their organizations are on the path to the cloud. Specifically, we’re announcing:

Cloud Run, a fully managed serverless execution environment that lets you run stateless HTTP-driven containers, without worrying about the infrastructure.
Cloud Run for Anthos, which lets you deploy Cloud Run applications into an Anthos GKE cluster running on-prem or in Google Cloud.
Our commitment to Knative, the open API and runtime environment on which Cloud Run is based, bringing workload portability and the serverless developer experience to your Kubernetes clusters, wherever they may be.

Cloud Run fully managed

Cloud Run brings the best of both serverless and containers together. It allows you to write code in any language you choose, using any binary, without having to worry about managing the underlying infrastructure. Cloud Run offers a natively serverless experience that lets you go from container to URL within seconds, for terrific developer velocity. You’re also charged only for the resources used, billed to the nearest 100 milliseconds. And Cloud Run workloads are totally portable: you can run them fully managed on Google Cloud, on Anthos running on-premises, or Anthos running on Google Cloud, or on a third-party cloud platform that supports Knative.

Customers such as Narvar, a post-purchase platform for retailers, are already leveraging the benefits of fully managed Cloud Run.

“Google Cloud Run accelerated our developer velocity by 3X by enabling our developers to create new services at scale with ZERO dev-ops involvement. Just as important, Cloud Run helped us create a net-new product and business model, previously not possible because of the constraints of other solutions.” – Ram Ravichandran, CTO Narvar

As a managed compute platform, Cloud Run is production-ready out of the box with monitoring and logging powered by Stackdriver, all integrated into Cloud Console. Cloud Run also has first-class integration with gcloud, GCP’s CLI experience, giving you a consistent interface for deploying and managing Cloud Run services across these platforms.

Cloud Run for Anthos

If your organization wants to leverage Kubernetes to modernize and optimize its existing resources, the combination of Anthos and Cloud Run for Anthos can help smooth that transition, so you can modernize in place. With Cloud Run for Anthos, developers can easily write serverless applications and deploy them to the Anthos cluster without having to learn Kubernetes concepts first. Cloud Run for Anthos takes care of scaling your application instances up or down, even down to zero depending on traffic.

Cloud Run for Anthos also lets you future-proof your applications. If you want to modernize an on-prem legacy application in place or extend it to the cloud, Cloud Run for Anthos can simply spin up a microservice that talks privately to existing services—all running on the same Anthos cluster. And if you decide you want to move your Cloud Run for Anthos apps to the cloud, it’s just a simple redeploy to the fully managed Cloud Run. You can even choose to move your workloads back to your own datacenter or another third-party cloud running a Knative-compatible environment. Here is what one of our customers, QiTech had to say:

“Cloud Run for Anthos brings additional features like application level auto scaling to our Kubernetes clusters, making it very simple to manage the cluster to scale when needed. It takes various actions that follow Kubernetes best practices and abstracts them, allowing us to focus more on our service and less on its infrastructure.” – Danilo Porto, Lead DevOps Engineer, QI Tech

We’ve also been collaborating with popular ISV partners to extend the capabilities of Cloud Run for Anthos across key areas like CI/CD, application performance monitoring (APM), and security. We’re excited to announce support from CircleCI, CloudBees, Datadog, Dynatrace, GitLab, JFrog, New Relic, Octarine, Palo Alto Networks, PureSec, Sumo Logic, and Sysdig. These partnerships mean organizations can easily integrate Cloud Run for Anthos using popular ISV solutions and still take advantage of existing tooling investments.

Cloud Run for Anthos running on Google Cloud is available as a free trial until May 14, 2020, with no additional charge beyond the cost of GKE.

Knative: the basis of Cloud Run

Cloud Run is possible, in part, through our longstanding commitment to open source. We started Knative more than a year ago to help developers easily write serverless applications on top of Kubernetes. Working alongside industry leaders such as IBM, Pivotal, Red Hat, SAP and TriggerMesh, we built Knative to provide the essential components you need to build, deploy and manage modern serverless workloads anywhere you choose.

The Knative project is supported by more than 100 organizations and approximately 450 individual contributors. Already, organizations such as T-Mobile are building innovative applications for production use cases with Knative. Releases over the last year have focused on codifying best practices from successful real-world Kubernetes frameworks, and collecting feedback to ensure Knative delivers on its promise of portability and ease of use. By bringing these learnings to Cloud Run, we aim to bring the serverless developer experience to your Kubernetes cluster anywhere.

Cloud Run, don’t walk, to serverless containers

Here at Google, we believe in the power of serverless and the benefits of containers, and give you the best of both with Cloud Run. We also believe that the tools to enable serverless containers should be built in the open, by the community. Check out our serverless quest to give Cloud Run a try. If you’re already using Cloud Run for Anthos, please upgrade your GKE cluster. It’s your journey—we’re excited to be there alongside you.

App Engine Java 11 is GA—deploy a JAR, scale it, all fully managed

Attention, Java developers. If you want to build modern Java backends, use modern frameworks, or use the latest language features of Java 11, know that you can now deploy and scale your Java 11 apps in App Engine with ease.

We’re happy to announce that the App Engine standard environment Java 11 runtime is now generally available, giving you the flexibility to run any Java 11 application, web framework, or service in a fully managed serverless environment.

Modern, unrestricted, managed
With the App Engine standard environment Java 11 runtime, you are in control of what you want to use to develop your application. You can use your favorite framework, such as Spring Boot, Micronaut, Quarkus, Ktor, or Vert.x. In fact, you can use pretty much any Java application that serves web requests specified by the $PORT environment variable (typically 8080). You can also use any JVM language, be it Apache Groovy, Kotlin, Scala, etc.

With no additional work, you also get the benefits of the fully managed App Engine serverless platform. App Engine can transparently scale your application up to handle traffic spikes, and also scale it back down to zero when there’s no traffic. App Engine automatically updates your runtime environment with latest security patches to the operating system and the JDK, so you don’t have to spend time provisioning or managing servers, load balancer, or even any infrastructure at all!

You also get traffic splitting, request tracing, monitoring, centralized logging, and production debugger capabilities out of the box.

In addition, if you can start your Java 11 application locally with java -jar app.jar, then you can run it on App Engine standard environment Java 11 runtime, with all the benefits of a managed serverless environment.

Finally, the App Engine standard environment Java 11 runtime comes with twice the amount of memory than the earlier Java 8 runtime, at no additional cost. Below is a table outlining the memory limit for each instance class.

Getting started with a Spring Boot application
At beta, we showed you how to get started with a simple hello world example. Now, let’s take a look at how to start up a new Spring Boot application.

Learn how to deploy a Spring Boot application using a JAR file to Google App Engine standard for Java 11. The runtime can now deploy a JAR file, using gcloud command line, or Maven and Gradle plugins.

To start up a new Spring Boot application, all you need is a GCP project and the latest gcloud CLI installed locally. Then, follow these steps:

1. Create a new Spring Boot application from the Spring Boot Initilizr with the Web dependency and unzip the generated archive. Or, simply use this command line:

2. Add a new REST Controller that returns “Hello App Engine!”:

src/main/java/com/example/demo/HelloController.java

3. Build the application JAR:

4. Deploy it using gcloud CLI:

Once the deployment is complete, browse over to https://[PROJECT-ID].appspot.com to test it out (or simply run gcloud app browse). Your application will use the default app.yaml configuration, on an F1 instance class.

To customize your runtime options, such as running with more memory and CPU power, configure an environment variable, or change a Java command line flag, or add an app.yaml file:

src/main/java/appengine/app.yaml

Then, you can deploy an application using either a Maven or Gradle plugin:

Note: You can also configure the plugin directly into Maven’s pom.xml, or in Gradle’s build script.

Finally, you can also deploy a pre-built JAR with an app.yaml configuration using the gcloud CLI tool. First create an empty directory and place both the JAR file and app.yaml in that directory so the directory content looks like this:

Then, from that directory, simply run:

Try it out!
Read the App Engine Standard Java 11 runtime documentation to learn more. Try it with your favorite frameworks with samples in the GCP Java Samples Github Repository. If you have an existing App Engine Java 8 application, read the migration guide to move it to App Engine Java 11. Finally, don’t forget you can take advantage of the App Engine free tier while you experiment with our platform.

From the App Engine Java 11 team: Ludovic Champenois, Eamonn McManus, Ray Tsang, Guillaume Laforge, Averi Kitsch, Lawrence Latif, and Angela Funk.

The Serverless Supercomputer

Harnessing the power of cloud functions to build a new breed of distributed systems

What if every developer had access to the world’s largest supercomputer?

The Serverless Journey So Far

When AWS Lambda launched on November 13, 2014, it created a new way of writing applications in the cloud. Today, developers around the world in every conceivable type and size of organization enjoy the lower costs and faster time to market of Serverless apps.

The journey from that initial release to today isn’t just about growth in adoption and scale: It’s also the story of an ever-increasing “target space” for Serverless apps. What began as a way to react to objects stored in Amazon S3 has grown to encompass event handling across the portfolios of every major cloud vendor. Over the years new capabilities were added that enabled Serverless architectures to be used for building mobile and web backends, process streaming data, replace cron jobs, and much more. Cloud vendors have found ways to make more and more of their capabilities serverless: not just the obvious ones like object stores and pub/sub services, but also SQL databases, data analytics queries, IoT, and more. This innovation is far from over— recent advances such as Amazon API Gateway’s ability to auto-frame websocket traffic and turn it into Lambda function calls, also known as mullet architectures, enables a whole new class of capabilities that formerly required heavyweight servers and deployment methodologies. These innovations come in many forms: new patterns and frameworks, new services (like AWS’s AppSync and Google’s Cloud Run), and the ever-growing set of features among the existing cloud vendor Serverless offerings.

The simplicity of Serverless coupled with its rapid pace of innovation has helped it become wildly successful — the benefits of not needing to own, scale, manage, or secure infrastructure lets developers focus on their business instead of the care and feeding of servers or containers. These benefits aren’t just technical — companies that adopt Serverless architectures also typically lower their cloud compute bills by up to 90% or more thanks to the fact that Serverless functions achieve 100% utilization, versus typical corporate server utilizations of 10–15%.

But as great as these advances have been, even enabling some companies to go entirely Serverless, they’re not enough. Large scale data processing, parallel algorithms, streaming content, distributed job management and plenty of other tasks are still primarily handled using the same multi-tier server architectures we were deploying in the 1990’s. Is it possible to apply Serverless techniques to big data, ML modeling, generic algorithms, video transcoding, and other compute-intensive domains and gain the same kinds of cost and time-to-market improvements that it offers today for web, mobile, and event-based applications? Can we get the same benefits for High Performance Computing (HPC) applications that Serverless brought to event handling and web and mobile backends?

Where Serverless has been successful…and where it can go next.

The Rise of the Serverless Supercomputer

Complexity is never a virtue. The promise at the heart of Serverless approaches is that mapping code to servers (or containers), and keeping those servers running securely at scale, should be the responsibility of cloud vendors. Figuring out where to run code and how to keep the infrastructure healthy represents an unnecessary distraction for every application developer — regardless of what their application might be. This has never been more true than in the world of big data and big compute, where the problems of partitioning, deploying, and managing servers can be an overwhelming challenge to the developers. It’s even more true when you consider that the “developer” of such applications might be a biology researcher, statistician, astronomer, or other professional with a need to crunch numbers but not necessarily the desire or skill to scale and babysit servers.

Meanwhile, Serverless functions now possess massive fleets, with aggregate computing power that’s larger than the entire computing capability of the public cloud just a few years ago. With that scale of processing power, Serverless functions in the cloud now rival purpose-built supercomputers in the total amount of silicon they employ…the question is no longer whether they will scale as a service, but whether we can find ways to harness all that power in actual HPC applications.

There are some tantalizing suggestions that this is possible. The world’s fastest video transcoding algorithm known today, ExCamera, doesn’t run on GPUs or other specialized hardware…it was built using AWS Lambda. Serverless algorithms for highly parallel linear algebra are already within 33% of conventional approaches while exhibiting 240% better compute efficiency. Fannie Mae has ported massive Monte Carlo simulations on loan portfolios from mainframes to AWS Lambda, resulting in faster completion times, lower costs, and more flexible scaling. Other researchers have found ways to take jobs normally run on laptops and desktops and move them into the cloud, shaving hours off distributed build and compute times.

Solving existing problems at this scale is exciting, but it doesn’t stop there. It’s also highly likely that Jevon’s Paradox will apply — for example, if we can find ways to parallelize video transcoding such that editing can happen in real time, more people will edit more videos. This suggests that, far from being the rarefied province of researchers and a few hardcore number crunchers, “Serverless Supercomputing” will actually unlock new applications and enable powerful new features in the apps we use today. Bottom line? The easier and cheaper it becomes to apply massive computing power to find answers quickly to hard problems, the more likely we are to ask such questions.

Serverless Supercomputers Are Still Missing some Parts

The examples above are exciting — they illustrate what’s possible with a Serverless approach and that it has the potential to revolutionize these applications…just as it changed how we write event handlers and API-driven backends. But here’s the bad news: Each of the teams building one of the applications listed above had to manually create a lot of scaffolding in order to get their job done. None of these were simple “out of the box” applications, and creating that underlying framework for distributed algorithms on top of vendor-provided Serverless offerings was nontrivial in every case. The good news? It was also fairly similar — and we can read the list of what was required as a form of product spec for building the Serverless Supercomputing platform of the future.

Before we tackle the specifics, it’s worth asking the broader question: Why would Serverless algorithms and architectures differ from what’s come before? The answer is simple: For most of history we’ve thought about the theory and practice of distributed systems as unlimited time on limited space. The problem statement in pretty much every distributed systems research paper or highly parallel algorithm has been to harness a limited set of machines (servers) that live forever to perform a computation that can’t fit inside just one of them. Serverless turns that fundamental assumption on its head: Its computation model is limited time on unlimited space. That shift causes us to rethink everything about our approach to distributed algorithms…and creates the disruptive potential for entirely new innovations that can bring previously unavailable computing power to the masses!

How Serverless changes our model of distributed computation.

What’s needed to enable a Serverless Supercomputer? Creating that capability requires a combination of closing gaps to conventional (“serverful”) compute, like networking, as well as crafting new services that address the impedance mismatch between compute (cloud functions like AWS Lambda) and server-based storage technologies like redis. It requires fundamentally new algorithms for sorting and searching that can exploit Serverless’s ability to tightly envelope costs while playing nicely within its temporal limitations. And it requires new frameworks, including the ability to rapidly distribute and choreograph work across tens of thousands of functions running in parallel. Lets take a look at some specific “missing parts” and the roles they would play in a Serverless Supercomputer architecture:

Distributed networking — All distributed algorithms depend on the ability to connect computing nodes to one another, and in many cases on the ability to dynamically establish and modify the topology of those communication paths. Today’s cloud functions don’t support this capability directly, and in fact most disable inbound TCP/IP. To make Serverless Supercomputing possible, we need to address this gap in the fundamentals.
Fine-grained, low-latency choreography — While existing managed workflow services do a nice job at modeling business processes, they are generally orders of magnitude too slow (and too costly) to manage the lifecycle of tens of thousands of function lifetimes, let alone to coordinate intra-function invocation transitions. A Serverless Supercomputer will also need custom workflow functionality, such as straggler management, that reflects its unique semantics and challenges.
High-speed key-value stores — Probably the most obvious missing piece in the managed portfolios of today’s cloud vendors is a high-speed (DRAM-based) key-value store. Cloud object stores such as Amazon S3 offer low-cost bandwidth and high throughput, but at the expense of high latency. NoSQL databases, such as Amazon DynamoDB, offer faster performance but at costs that are too high to effectively serve as a shared memory system for transient state. (This isn’t surprising; DynamoDB is designed to make writes persistent and durable…neither of which are typically necessary for storing the in-flight state of an algorithm that could simply be restarted.) Server-based infrastructure deployments like redis (or their cloud vendor equivalents) suffer from a grave impedance mismatch with Serverless functions, taking us back to the world of individual server management and scaling. Fortunately, recent work in academia shows promise in better matching storage lifetimes to Serverless algorithms and in designing cost effective scalable storage.
Immutable inputs and outputs associated with function invocations — Systems that have succeeded at utilizing the power of Serverless at massive computational scale have all needed to find a way to create input and output bindings in order to execute large-scale dataflows. Unlike the event-based bindings that exist today in some Serverless architectures, these objects are usually ephemeral outside of the algorithm’s execution and occur at massive scale. Fortunately, immutable object management frameworks have proven tractable to layer on top of existing cloud vendor services; they just need to be harvested out of academic research and made available to developers at large.
Ability to customize code and data at scale — Serverless functions like AWS Lambda have “control planes” (APIs for creating, updating, and deleting functions) that were designed for human interaction scale. But these control planes are ill-suited for a situation where 10,000 parallel function invocations each need slightly different code to perform a coordinated algorithm and then disappear forever. Similarly, cloud function invocation is designed to transmit arguments (such as event payloads) only once, when the function is invoked, and then return a single result when it completes. Distributed algorithms may require large amounts of data to be delivered throughout a function’s lifetime, with partial results being transmitted before the function exits.
Execution dataflows — With support for the preceding items, it’s possible to create and execute dataflow graphs that represent complex, multi-node distributed algorithms at massive scale. These dataflows will represent a new layer of abstraction for Serverless computing, because they describe the entire computation, not just how to run or invoke an individual function.
General purpose and domain-specific algorithms customized to the “size and shape” of Serverless functions — Finally, developers need support for both general purpose (sorting, searching, grouping, etc.) and domain-specific (video transcoding, genetics) libraries that are tuned to the Serverless platform. With these in place, they can focus on the specific needs of their algorithms and avoid reinventing the wheel to get things done.

The emerging Serverless Supercomputer technology Stack.

The Journey Ahead

As the saying goes, the future’s already here…it’s just not evenly distributed yet. Building any new technology stack takes time and work, so expect to see the Serverless Supercomputer emerge incrementally over the next several years. University researchers are already hard at work and companies like ServerlessTech are already tackling the problem of distributed networking for cloud functions.

Fortunately, it’s not an all-or-nothing proposition: Every incremental step will open up new application domains to take advantage of Serverless approaches. Just adding support for networking, for example, makes prewarming capacity, peer-to-peer file sharing, real-time content distribution, and exchanging additional arguments and results with a cloud function possible. Cloud vendors also have critical roles to play that only they can address: improvements to network bandwidth and jitter, additional memory and file system storage, higher (and easier to self manage) limits on concurrency, and a host of feature details from managed NAT customization to more contextual information inside of functions. There’s a lot to do, but it’s never been a better time to be a developer or innovator in this space — the world’s most powerful and easiest to use supercomputer is being designed and built right now!

This article includes material from my ServerlessConf NYC ’19 slides.

The Serverless Supercomputer was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.

25 Oct, 2019
(0) Comments
By editor
AWS, aws-lambda, cloud-functions, HowTo, serverless, supercomputing

The State of Serverless, Circa 10/2019

The State of Serverless, circa 2019

My observations from Serverlessconf NYC and the current state of serverless, the ecosystem, the friction, and innovation

Back in the spring of 2016, A Cloud Guru hosted the first ever Serverless conference in a Brooklyn warehouse. In many ways, that inaugural conference was the birth of the Serverless ecosystem.

Serverlessconf was the first time that this growing community came together to talk about the architectures, benefits, and approaches powering the Serverless movement.

Last week A Cloud Guru once again brought top cloud vendors, startups, and thought leaders in the Serverless space to New York City to exchange ideas, trends, and practices in this rapidly growing space.

In addition to the “hallway track”, which was a great way to meet and (re)connect with talented and passionate technology experts — there were multiple tracks of content.

Collectively, these conferences are a great way to take the pulse of the community — what’s getting better, what’s still hard, and where the bleeding edge of innovation sits.

With apologies to the vendors and talks I didn’t manage to get to, here’s my take on the State of Serverless after spending nearly a week with many of its best and brightest.

Enterprise users have shown up — with their stories
Back in 2016, much of the content (and nearly every talk’s opening slides) at Serverlessconf was some flavor of “Here’s how we define Serverless.”

Content focused on how to get started and lots of how-to talks. Notably absent back in 2016? Enterprise users talking about their experiences applying Serverless in real life with the sole exception of Capital One.

While the latest Serverlessconf retains its technology and practice focus, it was fantastic to see companies like the Gemological Institute of America, Expedia, T-mobile, Mutual of Enumclaw Insurance, and LEGO up on stage in 2019 talking about adopting and benefitting from Serverless architectures.

Growing ecosystem
The highly scientific metric of “square feet of floor space devoted to vendors” continues to grow year over year. But more importantly, those vendors have moved from early stage awareness and information gathering to offering products and services in the here and now.

System integrators and consulting firms specializing in Serverless practices are also showing up — more evidence of enterprise traction in the space.

Configuration & AWS CloudFormation are still creating friction
The buzz was around whether declarative or imperative “Infrastructure-as-Code” is the better approach, alternatives to CloudFormation, easier ways to construct and deploy Serverless architectures. Topics like these featured strongly in both actual content and hallway conversations in 2019 — just as they did in 2016.

Whatever your position on recent approaches like AWS’s cdk and the utility of declarative approaches like AWS SAM, it’s clear that CloudFormation and other vendor-provided options still aren’t nailing it.

Vendors like Stackery.io got a lot of foot traffic from attendees looking for easier ways to build and deploy Serverless apps, while talks from Brian LeRoux and Ben Kehoe explored both the problem, and potential solutions, to the difficulties of using CloudFormation today.

Google and Cloudflare are playing the role of category challengers
Google Cloud Run is taking an intriguing approach — offering customers a container-based specification with the scales-on-usage and pay-per-request model of AWS Lambda. It’s still too early to call GCR’s product market fit, but it’s exciting to see Google step back and reimagine what a Serverless product can be.

Meanwhile, Cloudflare workers exploit that company’s massive edge infrastructure investment to run chunks of computation that make Lambda functions look huge by comparison. It’s not necessarily a solution to general compute, but given expectations that the bulk of silicon will live on the edge, rather than in data centers, in the future, I’d keep my eye on this one.

Serverless innovation isn’t over
Johann Schleier-Smith talked about UC Berkeley’s position paper on Serverless and the growing attention that Serverless is getting from the research community.

Yours truly laid out a recipe for building the Serverless Supercomputer, starting with Serverless Networking that opens the door to building distributed algorithms serverlessly.

Chris Munns reviewed the pace of innovation for AWS Lambda since its launch in 2014 and hinted at more to come at next month’s AWS re:Invent in Las Vegas.

With their amusing name helping to grab attention, The Agile Monkeys presented a Serverless answer to Ruby on Rails with a high-level object model that compiles down to Lambda functions and other serverless componentry.

It’s still not easy enough
Serverless might sound like a technology stack, but it’s really a vision for software development. In contrast to the ever-growing complexity of servers and Kubernetes, attendees at a Serverless conference are looking for ways to do more with less — less infrastructure, less complexity, less overhead, and less waste.

But while a desire for simplicity and “getting the business of business” done unites the attendees at a conference like this, it’s still the case that too much non-essential complexity gets in the way.

Tools, IDEs, debuggers, security, config & deployment, CI/CD pipelines…a lot of energy from vendors to startups to consultants to enterprise adopters is flowing into getting Serverless projects across the finish line. It may be way easier than servers (and containers), but it’s clearly still not easy enough.

Conferences like this help, but more and better documentation, more sharing of best practices, and tools that can truly streamline the job of delivering business value on top of Serverless remain a work in progress…leaving a lot of untapped potential opportunity in the space still to explore!

Author disclosures: I presented at Serverless NYC ’19 for which I received a registration fee waiver. I’m a former employee of both AWS and Microsoft and currently an independent board member of Stackery.io. I received no compensation from any of the companies or organizations cited above for writing or distributing this article and the opinions provided are my own.

The State of Serverless, Circa 10/2019 was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.

18 Oct, 2019
(0) Comments
By editor
AWS, Azure, cloud-computing, Google Cloud Platform, HowTo, serverless