In this article, we’ll see how to use our reworked data source to produce a bar chart visualization in Kibana Vega. The expected result is the following:

Bar chart visualization

Definition

The bar chart graph we want to set up will therefore have:

• on the X-axis: the JVM memory in Gb
• on the Y-axis: the clusters (environments)

Each environment will also have a series by role (tier).

Set up in Vega

As we already have defined the data for Vega in the previous article, we will only care about visualization creation, ie the scales, axes, marks, and legends in the Vega definition.

{
  "$schema": "https://vega.github.io/schema/vega/v5.json",
  "title": {
    "text": "JVM by cluster and role", 
    "color": "black"
  },
  "description": "Information about JVM on clusters",
  "padding": 15,
  "background": "#FFFFFF",
  "config": {
    "title": { "fontSize": 20 }
  },
  "data": [
    // already done in previous article
  ],
  "scales": [
    // TODO
  ],
  "axes": [
    // TODO
  ],
  "marks": [
    // TODO
  ],
  "legends": [
    // TODO
  ]
}

Axes definition

We will start by defining our 2 axes. These axes must be scaled relative to the values ​​we wish to display.

X-axis

The X-axis will be displayed at the bottom of our graph (“orientation”) and the value labels (“labelColor”) will be black. So we will have to base ourselves on a scale named “xscale” which we will define just after. What gives:

"axes": [
  {
    "orient": "bottom", 
    "scale": "xscale", 
    "labelColor": "black"
  }
]

The scale to be implemented will therefore be of the “linear” type, function of the value of the JVM memory (data source “jvm”), the scale has to go from 0 to the value “total_jvm” available in the data source and which occupies all the available width (“range”).

{
  "name": "xscale",
  "type": "linear",
  "domain": {
    "data": "jvm", 
    "field": "total_jvm"
  },
  "range": "width"
}

This implementation of the X-axis gives:

Y-axis

The Y-axis will be displayed on the left and will show the names of the clusters (environments).

"axes": [
  // ...
  {
    "orient": "left", 
    "scale": "yscale", 
    "labelColor": "black", 
    "tickSize": 0, 
    "labelPadding": 25
  }
]

The “tickSize” to 0 makes the tick on this axis disappear. And we add some padding after the label with “labelPadding”.

The scale for this axis will this time be of type “band” to allow us to group according to our clusters, it is the name of the cluster (“cluster_name”) that will be displayed as a label on this axis but the clusters on this axis will be sorted according to a predefined order contained in the field “cluster_id”, The axis will take all the space available in height (“range”).

"scales": [
    // ...
    {
      "name": "yscale",
      "type": "band",
      "domain": {
        "data": "jvm", 
        "field": "cluster_name", 
        "sort": {
          "op": "median", 
          "field": "cluster_id", 
          "order": "descending"
        }
      },
      "range": "height"
    }
]

This implementation of the Y-axis gives:

Legends

Now we’re going to look at how to add a caption. Why not do it last? To go step by step through the difficulty 😉 in this article but, in fact, it is possible to do it at the very end or as needed.

Legend values

First, we will create the legend with only the values ​​of the roles (identifier allowing to order them). We want symbols (“type”) in the shape of a “square”. The title and labels will be in black (“titleColor” and “labelColor”). The legend will be placed at the bottom (“orient”), horizontally (“direction”). The “tickMinStep” will ensure we have only integer values.

"legends": [
  {
    "type": "symbol",
    "symbolType": "square",
    "fill": "color",
    "labelColor": "black",
    "title": "Roles",
    "titleColor": "black",
    "orient": "bottom",
    "direction": "horizontal",
    "tickMinStep": 1
  }
]

To limit the legend values ​​(exclude an unused one, like data_cold), we could use the “values” attribute instead of “tickMinStep”.

"values" : [ 1, 3, 4] // remove 2 (data_cold)

The “fill” field is associated with a new scale (“color”), based on the “role_id” field and whose “range” will allow us to define the colors we want to use for our legend, for each value (we could have used predefined ranges).

"scales": [
  //...
  {
    "name": "color",
    "type": "linear",
    "domain": {
      "data": "jvm", 
      "field": "role_id", 
      "sort": {
        "op": "median", 
        "field": "role_id", 
        "order": "ascending"
      }
    },
    "range": ["#c0392b", "#f1c40f", "#27ae60", "#3498db"]
  }
]

Legend labels

Now that we have a good base for our legend, we will improve it by associating labels with the roles' names to each sorted “role_id.” For this, we will need another “scale” to display our “role” field (“range”) according to the “role_id” defined in the “domain.”

"scales": [
  //...
  {
    "name": "scale_legend_values",
    "type": "ordinal",
    "domain": {"data": "jvm", "field": "role_id"},
    "range": {"data": "jvm", "field": "role"}
  }
]

We need to update our legend to indicate that we want to display the role label defined in the scale created previously instead of the role value. To do this, we need to use a new property that we haven’t covered yet, namely “encode” which allows us to customize some properties, such as the title, labels, symbols, etc.

In our case, we, therefore, want to update the text of the “labels”, using the lookup table defined in the “scale_legend_values” ​​scale.

"legends": [
    {
      //...
      "encode": {
        "labels": {
          "update": {
            "text": {
              "signal": "scale('scale_legend_values', datum.value)"
            }
          }
        }
      }
    }
  ]

This implementation of the legends gives:

Graphical Marks

We will cover the last part of this article, which discusses how to display the JVM memory value by cluster (environment) and role (tier). The goal is to use a bar chart visualization. In Vega, marks are a visualization's basic visual building block, providing basic shapes whose properties can be set.

Facetting by cluster

To create our bar chart, we first need to define a grouping because we want to group our data by cluster (environment). This will be done by using the “group” brand type and creating a “facet” on the name of our clusters.

"marks": [
  {
    "type": "group",
    "from": {
      "facet": {
        "data": "jvm",
        "name": "facet",
        "groupby": "cluster_name"
      }
    }
    // TODO
  }
]

We also need to make each cluster (environment) have its range on the Y-axis, but this time, for the bar chart, hence a starting point for the value of “y” which is based on the same “yscale” defined in a previous section for the axis display.

"marks": [
  {
    "type": "group",
    "from": {
      // ...
    },
    "encode": {
      "enter": {
        "y": {"scale": "yscale", "field": "cluster_name"}
      }
    }
    // TODO
  }
]

The added lines of code allow us to properly display our clusters (environments) on the Y-axis (one band reserved by cluster).

Scaling by role inside each cluster

Inside each band reserved for our clusters, we must redefine a scale that will allow us to correctly place the bar associated with each role (defined by the field “role_id”). This scale will be of type “band” and as for the environments, we will use the “range” property and set it to “height” to have a band of a fixed height per role. However, this time, we need a height that depends on the “yscale” scale and allows us to divide the height allocated to each environment by the number of roles. Therefore, we must use the “signals” functionality, ie, dynamic variables that parameterize a visualization and can drive interactive behaviors.

"marks": [
  {
    "type": "group",
    "from": {
      // ...
    },
    "encode": {
      // ...
    },
    "signals": [
      {
        "name": "height", 
        "update": "bandwidth('yscale')"
      }
    ],
    "scales": [
      {
        "name": "role",
        "type": "band",
        "range": "height",
        "domain": {"data": "facet", "field": "role_id", "sort": true}
      }
    ]
    // TODO
  }
]

Displaying bars

We can finally do what is necessary to display our bars representing JVM memory by cluster and role.

To do this, we will create “rect” type mark linked to the “facet” created previously. The following properties will need to be specified in the “encode” to be able to customize them.

• “x” and “x2” are used to define the min (0) and max (based on “total_jvm” field) for the length of the rectangle on the X-axis.
• “y” allows us to define where to place the rectangle on the Y-axis, in relation to our “role” subscale, based on the “role_id” field.
• “height” will indicate that the height of the rectangle will be the height of “1” band allocated for a role.
• “fill” is used to use our “color” scale for each role.

"marks": [
  {
    "type": "group",
    "from": {
      // ...
    },
    "encode": {
      // ...
    },
    "signals": [
      // ...
    ],
    "scales": [
      // ...
    ],
    "marks": [
      {
        "name": "bars",
        "from": {"data": "facet"},
        "type": "rect",
        "encode": {
          "enter": {
            "y": {"scale": "role", "field": "role_id"},
            "height": {"scale": "role", "band": 1},  
            "x2": {"scale": "xscale", "field": "total_jvm"},
            "x": {"scale": "xscale", "value": 0},
            "fill": {"scale": "color", "field": "role_id"}
          }
        }
      }
      // TODO
    ]
  }
]

This implementation of the “bars” mark gives:

The last thing to set up is to display the JVM memory value to the right of the rectangle. To do this, we will create another mark of type “text” based on our previous mark “bars” to display our text relative to our bar and with the associated data.

This time, we will define the following properties:

• “x” will place us at the level of “x2” of the “bars”, to position ourselves to the right of our bars.
• “y” allows us to indicate that we want to start from the “y” of our “bars” but with an “offset” allowing us to center on the “height” of the bar.
• “fill” to use “black” as text color.
• “align” and “middle” to center text.
• “text” to set the text to the “total_jvm” value

These last lines allow us to arrive at the final version of our visualization:

We were thus able to create a step-by-step visualization with data from Elasticsearch from several data sources, and fully customized to best meet our needs.

This requires a little practice but the result is rather interesting. However, be careful: when you are looking for resources on the Internet, you can find some related to Vega and some others related to Vega-Lite. Kibana supports both, but some features are missing or different between the two.

Create a nice bar chart in Kibana Vega step by step from Elasticsearch data was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kibana Custom visualization : Vega

One solution is to use Kibana’s Custom visualizations, such as Vega, which allows you to use multiple data sources from static data or Query DSL queries. In the latter case, it can be difficult to exploit the result, the structure is not a simple table but a fairly complex JSON, especially when using aggregations.

In this article, we will see how to create several data sources in Vega, but above all how to transform them to have something simple as an output (table) containing all the relevant information that we want to display.

Example based on Monitoring metrics

To discuss the necessary steps, we will take an example based on data known by Elasticsearch users, namely the data contained in .monitoring-es-*. These indices contain all the metrics needed to monitor the different clusters managed by a team/company.

We will start with a simple example, namely, to sum up the total amount of JVM by tier, and this, for each cluster (environment) that we manage. These clusters are managed in Elastic Cloud and are therefore defined by a UUID.

The tiers are:

• Hot
• Warm (not used in our case)
• Cold
• Frozen

The managed environments are:

• Production
• PréProduction (Pre-Production)
• Recette (Staging)
• Intégration (Integration)
• Monitoring

Creating the main query

Defining the main Query DSL

Our main query DSL will aim to retrieve the total JVM memory by cluster (cluster_uuid) and role, from the data in the node_stats dataset. A role can contain several nodes and the metric used to obtain the JVM is at the node level, so we must go down to the node level and then sum this JVM for all nodes in the same role, which gives:

POST /.monitoring-es-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "event.dataset": "elasticsearch.node.stats"
          }
        }
      ]
    }
  }, 
  "aggs": {
    "cluster": {
      "terms": {
        "field": "cluster_uuid",
        "size": 10
      },
      "aggs": {
        "role": {
          "terms": { 
            "field": "elasticsearch.node.roles",
            "include": "data_.*",
            "exclude": "data_content",
            "min_doc_count": 0
          },
          "aggs": {
            "node": {
              "terms": {
                "field": "elasticsearch.node.name",
                "size": 10
              },
              "aggs": {
                "max_jvm": {
                  "max": {
                    "field": "elasticsearch.node.stats.jvm.mem.heap.max.bytes"
                  }
                }
              }
            },
            "sum_jvm": {
              "sum_bucket": {
                "buckets_path": "node>max_jvm" 
              }
            }
          }
        }
      }
    }
  }
}

To make it easier to read, we can filter the output by using the “filter_path” attribute:

POST /.monitoring-es-*/_search?filter_path=aggregations,-**.doc_count,-**.doc_count_error_upper_bound,-**.sum_other_doc_count,-**.node

This will only keep the data useful for the rest by removing any superfluous and intermediate fields in the calculation of the JVM by tier.

This query therefore gives in output:

{
  "aggregations": {
    "cluster": {
      "buckets": [
        {
          "key": "PDIJyZMaSQOtFB2LEz9kwA",
          "role": {
            "buckets": [
              {
                "key": "data_hot",
                "sum_jvm": {
                  "value": 47764733952
                }
              },
              {
                "key": "data_cold",
                "sum_jvm": {
                  "value": 31893487616
                }
              },
              {
                "key": "data_frozen",
                "sum_jvm": {
                  "value": 15921577984
                }
              }
            ]
          }
        },
        {
          "key": "fN5Y2U2HRsK1HKw1X_H77A",
          "role": {
            "buckets": [
              {
                "key": "data_hot",
                "sum_jvm": {
                  "value": 5876219904
                }
              },
              {
                "key": "data_cold",
                "sum_jvm": {
                  "value": 884998144
                }
              },
              {
                "key": "data_frozen",
                "sum_jvm": {
                  "value": 0
                }
              }
            ]
          }
        },
        {
          "key": "ARezM52EQhGoxHoFJrm1oA",
          "role": {
            "buckets": [
              {
                "key": "data_hot",
                "sum_jvm": {
                  "value": 5876219904
                }
              },
              {
                "key": "data_cold",
                "sum_jvm": {
                  "value": 0
                }
              },
              {
                "key": "data_frozen",
                "sum_jvm": {
                  "value": 0
                }
              }
            ]
          }
        },
        {
          "key": "OtrL3B00RsuFpcOVCAQ08Q",
          "role": {
            "buckets": [
              {
                "key": "data_hot",
                "sum_jvm": {
                  "value": 15728640000
                }
              },
              {
                "key": "data_cold",
                "sum_jvm": {
                  "value": 0
                }
              },
              {
                "key": "data_frozen",
                "sum_jvm": {
                  "value": 0
                }
              }
            ]
          }
        },
        {
          "key": "erIavvd3TG6naKWwGag2TQ",
          "role": {
            "buckets": [
              {
                "key": "data_hot",
                "sum_jvm": {
                  "value": 884998144
                }
              },
              {
                "key": "data_cold",
                "sum_jvm": {
                  "value": 884998144
                }
              },
              {
                "key": "data_frozen",
                "sum_jvm": {
                  "value": 0
                }
              }
            ]
          }
        }
      ]
    }
  }
}

we realize that it is not easy to exploit the result JSON to create a visualization..

Integrating the main query into a Vega datasource

Let’s now integrate our Query DSL into a Vega datasource. We will therefore use the data section, respecting the Vega syntax:

• give a name to the datasource in order to be able to use it later in the creation of our visualization or debug it easily
• in the url part, specify the query and the body with the associated parts of our Query DSL
• set the format to make it easier to access fields in the resulting JSON
• prepare the transform attribute for future transformations

Which gives:

{
      "name": "jvm",
      "url": {
        "%context%": true,
        "%timefield%": "@timestamp",
        "index": ".monitoring-es-*",
        "query": {
          "bool": {
            // ...
          }
        }, 
        "body": {
          "aggs": {
            // ...
          },
          "size": 0
        }
      }
      "format": {"property": "aggregations.cluster.buckets"}
      "transform": [

      ]
    }

Debugging the data source in Vega

Kibana provides very handy inspection and debugging tools for Vega. Everything is done through the Inspect button in the toolbar.

The inspection pane provides 2 distinct views:
- View: Requests to visualize requests, responses and statistics on DSL requests
- View: Vega debug to inspect datasources as they are implemented

It is the latter that will interest us:

As we have set up a format, we see that it has been taken into account since we start to see the data from the sub-attribute “aggregations / cluster / buckets”. The first column displayed (“key”) is none other than the key of our highest level aggregation: “cluster”, therefore, the cluster_uuid. The second column indicates the number of documents that allowed the calculation of this aggregation and the last one is a JSON representing the value of our aggregation, i.e. the buckets from the sub-aggregations.

Transforming the main data source to make it usable

Contextualization of cluster information

The cluster UUID is a good starting point to know which cluster it is, but when displaying, we will prefer to have a cluster name which will provide the associated environment and perhaps also a clue allowing us to order our clusters according to an order of importance.

To do this, we will add a new static data source with the information allowing us to complete the missing information and make the link with our UUID:

{
      "name": "clusters",
      "values": [
        {"uuid": "erIavvd3TG6naKWwGag2TQ", "id": 1, "name": "Monitoring"}, 
        {"uuid": "OtrL3B00RsuFpcOVCAQ08Q", "id": 2, "name": "Recette"}, 
        {"uuid": "fN5Y2U2HRsK1HKw1X_H77A", "id": 3, "name": "Intégration"}, 
        {"uuid": "ARezM52EQhGoxHoFJrm1oA", "id": 4, "name": "PréProduction"}, 
        {"uuid": "PDIJyZMaSQOtFB2LEz9kwA", "id": 5, "name": "Production"}
      ]
}

We will now integrate the fields that interest us directly into our initial data source (jvm), using a transformation. To do this, we will use the lookup transformation:

{
    "type": "lookup",
    "from": "clusters",
    "key": "uuid",
    "fields": ["key"],
    "values": ["id", "name"],
    "as": ["cluster_id", "cluster_name"]
}

This transformation will use the “clusters” datasource, which key is the “uuid” field, make it correspond to the key of our current data source (“jvm”) which is the “key” field, and use this new data source to add the 2 fields named “id” and “name” to our current datasource with the specified names “cluster_id” and “cluster_name”.

At this step, the jvm dataset becomes the following:

Flattening tier data (roles)

We will now simplify the representation of the roles associated with each environment (cluster) by flattening the data, therefore, creating one line per output role (and this for each cluster). This can be done very easily using a flatten transformation:

{
  "type": "flatten", 
  "fields": ["role.buckets"],
  "as" : ["role"]
}

We use the field buckets (resulting of the aggregation) of the role column to flatten the data and erase the previous value of the column as we keep the same name in the “as” parameter:

The role colum now has this kind of value:

{
  "key": "data_hot",
  "doc_count": 25933,
  "node": {
    "doc_count_error_upper_bound": 0,
    "sum_other_doc_count": 0,
    "buckets": [
      {
        "key": "instance-0000000031",
        "doc_count": 8649,
        "max_jvm": {
          "value": 15921577984
        }
      },
      {
        "key": "instance-0000000029",
        "doc_count": 8646,
        "max_jvm": {
          "value": 15921577984
        }
      },
      {
        "key": "instance-0000000030",
        "doc_count": 8638,
        "max_jvm": {
          "value": 15921577984
        }
      }
    ]
  },
  "sum_jvm": {
    "value": 47764733952
  }
}

Retrieving the JVM metric for each cluster / role

Now that we have one line per cluster and role as output, we will be able to easily access the field that interests us from a metric point of view “sum_jvm” (at the end of each role value) and rework it to convert it from bytes to Gb.

To do such a conversion, we will use the formula transformation:

{
  "type": "formula", 
  "as": "total_jvm", 
  "expr": "ceil(datum.role.sum_jvm.value / 1024 / 1024 / 1024)"
}

We create a new field named “total_jvm”, using the expression “expr”, ie, for each row, we use the current (“datum”) value field “role.sum_value.value”, convert it to Gb and rounded it, which now gives:

Keep only role name in the role column

As the remaining buckets per node in the role is just here to made it able to calculate the sum of JVM by role, we won’t use them further, so we can replace it by only the name of the role by also using a formula transformation:

{
  "type": "formula", 
  "as": "role", 
  "expr": "datum.role.key"
}

This formula will take each line of results, and apply the expression, so set the role value to the current role.key field, is the role name.

We now have a nice and usable output to be able to process it in a beautiful and easy Vega visualization.

Latest improvement for the order of roles

In the same way that we added a data source for clusters to easily order them in our future visualization, we will do the same for roles because we want to be able to order them in a logical order.

Let’s add a new data source for roles:

{
  "name": "roles",
  "values": [
    {"id": 1, "name": "data_hot"}, 
    {"id": 2, "name": "data_warm"}, 
    {"id": 3, "name": "data_cold"}, 
    {"id": 4, "name": "data_frozen"}
  ]
}

We then use the same kind of lookup transformation to add a new role_id field, with an ordering value:

{
  "type": "lookup",
  "from": "roles",
  "key": "name",
  "fields": ["role"],
  "values": ["id"],
  "as": ["role_id"]
}

The final result is the following one:

A little simpler to exploit than our initial JSON, right?

Conclusion about transformations in Kibana Vega

When using Vega in a Kibana context, ie using Query DSL to retrieve Elasticsearch data, the resulting output is not always easy to manipulate. Therefore, we may need to query multiple indices or merge information in other static data sources to get all information.

In these cases, transformations are a good way to adapt the output to better exploit the data in visualizations.

Take care that transformations are applied by Kibana, so on client side !

In a further article, we will create a Vega visualization based on the previous transformed data. Stay tune !

Using transformations in Kibana Vega to adapt data from query DSL was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tu ajoutes @SpringBootApplication, tu lances ton projet… et tout fonctionne.

Connexion à la base de données ✔
Serveur web ✔
Injection de dépendances ✔

Mais c’est quoi cette magie 😲?

Dans un premier temps, nous allons voir comment se faisait la configuration avant Spring Boot et dans un second temps nous allons décortiquer l’auto-configuration de Spring Boot. C’est ok ? Let’s go !

1. C’était comment la vie avec Spring Framework sans Spring Boot ?

Lorsqu’on développe une application web on a différents besoins. Souvent ils concernent : communiquer avec une base de données et gérer des requêtes serveur. Pour cela, on va configurer ces moyens de communication soit via des fichiers xml soit via des beans (objets java gérés par spring).

Par exemple pour configurer un accès à la base de données via des beans on pourrait avoir (cas simple) :

a) le DataSource

C’est un objet qui contient l’URL, les identifiants de connexion à la base de données , et le pool de connexions.

@Bean
    public DataSource dataSource() {
        DriverManagerDataSource ds = new DriverManagerDataSource();
        ds.setDriverClassName("com.mysql.cj.jdbc.Driver");
        ds.setUrl("jdbc:mysql://localhost:3306/testdb");
        ds.setUsername("root");
        ds.setPassword("password");
        return ds;
    }

b) le EntityManagerFactory

Cet objet sert à instancier un EntityManager qui fait la liaison entre les objets Java (entités) et les tables de la base de données. Il prend DataSource en paramètre.

@Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
        LocalContainerEntityManagerFactoryBean emf =
                new LocalContainerEntityManagerFactoryBean();
        emf.setDataSource(dataSource());
        emf.setPackagesToScan("com.example.entity");
        HibernateJpaVendorAdapter vendorAdapter =
                new HibernateJpaVendorAdapter();
        emf.setJpaVendorAdapter(vendorAdapter);
        return emf;
    }

c) un Transaction Manager

Il sert à effectuer les opérations sur la base de données dans le cadre de transactions. Il prend EntityManagerFactory en paramètre.

@Bean
public PlatformTransactionManager transactionManager(
            EntityManagerFactory emf) {
        JpaTransactionManager transactionManager =
                new JpaTransactionManager();
        transactionManager.setEntityManagerFactory(emf);
        return transactionManager;
    }

La configuration complète pour communiquer avec la base de données pouvait donc ressembler à ça :

@Configuration
@EnableTransactionManagement
@EnableJpaRepositories(basePackages = "com.example.repository")
public class PersistenceConfig {

    @Bean
    public DataSource dataSource() {
        DriverManagerDataSource ds = new DriverManagerDataSource();
        ds.setDriverClassName("com.mysql.cj.jdbc.Driver");
        ds.setUrl("jdbc:mysql://localhost:3306/testdb");
        ds.setUsername("root");
        ds.setPassword("password");
        return ds;
    }

    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
        LocalContainerEntityManagerFactoryBean emf =
                new LocalContainerEntityManagerFactoryBean();
        emf.setDataSource(dataSource());
        emf.setPackagesToScan("com.example.entity");
        HibernateJpaVendorAdapter vendorAdapter =
                new HibernateJpaVendorAdapter();
        emf.setJpaVendorAdapter(vendorAdapter);
        return emf;
    }

    @Bean
    public PlatformTransactionManager transactionManager(
            EntityManagerFactory emf) {
        JpaTransactionManager transactionManager =
                new JpaTransactionManager();
        transactionManager.setEntityManagerFactory(emf);
        return transactionManager;
    }
}

Il fallait aussi configurer soi-même la servlet principale qui gère les requêtes : la DispatcherServlet. Cette servlet est chargée de router les requêtes du serveur vers le contrôleur adéquat.

Un exemple de configuration de la DispatcherServlet.

public class WebAppInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext container) throws ServletException {

        AnnotationConfigWebApplicationContext context =
                new AnnotationConfigWebApplicationContext();
        context.register(WebConfig.class, PersistenceConfig.class);

        ServletRegistration.Dynamic dispatcher =
                container.addServlet("dispatcher", new DispatcherServlet(context));
        dispatcher.setLoadOnStartup(1);
        dispatcher.addMapping("/");
    }

On devait donc écrire tout ce code même dans les cas les plus simples. C’était lourd, fastidieux et complexe ❌.

2. Spring Boot fait le travail tout seul

Il est important de comprendre que l’auto-configuration de spring boot ne vient pas annuler ou remplacer la configuration vue précédemment. Elle reste nécessaire. Cependant, l’auto-configuration vient déclarer ces beans automatiquement en suivant certaines règles.

Voyons ça étape par étape 🔎

1️⃣ Etape I : @SpringBootApplication : le point d’entrée

C’est l’annotation qui définit un projet spring boot. Elle est présente dans la classe principale là ou se trouve la méthode main. Par exemple :

@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}

Cette annotation est un alias pour 3 autres annotations. C’est à dire qu’en écrivant @SpringBootApplication en réalité on déclare les 3 annotations suivantes :

🔸@SpringBootConfiguration : elle indique que la classe est une classe de configuration qui peut contenir des beans.

🔸@ComponentScan : elle détermine les packages qui vont être scannés au démarrage de spring. Le but étant d’enregistrer les BeanDefinition des classes annotées @component, @service, @repository, @configuration dans la BeanFactory. Un BeanDefinition est un “plan” qui sert à construire un Bean. Un peu comme une classe avec un objet.

🔸@EnableAutoConfiguration : C’est ELLE qui nous intéresse. Au démarrage cette annotation réalise l’import de la classe AutoConfigurationImportSelector.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import({AutoConfigurationImportSelector.class})// <=== 👈 Importation ICI 👈
public @interface EnableAutoConfiguration {
    String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";

    Class<?>[] exclude() default {};

    String[] excludeName() default {};
}

2️⃣ Etape II :AutoConfigurationImportSelector va lire un fichier qui contient la liste des classes d’auto-configuration

A une certaine étape dans le processus de démarrage, AutoConfigurationImportSelector va lire un fichier qui contient la liste des classes d’auto-configuration.

Hein ? Qui? quoi? quel fichier listant quelles classes d’auto-configuration?

Je t’explique 👇

chaque dépendance dans ton pom.xml (ou gradle.build) est ajoutée au classpath de l’application. Spring boot vient avec une dépendance un peu spéciale qui s’appelle spring-boot-autoconfigure.

Cette dépendance contient un fichier AutoConfiguration.imports dans son dossier META-INF. Le chemin complet est le suivant : META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

Ce fichier AutoConfiguration.imports contient une liste de classes d’autoconfiguration. Ces classes sont déjà déclarées et configurées avec des propriétés par défaut.

org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration
org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration
org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration
org.springframework.boot.autoconfigure.context.ConfigurationPropertiesAutoConfiguration
....
....

AutoConfigurationImportSelector va donc lire ce fichier et enregistrer les classes d’autoconfiguration. Il ne crée ni les BeanDefinition de ces classes, ni les bean eux mêmes. Il ne fait QUE enregistrer ces classes comme “des classes potentielles à utiliser pour autoconfigurer l’application”.

📄AutoConfigurationImportSelector retourne une liste de classes
🔄ConfigurationClassParser les lit en profondeurs pour détecter les annotations à l’intérieur de ces classes.
🔄ConfigurationClassBeanDefinitionReader crée les BeanDefinition

🔄 ApplicationContext active ou non les classes de configuration

Les BeanDefinition des classes sont créées et enregistrées dans BeanFactory. Mais ce n’est pas pour autant qu’elles seront activées.

En effet, chaque classe d’auto-configuration contient des conditions d’activation. Si les conditions sont remplies, le BeanDefinition de la classe est utilisé pour effectivement créer le bean. Sinon, le bean n’est pas crée et l’autoconfiguration portée par cette classe n’est pas prise en compte dans l’application.

4️⃣ Un exemple concret : WebMvcAutoConfiguration

Une des classes qu’on retrouve dans AutoConfigure.imports est WebMvcAutoConfiguration. Elle configure automatiquement Spring MVC.

En lisant le fichier AutoConfigurationImportSelector va enregistrer cette classe (et toutes les autres) comme une autoconfiguration possible.

Une fois que toutes les classes sont enregistrées par AutoConfigurationImportSelector et que ApplicationContext a crée les BeanDefinition qui correspondent, vient alors le moment d’activer (créer le bean) ou de ne pas activer (ne pas créer le bean) de chaque BeanDefinition.

L’activation dépend des conditions décrites dans la classe elle-même. Ci-après le code de classe WebMvcAutoConfiguration.

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class })
@ConditionalOnWebApplication(type = Type.SERVLET)
public class WebMvcAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    public RequestMappingHandlerAdapter requestMappingHandlerAdapter() {
        return new RequestMappingHandlerAdapter();
    }

}

Le bean est crée si les conditions suivantes sont remplies:

• ✅ @ConditionalOnClass 👉 les classes Servlet, DispatcherServlet et WebMvcConfigurer sont présentes dans le classpath
• ✅ @ConditionalOnWebApplication👉 l’application est de type SERVLET (pour info le type d’application est déduite automatiquement au démarrage)
• ✅ @ConditionalOnMissingBean 👉 il n’existe pas déjà un bean RequestMappingHandlerAdapter.

Si les conditions sont réunies un bean RequestMappingHandlerAdapter est automatiquement crée et utilisé par spring boot sans que tu n’aies à faire quoi que ce soit. Magique 🌟

3. En résumé

1️⃣ @SpringBootApplication active @EnableAutoConfiguration
2️⃣ @EnableAutoConfiguration importe AutoConfigurationImportSelector
3️⃣ AutoConfigurationImportSelector lit AutoConfiguration.imports
4️⃣ Les classes d’auto-configuration sont chargées et les conditions (@ConditionalOnClass, @ConditionalOnMissingBean) décident quels beans créer

👉 Résultat : Spring Boot configure ton application automatiquement.

Si cet article t’a plu, n’hésite pas à me suivre pour plus de contenu sur Java et Spring Boot 👋.

L’auto-configuration Spring Boot expliquée : La Magie Derrière @SpringBootApplication was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Si la “Developer eXperience” (DX) est en perpétuelle amélioration, l’intelligence artificielle générative bouscule actuellement les paradigmes de développement. Des outils comme Firebase Studio (cf annonce faite par Google) ont déjà introduit la puissance de l’IA dans les Cloud Development Environment (CDE) pour assister les développeurs·euses dans la création d’interfaces, la génération de code et l’intégration de services.

Mais Google a déjà préparé l’étape suivante : l’arrivée des agents dans le monde du développement avec Google Antigravity. Lancée en novembre 2025, cette nouvelle plateforme vise à redéfinir la façon dont nous interagissons avec les agents.

Premiers pas avec Antigravity : Installation et Configuration

Google Antigravity est une nouvelle plateforme de développement « agentique ». La promesse : l’IA ne se contente plus de suggérer des lignes de code, mais elle prend le clavier, pilote l’éditeur, le terminal et le navigateur.

Antigravity s’appuie principalement sur les modèles Gemini. Toutefois, la plateforme est construite pour la flexibilité des modèles incluant le support pour Claude Sonnet 4.5 et Claude Opus 4.5 d’Anthropic ainsi queGPT-OSS d’OpenAI.

L’installation d’Antigravity s’effectue rapidement à partir d’un package téléchargeable sur votre machine (Windows, Mac ou Linux) : https://antigravity.google/download. Actuellement en preview, Antigravity est accessible publiquement avec une limite dans les quotas d’utilisation des modèles (cf https://antigravity.google/pricing).

Une fois installé, une courte phase de configuration permet de définir le comportement des agents avec quelques options. Antigravity vous propose 4 modes de fonctionnement prédéfinis :

• Développement piloté par agent (Agent-driven development)
• Développement assisté par agent (Agent-assisted development)
• Développement piloté par les avis (Review-driven development)
• Configuration personnalisée (Custom configuration)

Ces profils sont des préréglages des options présentes sur la partie droite de l’écran, que vous pouvez ajuster manuellement si elles ne vous conviennent pas. Vous pourrez également les modifier par la suite à tout moment dans les préférences d’Antigravity, avec la possibilité d’ajouter des commandes autorisées ou interdites par les agents.

Ces options consistent à configurer l’autonomie des agents dans l’exécution, avec ou sans votre validation humaine, de commandes dans le terminal, de commandes Javascript ou pour valider les revues.

La Rupture : L’IDE Agentique vs. L’Assistance Classique

Avec les IDEs classiques, l’IA restait limitée à des rôles d’assistance, comme la complétion de lignes, des suggestions de changement dans le code, ou les réponses dans un chat latéral. Les développeurs·euses devaient attendre que l’IA ait fini de générer du code avant de poser la question suivante. L’approche agentique change la donne. Désormais les agents intègrent leurs modifications dans nos fichiers avec ou sans notre approbation.

Avec Antigravity, la logique est celle de la délégation : la mission est confiée, l’IA effectue la majeure partie du travail. L’IA n’est plus seulement un outil d’écriture de code, mais un acteur autonome capable de planifier, d’exécuter, de valider et d’itérer sur des tâches complexes

Google Antigravity : IDE Agent-First

Antigravity articule son expérience utilisateur autour de deux vues principales distinctes. En plus d’avoir sa vue de développement comme tout IDE, la nouveauté réside dans l’apparition d’un écran de supervision des interactions avec les agents, l’Agent Manager.

Le Gestionnaire d’Agents (Agent Manager)

Le Gestionnaire d’Agents (ou Agent Manager) est un tableau de bord où le·la développeur·euse agit en tant qu’architecte. Il peut :

• Déléguer, orchestrer et surveiller plusieurs agents travaillant de manière asynchrone sur différentes tâches (exemples : refactoriser le module d’authentification, mettre à jour l’arborescence des dépendances, générer une suite de tests pour une API).
• Visualiser l’état de chaque agent, les artefacts produits et les demandes d’approbation humaine en attente.

Cette architecture permet à un développeur de déléguer jusqu’à cinq agents différents pour travailler sur cinq bugs différents simultanément.

Les artefacts

Déléguer des tâches complexes nécessite une certaine confiance envers l’agent ainsi que la nécessité de vérifier facilement le travail produit. Antigravity résout ce problème en exigeant des agents qu’ils génèrent des “artefacts“.

Un artefact peut être :

• Un plan d’implémentation détaillé.
• Les “diffs” de code standardisés montrant les lignes exactes qui seront modifiées.
• Des captures d’écran de l’UI (avant et après une modification).
• Des enregistrements d’écran de navigateur pour vérifier que les exigences fonctionnelles sont respectées lors des interactions.
• Des journaux structurés des résultats de tests (réussis/échoués).

Ces artefacts sont interactifs : si un élément semble incorrect, il est possible de laisser un commentaire directement sur l’artefact et l’agent intégrera ce retour pour itérer sans interrompre son flux d’exécution.

Un navigateur embarqué pour les tests automatisés

Un élément différenciateur est la capacité des agents à lancer un navigateur embarqué, Google Chrome, pour interagir avec des pages Web. Ces agents ont accès à une variété d’outils leur permettant de cliquer, faire défiler, taper, lire les logs de la console et même prendre des vidéos de leurs actions.

Cette capacité permet aux agents de démarrer l’application localement, d’ouvrir un serveur et d’exécuter un scénario utilisateur complet (comme tester une nouvelle fonctionnalité ou reproduire un bug). L’utilisateur·trice est notifié·e lorsque l’agent prend le contrôle, souvent par une bordure bleue visible autour de la fenêtre du navigateur. L’enregistrement de toutes les actions est disponible dans les artefacts, permettant de vérifier la logique fonctionnelle d’un simple coup d’œil.

Lors de la première configuration d’Antigravity et de son browser, une fenêtre Google Chrome s’ouvre vous demandant d’installer l’extension “Antigravity Browser Extension” disponible ici https://chromewebstore.google.com/detail/antigravity-browser-exten/eeijfnjmjelapkebgockoeaadonbchdd.

Un changement d’état d’esprit

Au-delà de la nouveauté technique, Antigravity amène un changement de paradigme dans les équipes de développement.

Habituellement concentré sur le développement d’une fonctionnalité ou de la résolution d’un incident, l’aspect agentique permet de déléguer aux agents plusieurs tâches en parallèle.

La partie « Inbox » centralise le suivi des agents et de leurs discussions. Les développeurs•euses doivent s’habituer à regarder cette « nouvelle boîte de réception » pour observer les notifications informant de la fin de traitement d’un agent et contrôler le résultat des traitements des autres agents. Cela amène un important « context switching » qui peut être nouveau et déstabilisant. Une gymnastique devra être à appréhender pour orchestrer ces tâches exécutées en arrière-plan tout en étant concentré sur l’architecture et les éléments de développement sur lesquels nous voulons garder la main.

Rules, workflow et customisation

Antigravity est personnalisable grâce aux “Rules” et “Workflows” qui permettent d’adapter le comportement des agents à vos habitudes de travail. Les “Rules” guident le comportement des agents avec des consignes que vous pouvez leur donner. Ces règles peuvent être enregistrées dans le répertoire .agent/rules/ de votre projet ou dans le fichier ~/.gemini/GEMINI.md et précisent vos attentes en termes de code, de tests ou l’utilisation de librairies sans avoir à les répéter dans chaque conversation. Par exemple, vous pouvez définir une règle spécifiant que tous les composants React doivent être fonctionnels ou bien que le handler de l’API HTTP ne doit jamais appeler la couche ORM directement.

Les “workflows” sont quant à eux des commandes personnalisées que vous utilisez fréquemment et qui pourront être exécutés rapidement. Ces commandes peuvent être enregistrées dans le répertoire .agent/workflows/ de votre projet ou bien à la racine de votre compte utilisateur dans le fichier ~/.gemini/antigravity/global_workflows/global-workflow.md. Un exemple de workflow pourrait être de demander de générer des tests unitaires sur le code ajouté sur cette branche de développement.

Les Model Context Protocol (MCP), utilisés dans les assistants IA pour faciliter les liens avec des services tiers, sont intégrables dans Antigravity. Une liste de MCP pré-configurée vous permet de rapidement en ajouter à votre projet. Les MCP absents de cette liste peuvent également être ajouté en éditant (ou créant) le fichier mcp.json.

Une fois configuré, vous avez la main sur l’activation ou désactivation des services des MCP configurés.

Complément ou futur de Firebase Studio ?

Antigravity n’est pas le seul à proposer une plateforme agentique pour développer des applications. Cursor est une alternative qui propose un contexte équivalent et qui est assez connue et répandue. GitLab Duo propose également une solution de développement agentique qui va cependant plus loin en intégrant des agents dans toute sa plateforme DevOps.

Dans de précédentes conférences, nous soulignions les fonctionnalités d’IA de Firebase Studio, notamment dans le prototypage et l’intégration cloud. Avec l’arrivée de la plateforme Antigravity, qui introduit un changement de paradigme vers le développement « agentique », on peut légitimement se demander si l’approche d’assistance de Firebase Studio est remise en cause.

L’atout principal de Firebase Studio réside dans la rapidité de réalisation de prototypages transformant une simple intention en un plan d’action avec des guidelines graphiques, un déploiement simple et rapide sur les services Google Cloud et le tout depuis votre navigateur. L’exécution n’a pas lieu sur votre ordinateur mais sur la plateforme Cloud de Google (GCP).

Google Antigravity, quant-à lui, exécute votre projet en local et l’IA n’est plus un assistant, mais un acteur autonome capable de piloter l’éditeur, le terminal et un navigateur embarqué. Sa force réside dans la délégation de tâches complexes de bout en bout, comme le refactoring d’un module ou la génération d’une suite de tests complète. Avec son navigateur, Antigravity peut tester lui-même son code et générer un compte rendu de ses actions. Son gestionnaire d’agents permet l’orchestration asynchrone de plusieurs agents travaillant en parallèle.

Firebase Studio est l’outil idéal pour l’entrée en matière et le déploiement rapide d’un PoC dans le cloud, tandis qu’Antigravity prend le relais pour du travail complexe en arrière-plan.

👉 Article écrit avec Jean-Philippe Baconnais 🙌

Google Antigravity : l’ère des IDE Agentique was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comme chaque année (2023 et 2024), je fais le point sur les avancées de Google Cloud sur le Web3. En 2025, ce domaine est également concerné par l’arrivée de l’Intelligence Artificielle (IA). Le géant du cloud mise désormais sur la convergence entre la blockchain et l’IA. De l’infrastructure aux agents autonomes, en passant par les paiements programmables, Google étend son empreinte bien au-delà des simples services de nœuds.

🤖 Des agents IA connectés à la blockchain

L’un des temps forts de l’année est la publication par Google d’un guide complet pour créer des « Web3 AI agents », des agents autonomes capables d’interagir directement avec des smart-contracts et des données « on-chain ». S’appuyant sur Vertex AI Agent Engine et Agent Development Kit (ADK), ces agents peuvent lire des transactions, exécuter des contrats et gérer des flux en toute autonomie.

👉 Lire l’article officiel sur le blog Google Cloud

Google ne se contente plus de fournir des outils d’accès à la blockchain, il devient un acteur du Web3 intelligent, où les IA ne sont plus seulement “off-chain” mais véritablement connectées à l’écosystème décentralisé. Les agents deviennent des entités économiques à part entière, capables d’échanger, d’apprendre et d’agir dans un écosystème numérique interconnecté et sécurisé.

🏦 Stablecoins et “Universal Ledger” : Google veut sa propre infrastructure de paiement

L’annonce la plus stratégique de 2025 reste toutefois la mise en avant d’un protocole de paiement pour agents IA, appuyé sur les stablecoins ainsi que sa propre blockchain maison baptisée Google Cloud Universal Ledger. GCUL ne reposerait pas sur l’Ethereum Virtual Machine (EVM) mais plutôt sur une infrastructure indépendante avec des smart contracts écrits en Python. Selon Rich Widmann, responsable Web3 chez Google Cloud, GCUL est conçue pour être une plateforme stable, flexible, conforme aux réglementations et « crédiblement neutre », dédiée aux paiements institutionnels et les cas d’usage IA-to-IA.

Cette initiative rapproche Google des acteurs comme Stripe et Circle, tout en renforçant son positionnement face à des besoins émergents : permettre à des agents autonomes d’effectuer des transactions stables, traçables et programmables.

👉 Article du Journal du Coin sur le protocole de paiement IA

👉 Article du Journal du Coin sur GCUL

👉 Cryptoast — Google construirait sa propre blockchain

👉 CryptoDNES — Google Cloud lance sa blockchain pour concurrencer Stripe et Circle

🌐 Un écosystème Web3 en expansion

En parallèle, Google Cloud a multiplié les partenariats dans l’écosystème blockchain, confirmant sa volonté de ne pas rester seul fournisseur mais de jouer un rôle de catalyseur :

• Collaboration avec Lava Network autour de la “future économie autonome”, mêlant IA et blockchain. 👉 Article sur Cryptopolitan
• Partenariat avec Etherlink pour renforcer les outils de développement Web3 et améliorer les performances des infrastructures décentralisées. 👉 Source Phemex News
• Coopérations avec des projets blockchain pour stimuler l’innovation Web3 à l’échelle mondiale. 👉 Article de CryptoDnes

Ces alliances traduisent une stratégie pragmatique : favoriser un écosystème performant plutôt qu’un modèle fermé, tout en s’assurant que les briques critiques, données, IA, paiements, passent par Google Cloud.

Ce qu’il faut retenir

En résumé, voici les quelques pistes à explorer en priorité :

• Expérimenter les architectures d’agents IA connectés à la blockchain : les tutoriels et SDK proposés par Google facilitent les prototypes. Il y a d’ailleurs un codelab ici ou encore un exemple là.
• Surveiller de près Google Cloud Universal Ledger et les initiatives de paiement stablecoin : elles pourraient transformer la manière dont les agents IA échangent de la valeur.
• Garder un œil sur la gouvernance et la neutralité : plus Google s’implique dans l’infrastructure financière on-chain, plus la question de la “neutralité crédible” deviendra importante.

Conclusion

En 2025, Google Cloud franchit une nouvelle étape : du simple accès à la blockchain à la création d’une infrastructure complète pour les agents intelligents et les paiements programmables. Avec ses nouveaux outils, ses partenariats stratégiques et ses ambitions dans les paiements, le cloud de Google devient un acteur structurant de la convergence Web3 × IA.

Les clouds de demain seront-ils « on-chain et intelligents ».

Rendez-vous en 2026 !

Web3 : Le bilan de Google Cloud sur la blockchain en 2025 was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Google Cloud continue de renforcer sa présence dans l’écosystème blockchain, avec des innovations technologiques, des partenariats stratégiques, et une volonté affichée de démocratiser le Web3.

Tour d’horizon des initiatives marquantes pour cette année 2024

Un nouveau portail Web3, enrichi et consolidé

En Avril 2024, Google Cloud a lancé un portail dédié au Web3, centralisant outils et ressources pour les développeurs, entreprises et startups.

Ce portail propose une gamme complète d’outils et de services, structurée autour de plusieurs axes majeurs :

• L’onglet « Discover » : Tous les produits que Google Cloud et la communauté ont conçus pour les développeurs avec des outils dédiés à l’infrastructure, du data warehousing, de l’analytics pour l’analyse des données blockchain, etc. De nombreux réseaux blockchain sont supportés : Ethereum Mainnet et Goerli, Arbitrum, Avalanche, Cronos, Fantom, etc.
• L’onglet « Faucet »: Un espace permettant le déploiement et les tests sur les réseaux Ethereum (Sepolia et Holesky)
• L’onglet « Events »: Un espace regroupant tous les événements passés ou futurs autour du Web3 et de ses partenaires
• L’onglet « Learn »: Toutes les ressources pour vous former dans ce domaine. Vous pouvez retrouver des tutoriels vidéos tels que “Develop an NFT on Ethereum”, “Using Firebase with Web3Auth” ou encore “Secure Digital Assets with MPC”.
• L’onglet « Community »: Des liens vers des communautés et les réseaux supportés par Google Cloud
• L’onglet « Startup Program »: Un programme dédié aux startups Web3, proposant deux parcours distincts selon le stade de développement

Cette approche témoigne de la volonté de Google Cloud de démocratiser l’accès aux technologies Web3, même si certains outils restent encore très spécialisés pour le grand public.

SUI : Une collaboration centrée sur l’IA

L’une des collaborations majeures de l’année est celle avec SUI, une blockchain Layer 1 issue des travaux de l’équipe derrière les projets Libra et Diem de Facebook. En partenariat avec Mysten Labs, Google Cloud a travaillé sur plusieurs axes stratégiques :

• Analyse des données : l’intégration des données de la blockchain SUI dans BigQuery permettant aux développeurs d’accéder à des outils analytiques avancés pour la création de dApps.
• IA et sécurité : grâce à Vertex AI, entrainé sur le langage de programmation de smart-contract MOVE, SUI a développé des outils d’audit et de génération de code basés sur l’intelligence artificielle pour améliorer la sécurité et optimiser le développement.
• Amélioration de l’expérience utilisateur : la technologie zkLogin permet de combler certaines lacunes entre les applications traditionnelles (Web2) et décentralisées (Web3). Elle utilise des identifiants OAuth de Google et d’autres plateformes Web2 de confiance pour simplifier l’authentification sur les applications Web3 et les portefeuilles numériques.
• Infrastructure : la scalabilité de l’infrastructure Google Cloud garantit la performance du réseau SUI.

Amit Zavery, Vice-Président, General Manager et Responsable des plateformes chez Google Cloud, souligne :

« Nous nous engageons à soutenir l’innovation Web3 grâce à notre infrastructure cloud sécurisée et nos capacités en intelligence artificielle. »

Comme le rappelle également Evan Cheng, CEO et co-fondateur de Mysten Labs :

« La collaboration avec Google Cloud nous aide à propulser le développement d’expériences Web3 sécurisées, évolutives et centrées sur l’utilisateur. »

Ce partenariat illustre parfaitement la synergie entre l’expertise technologique de Google Cloud et l’innovation de SUI.

Une infrastructure RPC renforcée

Google Cloud a étendu ses capacités avec le lancement du service Blockchain Remote Procedure Call (RPC). Ce service offre des fonctionnalités clés :

• Compatibilité: Un support pour Ethereum mainnet et testnet
• Performance et accessibilité : jusqu’à 100 appels par seconde dans son niveau gratuit.
• Interopérabilité : compatible avec le protocole Ethereum JSON-RPC, facilitant son intégration dans des systèmes existants.
• Extension future : Google prévoit d’ajouter la prise en charge de nouveaux réseaux blockchain en 2025.

Un service RPC est essentiel pour interagir avec une blockchain. Il permet aux développeurs et aux applications de communiquer avec les nœuds du réseau blockchain en envoyant des requêtes et en recevant des réponses. Grâce à cette couche d’abstraction, les développeurs et les utilisateurs peuvent interagir facilement avec la blockchain sans devoir gérer la complexité technique sous-jacente, comme la synchronisation des nœuds ou le traitement des données brutes.

L’engagement de Google Cloud pour améliorer l’interaction avec les données blockchain a été salué, notamment par Kyle Quintal de 0xArc :

« Les offres RPC de Google Cloud offrent des temps de réponse rapides — exactement ce que vous attendez. »

Blockchain et gaming : GameStack et l’essor du Web3 dans les jeux

L’année 2024 a également vu un rapprochement entre Google Cloud et l’industrie du jeu vidéo via des partenariats comme celui avec Sequence. Cette plateforme tout-en-un pour le développement de jeux Web3 est désormais disponible sur Google Cloud Marketplace, facilitant l’intégration de technologies blockchain dans les jeux vidéo.

Les outils fournis incluent des Unity APIs et des fonctionnalités pour gérer portefeuilles, NFT et transactions. Sequence prend en charge toutes les blockchains EVM, y compris les Layers 1 et 2, ainsi que les Layers 3/App Chains.

Dai Vu, directeur général des programmes Marketplace et ISV GTM chez Google Cloud, a déclaré :

« Amener Sequence sur Google Cloud Marketplace aidera les clients à déployer, gérer et développer rapidement la plateforme de développement de jeux Web3 sur l’infrastructure de Google Cloud. Sequence peut désormais évoluer en toute sécurité et accompagner ses clients dans leur transformation numérique. »

Comme l’a expliqué Michael Sanders, cofondateur de Sequence :

« Nous nous sommes lancés sur Google Cloud Marketplace en tant que fournisseur d’infrastructure pour les jeux Web3, afin d’aider les développeurs à attirer, fidéliser et monétiser les joueurs tout en offrant des expériences de jeu disruptives. »

Un message fort contre la fraude

Google Cloud démontre également son engagement dans la sécurisation de l’écosystème Web3 en adoptant des mesures juridiques inédites. L’entreprise a engagé une action en justice contre un groupe ayant proposé des applications frauduleuses sur la plateforme Google Play pendant plusieurs années. Ces applications, qui promettaient des gains exceptionnels à ceux investissant dans les cryptomonnaies, ont en réalité permis de détourner des sommes considérables.

Pour la première fois, Google a choisi de poursuivre en justice les deux principaux instigateurs de cette fraude, en s’appuyant sur la loi RICO (Racketeer Influenced and Corrupt Organizations), habituellement utilisée dans des affaires de crime organisé. Cette initiative positionne Google comme pionnier parmi les entreprises technologiques dans l’utilisation de ce cadre juridique pour lutter contre les escroqueries.

Comme le souligne Halimah DeLaine Prado, avocat pour Google :

« Rien qu’en 2023, nous avons vu plus d’un milliard de dollars de fraudes et d’escroqueries aux cryptomonnaies aux États-Unis et ce dossier nous permet non seulement d’utiliser nos ressources pour protéger les utilisateurs, mais également de servir en quelque sorte de précédent aux futurs mauvais acteurs dont nous ne pouvons tolérer le comportement. »

La suite en 2025

En 2024, Google Cloud confirme son ambition de devenir un acteur majeur du Web3 en proposant une infrastructure complète et sécurisée. Entre innovations techniques, partenariats stratégiques et engagement contre la fraude, la plateforme pose les jalons d’un écosystème Web3 plus mature et accessible. Les développements à venir, notamment l’extension du support RPC à d’autres réseaux blockchain, laissent présager de nouvelles avancées significatives dans les mois à venir.

Rendez-vous l’année prochaine.

Web3 : Le bilan de Google Cloud sur la blockchain en 2024 was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dataproc and Dataproc Serverless are managed services on Google Cloud that allow you to run Apache Spark jobs. This article will highlight both their features and differences.

1- What is Dataproc?

Dataproc is a Google Cloud managed service designed to run Apache Spark and Hadoop jobs on virtual machine clusters. Creating, shutting-down, sizing, configuring, and scaling these clusters are the user’s responsibilities.

2- What is Dataproc Serverless

Dataproc Serverless runs Spark jobs without requiring the user to manage clusters. It automatically provisions resources, scales, and shuts down when the job is done.

So, Dataproc Serverless reduces operational overhead. It means you don’t have to worry about scaling the infrastructure and managing clusters and resources. It’s automatically handled by Google which saves time, effort, and cost, as you only pay for the resources used during job execution. Additionally this efficient scaling not only optimizes costs but also reduces environmental impact by minimizing idle resource consumption.

3- Difference between Dataproc and Dataproc Serverless

For more details about the tuning parameters, you can consult the Google official documentation.

https://cloud.google.com/dataproc-serverless/docs/concepts/properties

4-Cost Considerations

As we mentioned before the pricing model is different for both services.

Pricing model:

• Dataproc (Cluster-based): the cost includes virtual machines (VMs) running in the cluster; master and worker nodes even when idle.
• Dataproc Serverless: You pay only for the resources consumed during job execution (vCPUs, memory, and storage), making it more cost-efficient for on-demand workloads.

Operational Costs

• Dataproc: cluster management fees(scaling, tuning, lifecycle management).
• Dataproc Serverless: No operational overhead, which can reduce engineering effort and hidden costs.

Scaling Costs

• Dataproc: Manual or autoscaling clusters can lead to over-provisioning.
• Dataproc Serverless: Dynamically allocates resources, ensuring you only pay for what you use.

Migration Costs

For Dataproc Serverless, if your workloads run on Spark 2.x, you must upgrade them to Spark 3+, which entails:

• Code changes and configuration update : which means allocating time and resources for refactoring, testing, and deployment, adding to the total cost.

To sum it up, if your jobs are already using Spark 3+ and you have occasional workloads, Dataproc Serverless can really optimize the costs. However, if you’re still on older Spark versions, you need to consider the costs of migrating your jobs and that could outweigh the potential savings.

5- Optimizing Dataproc Serverless: What to Watch Out For

Working with Dataproc Serverless it’s not all sunshine and roses, so it’s important to be aware of its limitations. For example, if a job involves long-running tasks, suffers from data skew, or lacks sufficient parallelism, you might need to manually adjust resource allocations. If you don’t, your jobs can time out, leading to increased costs due to retries.

So what you should do in such situations:

• Analyze execution logs to identify any bottlenecks.
• Analyze the diagrams on the GCP interface and the Spark UI( memory usage , cpu, workers). Don’t hesitate to use the help of “Gemini” the Google’s AI model to analyze the dashboards.
• Set appropriate maximum worker limits to ensure adequate parallelism.
• Optimize data partitioning to enhance task distribution and performance.

6- Conclusion

In Conclusion, Dataproc Serverless appears to be “the choice” when looking for an optimized solution regarding costs, time and low-maintenance. I think Google has done a great job making Spark execution easier, which makes Serverless a strong option for many use cases.

That being said, Dataproc classic (cluster-based) can still be better option in some cases:

• If your jobs run for long periods and need consistent resources, a dedicated cluster might be more stable and predictable in terms of cost.
• If you’re still on Spark 2.x, moving to Serverless means migrating your jobs, which comes with hidden costs in time, effort, and testing.
• If you need full control and fine-tuning a traditional cluster could give you better performance .

In the end, the right choice depends on: your workload, budget, available time, and how much control you need over your jobs.

Dataproc vs Dataproc Serverless was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

L’Intelligence Artificielle (IA) est partout, de plus en plus utilisée, transformant la manière dont nous abordons nos tâches. Elle se révèle comme un assistant précieux, permettant d’aider les personnes à accomplir plus rapidement leurs activités du quotidien.
Dans le domaine de la manipulation de son en texte, elle nous offre des retranscriptions rapides, mais une intervention humaine reste indispensable pour garantir la justesse et la pertinence du contenu généré.

Dans cet article, nous allons vous parler de notre expérience avec l’IA dans la production de notre podcast Zenikast et plus particulièrement celle de Google : Gemini

🎙️ Zenikast, une nouvelle aventure

Quand nous avons lancé Zenikast, le nouveau podcast de Zenika, nous nous sommes interrogés sur la manière de rendre accessible nos futurs épisodes.

L’accessibilité , et surtout quand il s’agit de podcast, n’est malheureusement pas souvent une priorité. A Zenika, c’est un sujet qui nous tient à cœur. Nous avons la volonté d’amener l’accessibilité au sein de nos prestations, nos audits, nos formations et aussi lors de nos activités annexes comme le podcast !

Sur les plateformes de podcast comme Apple podcast ou bien Youtube, des transcriptions automatiques sont générées, laissant parfois, voire souvent, des erreurs et diverses hallucinations. Nous le savons, les outils basés sur l’IA s’améliorent jour après jour mais nous avions l’envie et la volonté de mettre à disposition une transcription quasi parfaite. Pour mettre à disposition cette transcription, nous avons opté pour une solution simple et efficace : un Google Doc. Nous avons un outil interne qui permet de créer des liens vers des pages web ou documents et éviter de mentionner le lien du document tel quel. Nous pouvons donc avoir rapidement et simplement un lien de type https://links.zenika.com/link/zenikast/episode-1.

Merci à Emmanuelle Aboaf pour avoir pris le temps de répondre à nos questions et pour tes conseils 🙏.

🧪 Nos premiers essais: Whisper Transcribe

Pour la saison 1, nous étions plusieurs personnes au profil technique à s’occuper du podcast. Nous avons donc testé différents outils, basés sur des projets Node.js, Java, ou bien sur des outils directement à installer. Mais Zenikast a pour vocation d’être à la disposition de toutes les personnes de Zenika, qu’elles soient tech ou non. L’outil et la manière de créer nos transcriptions doivent donc être accessibles à tous les profils des collaborateurs et collaboratrices de Zenika.

Nous avons sélectionné Whisper Transcribe, et avons pu tester nos premières transcriptions avec la version gratuite . Merci aux personnes qui ont travaillé sur ce magnifique projet 💪.

Petit plus de Whisper : la diarisation, ou détection automatique des différents intervenants·es dans le podcast, une fonctionnalité très utile pour nos épisodes pouvant avoir jusqu’à 6 voix.

Des mots spécifiques, abréviations ou termes techniques peuvent être ajoutés à la liste des mots “connus” de Whisper.

Malgré sa qualité, chaque transcription demandait tout de même plusieurs heures de relecture pour arriver à un texte sans erreur et structuré de façon à être agréable à lire. De plus, Whisper Transcribe est payant pour une utilisation plus intense.

💡 Vers l’IA générative avec Vertex AI

Lors du Devoxx France mi-Avril, une discussion avec Valentin Deleplace nous a orienté et surtout convaincu de pousser nos expérimentations avec Gemini et Vertex AI Studio de Google Cloud. Il est possible d’y importer un fichier audio (.mp3 ou .wav) et de demander à Gemini de nous donner la transcription de l’épisode, sans écrire une seule ligne de code.

Le rendu est largement satisfaisant et a poussé notre curiosité à tester d’avantage la transcription de notre épisode de podcast que nous tournions d’ailleurs pendant le Devoxx (cf la vidéo de l’épisode) avec les solutions Google.

🧪 Retour d’expérience : Gemini 2.5 Pro à l’épreuve

Nous sommes donc allés tester directement avec le dernier modèle : Gemini 2.5 Pro.

Disponible en preview via Vertex AI, Gemini 2.5 Pro a la capacité de traiter des prompts multimodaux : texte, image, audio, voire même vidéo. Contrairement aux générations précédentes, il intègre des capacités de raisonnement bien plus poussées.

La prise en main est rapide : en important un fichier .mp3 ou .wav, nous avons interagi avec le modèle directement dans l’interface de Vertex AI Studio et en quelques secondes Gemini génère un texte très fluide et assez fidèle à l’audio. Là où Whisper Transcribe nous demandait une bonne relecture, Gemini a nettement réduit ce temps. Mais surtout, il est aussi capable de faire de la diarisation, c’est-à-dire de détecter et séparer les différentes voix intervenant dans le podcast.

🪜 Étape 1 : Transcription avec détection des voix

Nous avons importé un fichier .wav dans Vertex AI Studio et formulé une simple instruction.

Peux-tu me générer la transcription de ce fichier audio ?
Contexte : pour le podcast Zenika (Zenikast), nous enregistrons un épisode au Devoxx France 2025. La première personne qui parle est Jean-Philippe et la deuxième personne Benjamin.
Peux-tu donner la transcription sous format texte ?

En quelques secondes, Gemini a produit une transcription structurée, segmentée par “Intervenant 1”, “Intervenant 2”, etc.
Le résultat brut est vraiment satisfaisant. Pas d’hallucinations, très peu d’erreurs de transcription, et surtout une bonne compréhension des enchaînements entre les intervenant·es. Cette étape nous a convaincus du potentiel. Mais on voulait aller plus loin : améliorer la lisibilité du texte pour en faire un support plus agréable à lire, voire publiable tel quel.

🪜 Étape 2 : Nettoyage automatique des tics de langage

Lors d’un second prompt, nous avons demandé exactement la même transcription mais en enlevant les tics de langage : les “du coup”, “euh”, “voilà”, “en fait” et autres. Gemini a gardé l’esprit de l’échange, sans trahir le propos, mais en le rendant bien plus fluide à la lecture.
Un vrai gain pour les personnes qui liront la transcription sur le lien partagé.

Voici le prompt :

Peux-tu me générer la transcription de ce fichier audio ?
Contexte : pour le podcast Zenika (Zenikast), nous enregistrons un épisode au Devoxx France 2025. La première personne qui parle est Jean-Philippe et la deuxième personne Benjamin.
Peux-tu donner la transcription sous format texte ? Peux-tu également nettoyer le texte de façon à supprimer les tics de langage comme les “euh”, les répétitions de mot, etc afin de le rendre lisible tout en restant fidèle au texte au maximum.

🪜 Étape 3 : Deux versions complémentaires

Ce double rendu nous permet maintenant d’avoir à la fois une version fidèle à l’original et une version plus lisible.

🧭 Grounding : des réponses vérifiées via des sources fiables

Sur les captures d’écran précédentes, vous remarquerez l’activation d’une option nommée “Grounding” sur le panneau de droite.
L’idée est de connecter Gemini à des sources de données vérifiables, comme la Recherche Google, Google Maps ou même vos propres données. Cela permet de réduire drastiquement les risques d’hallucinations.

Par exemple, si on demande à Gemini de résumer un article de presse récent, de générer un contenu à jour, ou même de répondre à une question pointue sur un sujet en constante évolution, le grounding avec la Recherche Google permet d’adosser sa réponse à des contenus web récents et pertinents. Mieux encore : les réponses peuvent être accompagnées de citations et de scores de confiance, ce qui renforce l’auditabilité et la transparence.

Du côté de vos données, il est possible de connecter Gemini à du RAG Engine , du Vertex AI Search ou de l’Elasticsearch.

🚀 La suite, basée sur des agents IA?

L’utilisation de l’Intelligence Artificielle, que ce soit Whisper Transcribe ou dernièrement Gemini, nous a permis de gagner plusieurs heures sur la transcription de nos épisodes. Lors des premiers tests, nous passions 3 à 4h pour relire et corriger un épisode. Pour le moment, même si cette cinématique est très archaïque et perfectible, nous n’y passons plus que 30 minutes.

Avec les annonces faites par Google courant Avril et Mai 2025, des améliorations vont rapidement pouvoir être testées et mises en place pour accélérer ce processus et permettre à tous les collaborateurs et collaboratrices de Zenika de réaliser des transcriptions en quelques clics (via la plateforme AgentSpace, le protocole Agent2Agent (A2A) et le framework Agent Development Kit, ADK. Nous vous raconterons sûrement cela dans un nouvel article de blog.

👉 Article rédigé avec Jean-Philippe Baconnais

Rendre son podcast accessible avec l’IA au service de la transcription was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Numerous articles may guide you on what to do, but in this one, you will uncover what not to do and like William Blake once said :

The errors of a wise man make your rule, Rather than the perfections of a fool.

So, regarding things not to do, we can divide them into two categories:

Preparation phase:

• Neglecting to review the official Google Cloud exam guide: The official exam guide is a crucial resource that outlines the exam key areas of focus. It provides a detailed breakdown of the topics covered, the weight of each section. By skipping this guide, candidates miss out on essential information that helps them understand what to expect on the exam.
• Schedule the date without considering potential program updates : if you booked a date after the 11th of November 2023 you will notice that the exam underwent significant changes. The updated exam now focuses more on data preparation, analytics, and pipeline management, with fewer questions on machine learning issues.
• Ignoring the labs: you may very well understand the various Google Cloud Platform (GCP) services relevant to data engineering, but without hands-on practice with GCP services, you may struggle to answer practical and detailed exam questions effectively.
• Use only one source of documentation : Avoid relying on a single source of documentation. It’s essential to consult multiple references to gain a comprehensive understanding
• Not making a summary : Notes can be invaluable when preparing for exams or assessments. They provide a structured overview of the material, making it easier to study efficiently and effectively.

Day D

• Be hungry , thirsty , cold…: Ensure you are comfortable during the exam; sitting on a comfortable chair is essential. The exam lasts 2 hours, and discomfort can make it feel like an eternity.
• Panic when the exam stops unexpectedly: If the exam stops unexpectedly, which can happen frequently, especially during the middle of the test, remain calm and follow the instructions given. You will be able to resume and continue with your exam.
• Flag all the questions: Use flags to mark questions you’re unsure about and want to revisit later. However, remember that you may not have time to revisit all flagged questions if you flag all 50. Mark only the most critical ones to manage your time effectively.
• Panic when the “exam tool” struggles to launch: If you encounter issues launching the exam, remain calm. It’s normal for technical tools to have occasional issues and you may start a little late is okay. Follow the provided instructions carefully to resolve the problem and begin your exam smoothly.

To wrap it up, avoiding these mistakes helps you prepare better for your exam and handle challenges successfully. If you don’t pass the first time, see it as a chance to learn from what went wrong and hey you will have your own list of what to not do !! and second time could really be a charm

so don’t stop learning you’ve got this!

A google cloud professional data engineer certification short story on what not to do was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.

Like in the pyramid testing model, testing end to end metrics is a complementary approach to the metrics that we are used to check.

With new SEO constraints linked to the performance of web applications, many companies are now managing end to end metrics to get the full picture of what is working and how fast their websites are.

“Everything fails, all the time” is a famous quote from Amazon’s Chief Technology Officer Werner Vogels. This means that software and distributed systems may eventually fail because something can always go wrong.

Definition & Concepts

In a few words : It’s a way to monitor your application, by simulating user actions and business critical scenarios. This aims to warn you of production related issues, so you can fix them before impacting most of your users.

If you are familiar with End-to-end testing, you are almost good to go. The idea, here, is to execute scripts that mimic your users and ”run” most business critical scenarios.

The key difference is that you are running this on your production environments, and focus will be given on performance of your application.

Once your scenario is executed, you’ll get plenty of metrics around your application, whether it’s related to web performance, or on one of your internal components.

Based on these metrics, you’ll be able to know where the effort needs to be made on your assets, to make your application more robust and fault-tolerant.

In general, there are different type of monitoring that refer to Synthetic monitoring :

1/ Availability Monitoring :

Will verify that your service is available at any time. It is a bit more sophisticated than a simple health check control, instead this monitor ensures that the service is running well and responding as it intends to be.

2/ Transaction Monitoring :

It is a step ahead of Availability Monitoring, now we are going to add scripts that will simulate users interactions to make sure business critical scenarios are working as expected.

3/ Web performance monitoring :

As its name suggests, it will focus on application performance throughout Core Web Vitals, this helps identify improvements/ degradation for your end-users.

Use-case

In this article, we will focus on Transaction & Web performance monitoring :

Our critic scenario is :

• A user navigates to https://training.zenika.com
• Type in search bar : “CKA”
• Should be redirected to a result page containing results.
• Choose the first training.
• Should be redirected to the training detail page.

Synthetic monitoring setup on Google Cloud

Demo: https://github.com/Tarektouati/GCP-synthetic-monitoring

A synthetic monitor is composed of 2 Google Cloud components :

• A cloud function
• A monitor attached to the cloud function.

We’ll create a Node.JS cloud function with a puppeteer inside to which iterate on our user’s scenario.

As it’s puppeteer, you can write it by yourself, and rely on testing-library best parcticies and install pptr-testing-library.

if you are lazy, that’s why you can use Chrome recorder, to generate your puppeteer user journey.

Once, your are good to go, deploy cloud function in the your desired region, by running :

gcloud functions deploy <YOUR_CLOUD_FUNC_NAME> — gen2 — runtime=nodejs18 — region=<REGION> — source=. — entry-point=<YOUR_CLOUD_FUNC_ENTRYPOINT> — memory=2G — timeout=60 — trigger-http

You should see you cloud function available on GCP console

Next, attach a monitor to that cloud function :

gcloud monitoring uptime create <YOUR_MONITOR_NAME> — synthetic-target=projects/<PROJECT_ID>/locations/<REGION>/functions/<YOUR_CLOUD_FUNC_NAME> — period=5

You should also see the monitor available and configured on the GCP console

Navigate to the monitor detail page, you can see whether it status is passing or not.

Go ahead and create an Alerting policy, this step is crucial as it will notify you when you monitoring goes wrong.

Define a duration before an incident is declared, select a channel (email, slack, pager-duty, …). And add instruction to help the duty-girl/boy understand the incident.

For now, we have seen Transaction Monitoring with GCP, but what about Web performance monitoring ?

This doesn’t come out of the box, but still possible on GCP by combining puppeteer with lighthouse (checkout puppeteer documentation for this https://github.com/GoogleChrome/lighthouse/blob/main/docs/puppeteer.md).

Set-up on synthetic monitoring on Datadog

A synthetic monitor on Datadog is composed of different components :

Select UX Monitoring > Synthetic tests > New Test then create a “Browser test”

Configure your test by filling:

• Target URL
• Name,
• Browser targets (Chrome, Firefox, …)
• Locations: Chose one or multiple locations based on your business requirements

Next, same as the GCP part, we need to define the test period and alerting conditions.

To create our test scenario it’s quite easy and fast, Datadog allow you to record a journey directly from your browser (This requires a browser extension to be installed)

Go ahead and create your own journey, and once you are satisfied, create your monitor.

By default, a Browser performance dashboard is already available.

This one showcases the metrics like

• success rate per browser (chosen in the test configuration in the steps above)
• Core web vitals
• Long running tasks (which can be painful for your users)
• 3-party integration
• …

Conclusion

Leveraging Google Cloud for Availability and Transaction Monitoring is a robust and efficient choice, especially for those already integrated into the Google Cloud ecosystem.

The seamless integration and comprehensive tools available within Google Cloud ensure thorough and effective transaction monitoring.

However, when it comes to web performance monitoring, while it’s still possible on Google Cloud, exploring Datadog can provide additional benefits.

Datadog’s Real User Monitoring (RUM) is particularly noteworthy, offering advanced capabilities and insights that might better serve your web performance monitoring needs.

More information :

• Link to Datadog doc
• Link to Google Cloud doc

Getting Started with Synthetic Monitoring on GCP and Datadog was originally published in Zenika on Medium, where people are continuing the conversation by highlighting and responding to this story.