Getting started with Micronaut on Google App Engine Java 11

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.


Getting started on Google Cloud Platform


In this article, I assume you’ve created an account on Google Cloud Platform already (follow the “getting started” blue buttons to create an account otherwise and benefit from the free tier and free quota), and that you’ve downloaded and installed the gcloud command-line SDK. You’ll be able to follow the first few steps in the quickstart guide, to create your GCP project and make it ready for using App Engine, in particular those commands:


$ gcloud projects create mn113-gae-java11 --set-as-default


You’ll have to change the project ID from “mn113-gae-java11” to your own name of choice.


$ gcloud app create --project=mn113-gae-java11


It’ll ask for a cloud region to use, I’ve decided to go with europe-west for this one.


The above steps can as well be done from the cloud console UI as well, at https://console.cloud.google.com.


Although your application will run for free within the free quota, we need to enable billing for our app, as it’s going to use Cloud Build to build our app, and the latter requires billing to be enabled.

To enable billing and the Cloud Build API, please follow the first step of the quickstart guide mentioned above.


Building our Micronaut application


Time to fire the Micronaut goodness! On my machine, I’m using SDKman to install my SDKs, so I’ve installed Java 11 and Micronaut 1.1.3 as explained in Micronaut’s getting started guide.


Our first step will be to create our basic Micronaut application, thanks to the following command, with the mn command-line SDK:


$ mn create-app mn113-gae-java11 --lang=groovy


The structure of your Micronaut project is created, with a Gradle-based build, an Application main class, an application.yml file to configure your application.


As this application isn’t yet doing anything useful, we’re create a “Hello World” controller with:


$ mn create-controller hello


We’ll modify this newly created HelloController.groovy controller as follows:


package mn113.gae.java11
import io.micronaut.http.annotation.*
@Controller("/hello")
class HelloController {
    @Get("/")
    String index() {
        return "Hello Micronaut!"
    }
}

On the /hello path, we’ll simply return a plain text response showing our greeting message.


To run your application locally, to check everything is working fine, you’ll simply run:


$ ./gradlew run


And you can check that localhost:8080/hello returns the Hello Micronaut message. So far so good.


Configure our Micronaut application for App Engine


In order to deploy the App Engine, we’ll use the App Engine Gradle plugin. So we need to amend our build.gradle a little.


Let’s define where Gradle will find the plugin:


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

We’ll make use of the plugin:


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

Let’s configure the App Engine section:


appengine {
    stage.artifact =
            "${buildDir}/libs/${project.name}-${project.version}.jar"
    deploy {
        projectId = "mn113-gae-java11"
        version = "1"
    }
}

Note that App Engine’s version string is not supporting dots or underscores (only alphanumeric characters), hence why I replaced the version property. Furthermore a reported issue prevents me from reusing the Gradle project’s own project property in the projectId property.


Configure the App Engine deployment


App Engine has its own deployment configuration file, where you will define the App Engine runtime (in our case Java 11), and you can also decide what kind of instance will be used to run your code. Last but not least, you can customize the entry point which defines how your application should be started.


In src/main/appengine we’ll add a file named app.yaml:


runtime: java11
instance_class: F4
entrypoint: 'java -agentpath:/opt/cdbg/cdbg_java_agent.so=--log_dir=/var/log -jar mn113-gae-java11-0.1.jar'

Deploying to App Engine


Now you’re ready to deploy your Micronaut application on App Engine’s Java 11 runtime! 


$ ./gradlew appengineDeploy


After a minute or so, and if billing and the Cloud Build API are enabled as said in the introduction, your Micronaut app should be deployed! You can then browse https://mn113-gae-java11.appspot.com/hello and get your Hello Micronaut greeting.


What’s next


In upcoming articles, I’ll cover some other aspects, like how to configure and optimize static asset serving, or perhaps how to integrate with databases or other services of Google Cloud Platform. So stay tuned!


Update on the recent serverless developments on GCP at DataXDay 2019

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. On Cloud Functions, we have an alpha for Java as well (currently Java 8, but it'll be soon moved to Java 11 instead, as customers are more interested in the latest LTS version)

In this talk, I also covered Cloud Run, and Cloud Run on GKE (Google Kubernetes Engine), as well as telling a few words about the Knative open source building blocks for Kubernetes, which allows to create serverless portable containers.

Here's the slide deck I presented at the conference:


A serverless Java developer’s journey

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. Not only servlet-based apps but also executable JARs. And what about authoring functions? Until now, you could only use Node or Python, but today, Java is the third runtime available for Google Cloud Functions. We will review the various ways you can develop your Java functions. Last but not least, thanks to serverless containers, containerized Java workloads run serverlessly, without you caring for infrastructure, scaling, or paying for idle machines. Through various demos, we will look at the many ways Java developers will be able to write, build, test, and deploy code in Java on the rich serverless offering of Google Cloud Platform.


Until fairly recently, our compute serverless products consisted only of Google App Engine for deploying apps and services, and Cloud Functions for deploying functions. Furthermore, for the Java developer, the situation wasn’t that great as Cloud Functions wasn’t offering any Java support (only Node, Python and Go runtimes), and only App Engine provided a Java 8 runtime.


Fortunately, some very important announcements were made at Cloud Next:


So you can develop Java functions, Java apps and Java-powered containers in a serverless fashion:

  • Scaling on demand as needed to serve incoming requests as well as down to zero when no traffic comes.

  • Paying proportionally to the usage.

  • And all of that, without having to worry with server or cluster provisioning and management.


Without further ado, let me share with you the video and the slides of this presentation:


Video recording:



Slides of the presentation:


Now it’s your turn! If you want to try out functions, apps, and containers in Java, here are a few pointers to get you started:

On curiosity and sharing with the world

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.


In a nutshell, as I answered this person, for me it all boiled down to lots of curiosity, and the desire to share my findings with the world. It’s not really about knowing specific methodologies, technologies or languages, or which soft or hard skills to master. It’s about the core attitudes from which all the rest will derive from. But first, a bit of background about me.

A bit of history

Alright, so if I was contacted (and actually a few others as well) with those questions, it’s because I’m considered to be a visible and public person. Because I’m known for my work in the Java community and more precisely in the Apache Groovy ecosystem. I’ve been in the field for quite a number of years, along with my contributions in Open Source, and that makes me a senior developer. But how did I get there?


You’ve learned a lot during your studies, but often, not much of what you learned is immediately applicable in your daily duties and tasks. So there’s even more to learn to become a productive developer. I started working as a junior Java developer in 2001. I was lucky to have had a great mentor that helped me design and write better code. I also spent quite some time reading Java and development related news websites or blogs. I wanted to know what were the latest trends (new language features, frameworks), the best tools for the job, how developers were developing on their projects. So clearly, I was pretty curious to look beyond just what I was doing at work, but to see if I could become a better programmer by learning from others. There’s so much great content on the web, so much information that is shared, from best practices to bug fixes explanations, that you can learn a lot. That’s also more or less when I started blogging. I saw so many useful blog posts that helped me, that I thought it would be a good thing to share back things I learned that could be helpful to others as well.


In 2003, at work, I needed a way to extend an app I was working on, and clearly, some kind of scripting solution was what would allow the end-users of our app to further customize and tailor the application to their needs. So I spent some time reviewing existing Java scripting solutions, but none were really ideal. Fortunately, that’s when Groovy was born. It was embryonic, and not really ready for prime time though. But it was what I needed.


I started playing with Groovy, but quickly I encountered tons of problems and bugs. Since the code was Open Source, I started looking at its codebase, outside of work. I quickly understood where some of the bugs were coming from, and found ways to fix them. Since the community was pretty open, I participated in the mailing-lists to tell about those bugs, to help other users. It was nice to feel being part of a nice, friendly and helpful community.


I used the bug tracker to file bugs and feature requests, and when I could I even submitted some patches to fix these. My patches were accepted, and in a handful of months, I was asked to become an official committer on the project (which I gladly accepted). By working with the other committers, I learned a lot about Java, the JVM, or how open source projects worked. That was super interesting. Since the code was public, I really wanted all my contributions to be top-notch, perfectly well tested and commented. Somehow I had the impression that the scrutiny of my peers mandated that I had to produce even better code than at work! So I perfected my craft. A lot.


Since I had already started sharing my findings on my blog (and later on on social networks), I became part of the so-called “blogosphere”, and started interacting with other bloggers. I wrote about Java and Groovy, of course, but the discussions with other open source developers, allowed me to also meet them in the real world. We even started a meetup of open source developers that shared what they were working on. That’s how I did my first public presentation, to show Groovy to my peers, in 2004 or so, at our local gatherings. I came to know people working for big companies like Sun or Oracle, as well as smaller actors, from freelancers, to entrepreneurs. A handful of those companies started using Groovy, and that’s how one day, someone asked if I’d be ready to talk with them at a big conference. That was for JavaOne! My first big conference and presentation was in the US in front of 600 persons. Woh… That’s how I started sharing more widely with the world, and also started travelling to spread the word.


I spent a lot of time on Groovy and its ecosystem, and I later got the chance to both work on those technologies for a living (after doing quite a bit of consulting), as well as even creating my own company to focus on the project. At the same time, I was still continuing presenting about Groovy, and still improving the language thanks to the feedback I was getting from the many developers I was meeting all around the world. I was doing developer advocacy at the same time as product management and development. Three hats in one. And by doing developer advocacy, that’s also what landed me my current job of developer advocate at Google.

The ever changing nature of our field

From the narrated history above, there’s a theme that emerges: curiosity. But what lead me to being curious? Tons of people are doing 9-to-5 jobs, and that’s totally fine. However, as we spend so much time in our lives at work, for me, it had to be interesting and motivating. To be interesting, work has to be somehow entertaining — beside spending quality time with great coworkers. If it’s not interesting, you get bored very easily, and you don’t want to wake up every morning to go to the office. So how not to be bored? By making your job more interesting. How to make it more interesting? Well, if you’re passionate about what you’re doing, it’s much easier to go through the day and do fun and interesting things, event for a project that could appear as not being very fancy.


Programming was first a hobby, for me, as a child and teenager. It never really occurred to me it could become my job. Initially, I just wanted to be… an “engineer”. Perhaps in aerospace, or something like this. Who hasn’t dreamt of becoming an astronaut? It’s only late in my studies that I thought I could actually become a developer. So my hobby, my passion, became my job. But there’s a big difference between working on stuff you want, versus being asked to work on stuff for the company which hired you. In order to not be bored, be sure to push for improving the project in interesting ways both for you and the end-users. If possible, perhaps try to introduce and learn new technologies that can make the product better, and at the same time make you learn something new. Be passionate about improving both your projects and your skills.


Notice also that in our field, we actually don’t really have a choice but to learn. When I was a student, my current job didn’t even exist. When I started working, the languages or tools I’m using today weren’t available then yet. So in IT, in programming, etc, there’s always a new language, a new tool, a new practice, new patterns, etc, that come to light. It’s a field where we have to be in a constant learning state, in order to stay relevant. If you’re not learning, your skills will rot, you’ll be less employable, you’ll diminish your chances of having a fantastic job. So you have to be curious and learn all the time. To not be bored, but also to get better at your craft.


With all those new tools, languages, frameworks, technologies, you have to keep up with what’s going on. You have to be ready to learn something new.

Sharing is caring

We talked a lot about being curious, about learning all along, but I also mentioned about sharing. As the saying goes, sharing is caring, but it’s also about creating opportunities for you.


Sharing what I learned or worked on was helpful for others too (who encountered similar problems, for example), but it’s also how I came to meet wonderful people along the way. Even mentors and role models. If I hadn’t blogged or tweeted, I wouldn’t have been able to start making presentations at meetups and conferences. And many of the friends I have today are friends I met along the way, at meetups, conferences, working on open source projects together, and so on.


Without sharing my code, I wouldn’t have had the opportunity to meet my future employers and colleagues, as well as the co-founders of my own startup. Sharing is great to be visible, of course, but it’s a wonderful way to meet new people from whom you’ll learn a lot.


Open source is sharing too. Working on open source projects, nurturing communities and ecosystems around those, further allowed me to meet great people around the world. And it’s what lead me to get the jobs at companies I was interested in. It created great professional opportunities.

Summary

Let’s try to wrap up a bit. It’s really not about learning a particular tool or technology. It’s all about being curious and passionate about your craft, and to share what you’ve learned with the world.


Be curious!


It’ll make your daily job more interesting. You will learn lots of great new technologies. You’ll become a better developer by learning from your peers. You’ll improve your craft and expertise. It’ll increase your employability. You’ll even likely become an expert in your field!


Share with the world!


Write, blog, tweet, present about the things you’ve learned at meetups or conferences. You’ll learn a lot from others along the way. Write and share code, and/or contribute to open source projects. You’ll meet awesome peers and mentors. And will create all sorts of interesting job opportunities.


Be curious and share with the world!

Tip: Making a Google Cloud Storage bucket or file public

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.


However, of course, it’s still possible to make buckets or files stored in Cloud Storage public. But you can’t do it without paying attention! As I never quite remember how to do that (in spite of the linked documentation easily found with a quick Google search), I decided to highlight with a few screenshots how to achieve that!


I assume you already have or created a GCP project, and you also have a bucket full of assets that you want to make public, because you need to share them on the Web, for your mobile application, etc.


To illustrate this tip, let’s have a look at the GCP cloud console:



Making a file public


First, we’ll have a look at making a single file public.


You’ll have to click the vertical triple dot icon on the right of the screen, and click on “Edit permissions”:



Once you’ve clicked on this option, you’ll be given the choice to add new permissions to members or groups of members:


In our case, we want to allow all the users to have read access on that particular file. So I’m giving the “Group” of “allUsers” the “Reader” access level. Then, once saved, in the file browser, you should see the following icon warning you the file is now public:


Making a bucket public


Instead of doing this for each individual file, you can also do the same at the bucket level, to give read access to the bucket and all its files in one go.


From the object browser, click on the “Permissions” tab. You will have to add the “allUsers” members the Storage Object Viewer role:



Click on the “Add members button”, type “allUsers”, select the “Storage > Storage Object Viewer” option, as follows, and click add:


Now if you head back to the file browser, you’ll see all the files have the little warning icon telling you the resource is publicly accessible.


For command-line gurus


I showed the visual approach from the cloud console… but there’s a one-liner you can use, thanks to the gsutil command.


For an individual file:


gsutil acl ch -u AllUsers:R gs://[BUCKET_NAME]/[OBJECT_NAME]

For a whole bucket:


gsutil iam ch allUsers:objectViewer gs://[BUCKET_NAME]


(Where you replace [BUCKET_NAME] with your project name, and [OBJECT_NAME] with the file name)


More…


There’s also a REST API that you can use to handle your buckets and file, as well as different client libraries in different languages that you can use as well.


 
© 2012 Guillaume Laforge | The views and opinions expressed here are mine and don't reflect the ones from my employer.