Requirements:

• an existing Google Cloud Platform account with a project
• you have enabled the Cloud Run service and already deployed a container image
• your local environment’s gcloud is already configured to point at your GCP project

By default, when you deploy a Cloud Run service, it is secured by default, unless you use the –allow-unauthenticated flag when using the gcloud command-line (or the appropriate checkbox on the Google Cloud Console).

But once deployed, if you want to call it locally from your development machine, for testing purpose, you’ll have to be authenticated.

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. 

Requirements:

• an existing Google Cloud Platform account
• you have enabled the Cloud Run service and deployed already a container image

One of the nice things with Cloud Run is that when you deploy your services, you get a URL like https://myservice-8oafjf26aq-ew.a.run.app/, with a certificate, on the run.app domain name, etc.

You see the name of the service: myservice, the region shortcut where it was deployed: ew (Europe West), and then .a.run.app. However, you can’t guess ahead of time what the final URL will be, as there is a randomly generated part in the URL (here: 8oafjf26aq). Let’s see how we can discover this whole URL.

Requirements:

• an existing Google Cloud Platform account
• a Git or Github repository containing your project
• your project can have a Dockerfile (but not mandatory)

With Cloud Run, you can easily deploy a container image and let it scale up and down as needed, in a serverless fashion:

• No need to focus on infrastructure (provisioning servers, clusters, upgrading OS, etc.)
• Your application can scale transparently from 0 to 1, and from 1 to n (no need for a pager when your app is featured on Hackernews)
• You pay as you go, proportionally to the usage

If your project is hosted on Github, for example, how can you help users get started with your project? You usually explain all the steps needed to build a container image, or where to fetch a pre-made image from a hub, and then steps to actually deploy that image on the platform. But thanks to the Cloud Run button, you can add a button image on your README.md page for instance, and then users can click on it and get started with building and deploying to a GCP project automagically.

Requirements:

• an existing Google Cloud Platform account and project
• a Java or alternative language web application
• a build that creates a standalone executable JAR file

Usually App Engine applications in Java are deployed with the gcloud command-line interface, or via a Maven or Gradle build plugin. Either way, an app.yaml file to describe your application is required to let the cloud SDK know that the project at hand is an App Engine project.

Requirements:

• an existing Google Cloud Platform account and project
• a Java or alternative language web application
• a Gradle build that creates a standalone executable JAR file

In youd build.gradle file, add the App Engine gradle plugin to your buildscript dependencies:

buildscript {
    repositories {
        jcenter()
        mavenCentral()
    }
    dependencies {
        classpath 'com.google.cloud.tools:appengine-gradle-plugin:2.+'
    }
}

Apply the plugin, to make use of it:

apply plugin: "com.google.cloud.tools.appengine-appyaml"

Then you can configure the appengine task to point at the standalone executable JAR:

A new Java runtime was announced for Google App Engine standard: with Java 11. It’s currently in beta, but anybody can already try it out. Another interesting announcement was the fact that the instances running your apps now get double the memory! So with this double dose of great news, I decided to craft a little tutorial to show how to deploy a Micronaut application on App Engine Java 11. And because Apache Groovy is, well, groovy, I’ll go ahead and use Groovy for my programming language, but of course, the same steps apply to Java workloads as well.

Yesterday, we announced new second-generation runtimes for Go 1.12 and PHP 7.3. In addition, App Engine standard instances now run with double the memory. Today, we’re happy to announce the availability of the new Java 11 second-generation runtime for App Engine standard in beta. Now, you can take advantage of the latest Long-Term-Support version of the Java programming language to develop and deploy your applications on our fully-managed serverless application platform.

Based on technology from the gVisor container sandbox, second-generation runtimes let you write portable web apps and microservices that take advantage of App Engine’s unique auto-scaling, built-in security and pay-per-use billing model—without some of App Engine’s earlier runtime restrictions. Second generation-runtimes also let you build applications more idiomatically. You’re free to use whichever framework or library you need for your project—there are no limitations in terms of what classes you can use, for instance. You can even use native dependencies if needed. Beyond Java, you can also use alternative JVM (Java Virtual Machine) languages like Apache Groovy, Kotlin or Scala if you wish.

At the end of December, I was contacted by someone I didn’t know, who asked me some interesting questions, and that led me to quite a bit of introspection.

As a Java Champion and with your career history. I wanted to ask you what you consider are the most important skills for a Java programmer to have in their toolbox, especially a Senior Java programmer? Or maybe even a better question is what skills you developed that helped you become the Java Developer/Groovy Language Developer that you are today.

Google Cloud Storage is the ideal product to store your object files (binary files, pictures, audio/video assets, and more).

Until recently, there was an option in the Google cloud console with a checkbox to quickly make a file or bucket public. However, and I would add “unfortunately”, users tended to inadvertently clicking the checkbox, thus making potentail confidential assets public. So this risky, but easy, option, has been removed to avoid any unwanted data leak.