So far, in our Cloud Workflows series, we have seen some of the YAML syntax for defining workflows. However, steps are defined after each other, as a series of step definitions, but in spite of the jump instructions, the conditionals, you don’t really see visually what is going to be the next potential step in a workflow execution.

Fortunately, a new UI enhancement has landed in the Google Cloud Console: the ability to visualize a workflow definition with a graph, when you’re editing the definition. Furthermore, the graph is updated in quasi real-time as you make updates to the definition.

In the previous articles about Google Cloud Workflows, we talked about how to assign variables, create expressions, and also how to jump from a step to another. It’s time to combine both aspects to understand how we can do conditional jumps, thanks to the switch instruction.

Let’s start with a first step defining a variable, whose value we’ll use in our switch condition:

- assignement:
    assign:
        - number:  42

Then we’re going to create our second step that will use a switch instruction, with an expression:

Now that we have multiple steps in our workflow definition, let’s see how we can pass data around, from a step to another.

In a step, you can assign values to variables. Those values can be ints, doubles, strings, or booleans (and also null). Use the assign keyword as follows:

- assignments:
    assign:
        - two:  2
        - pi:  3.14
        - message:  "Hello"
        - bool:  True

Those variables are available in the whole scope of the workflow, and can be accessed in other steps. So let’s see how we can do something with those variables. Let’s add a second step to our workflow definition:

Let’s continue our discovery of Goole Cloud Workflows!

Yesterday, we discovered the UI of Workflows. We created our first workflow. We started with a single step, returning a greeting message:

- sayHello:
    return: Hello from Cloud Workflows!

A workflow definition is made of steps. But not just one! You can create several steps. In YAML, the structure of your workflow will be something like:

- stepOne:
    # do something
- stepTwo:
    # do something else
- sayHello:
    return: Hello from Cloud Workflows!

By default, steps are executed in the order they appear, from top to bottom. The execution will finish when either you return a value, or you reach the final step. If there’s no return statement, a null value is returned as result of the workflow execution.

With more and more interconnected services, making sense of their interactions becomes critical. With Google Cloud Workflows, developers can orchestrate and automate such complex systems by creating serverless workflows.

In this series of articles, we will learn together how to use Goole Cloud Workflows, and get to know all its features, with short and easy to read tutorials. For our first day, we’ll discover and use the Workflows UI in the cloud console. We will create a simple “hello world” workflow, consisting of a simple step. Going further, in the coming days, we’ll learn more about advanced features. But first things first!

The trend toward splitting a monolith into fine-grained loosely-coupled microservices has its merits. It allows us to scale parts of an application more easily. Teams become more effective on their focused perimeter. However, in a chain or graph of services interacting with each other via message buses or other eventing mechanisms, it becomes difficult to understand when things start to break. Your business processes spanning those services are in limbo. Here starts detective work to find out how to get back on track.

Last week, I had the pleasure of presenting Micronaut in action on Google Cloud Platform, via a webinar organized by OCI. Particularly, I focused on the serverless compute options available: Cloud Functions, App Engine, and Cloud Run.

Here are the slides I presented. However, the real meat is in the demos which are not displayed on this deck! So let’s have a closer look at them, until the video is published online.

On Google Cloud Platform, you have three solutions when you want to deploy your code in a serverless fashion (ie. hassle-free infrastructure, automatic scaling, pays-as-you-go): 

The Java programming language recently turned 25 years old, and it’s still one of the top-used languages powering today’s enterprise application customers. On Google Cloud, you can already run serverless Java microservices in App Engine and Cloud Run. Today we’re bringing Java 11 to Google Cloud Functions, an event-driven serverless compute platform that lets you run locally or in the cloud without having to provision servers. That means you can now write Cloud Functions using your favorite JVM languages (Java, Kotlin, Groovy, Scala, etc) with our Functions Framework for Java, and also with Spring Cloud Functions and Micronaut!

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.

Java celebrates its 25th anniversary!  Earlier this year, the Apache Groovy team released the big  3.0 version of the programming language.  GMavenPlus was published in version 1.9 (the Maven plugin for compiling Groovy code) which works with Java 14. And today, Google Cloud opens up the beta of the  Java 11 runtime for Cloud Functions. What about combining them all?

I’ve been working for a bit on the Java 11 runtime for Google Cloud Functions (that’s the Function-as-a-Service platform of Google Cloud, pay-as-you-go, hassle-free / transparent scaling), and in this article, I’d like to highlight that you can also write and deploy functions with alternative JVM languages  like Apache Groovy.