Hot on the heels of the announcement of the general availability of JDK 14, I couldn’t resist taking it for a spin. Without messing up my environment — I’ll confess I’m running 11 on my machine, but I’m still not even using everything that came past Java 8! — I decided to test this new edition within the comfy setting of a Docker container. Minimal OpenJDK 14 image running JShell Super easy to get started (assuming you have Docker installed on your machine), create a Dockerfile with the following content: Read more...

Requirements: an existing Google Cloud Platform account and project Cloud Functions should be enabled for that project Compared to the previous tip when using Exress’ request path attribute, we can take advantage of Express routing. So to support the following paths: https://us-central1-myproject.cloudfunctions.net/api/customers https://us-central1-myproject.cloudfunctions.net/api/customers/32 https://us-central1-myproject.cloudfunctions.net/api/customers/32/address We can have our functions require Express by adding Express in package.json: { "name": "mini-api-router", "version": "0.0.1", "dependencies": { "express": "^4.17.1" } } Then we can require that dependency in our new functions script: Read more...

Requirements: an existing Google Cloud Platform account and project Cloud Functions should be enabled for that project We often use individual HTTP Cloud Functions as a single endpoint, and we pass data to the functions with either query parameters, or via a POST body payload. Although it’s a good practice to keep the scope of a function small, however, you can easily write mini Web APIs for a given function, with different paths for different needs, like with usual Web frameworks. Read more...

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). Read more...

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 . Read more...

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? Read more...

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: Read more...

Last week, I was in Tokyo for the first time, to speak at the Google Cloud Next conference. During the DevDay, I spoke about Google App Engine and its 2nd generation runtimes, and I also presented Cloud Run on how to deploy and run containers in a serverless fashion. It’s been awesome to visit Japan for the first time and get a chance to meet developers there. Here are the slides I presented: Read more...

At DataXDay 2019, last week, I had the chance to present an updated version of my introductory talk on the serverless compute options on Google Cloud Platform. There’s always something new to cover! For instance, if I put my Java Champion hat on, I’d like to mention that there are new runtimes for App Engine standard, like the beta for Java 11, and there’s twice the amount of memory as before. Read more...

Last week at the Google Cloud Next conference, I had the chance to speak about the Java developer’s journey through the “serverless” offering of Google Cloud Platform, with my colleague Vinod Ramachandran (Product Manager on some of our serverless products): Serverless Java in 2019 is going to be ubiquitous in your favorite cloud. Well, it’s actually been 10 years since you could take advantage of Java on Google App Engine. But now you can run your apps on the brand-new Java 11 runtime. Read more...