Google Cloud Next | Focus Session

La semaine dernière, cinq de nos consultants ont fait le déplacement à San Francisco pour la Google Cloud Next. Partenaire Google Clous Platform, Zenika ne pouvait qu’être présent.

Dans un premier article, nous avons mis un premier focus sur les keynotes et les grandes annonces de la Google Cloud Next, focus maintenant quelques sessions auxquelles nos consultants ont pu assister.

Moving From Cassandra to AutoScaling Cloud BigTable at Spotify

Cette session animée par Emilio Del Tessandoro (Senior Software Engineer chez Spotify) et Sandhya Ghai (Cloud Bigtable Product Manager chez Google Cloud) est un bon retour d’expérience sur la migration de Cassandra vers Cloud BigTable sur GCP.  

Emilio commence par présenter le pourquoi de cassandra chez spotify (Tunable consistency, Tunable performance, replication, scalabilité, CQL) et les limitations rencontrées :

• Couplage fort entre storage et compute
• Scalabilité horizontal limité
• Beaucoup de complexité sur le tuning de la performance et sur la partie export
• Changement de design très consommateur de temps

Emilio en profite pour nous rappeler qu’ils ont dû développer certains outils pour répondre aux problématiques d’automatisation : cassandra-reaper, cstar, hecuba, hezo, …
Avant la migration vers GCP, Cassandra chez Spotify, c’est plus de 100 clusters en production, 3000 machines sur un datacenter on-premise.

Emilio enchaîne sur les gains de la migration vers GCP :

• Moins de travail sur l’infrastructure, aucun provisionnement à planifier
• Un gros gain sur les coûts d’infrastructure
• Moins de problèmes techniques, plus de temps à passer sur la logique métier
• De nombreuses opportunités techniques qui s’ouvrent à eux : Styx, Scio, Forseti, Backstage, auto-scaler
• Utilisation de DataProc pour simplifier les exports de données

Sandhya reprend la main pour nous présenter Cloud BigTable et ses caractéristiques avant qu’Emilio nous explique comment ils ont créé un autoscaler pour les nœuds BigTable. En effet,  l’auto-scaling des nœuds de BigTable n’étant pas proposé, ils ont initié un projet pour le gérer automatiquement.
Pour se faire, ils se sont basés sur le monitoring des services de BigTable pour adapter les nœuds en fonction du CPU et en fonction d’un nombre minimum et maximum de nœuds.
Au final, un très bel exemple de ce que le cloud peut amener et de toutes les problématiques qu’il peut résoudre, le tout avec un gros gain sur les coûts et la possibilité de se focaliser sur la logique business plutôt que sur des problématiques techniques. Regarder cette session.   

Build an End-to-End Serverless App with compute, Machine Learning and Data

Cette session est animée par Bret McGowen (Developer Advocate chez Google). Durant 45 minutes, Bret va nous montrer comment construire un site de vente de glace en ligne entièrement en utilisant les features Serverless de GCP.
Après un bref rappel des principes du serverless (Pas d’infrastructure à gérer, scaling automatique, on ne paie que pour ce qu’on consomme), Bret va nous présenter durant tout son talk les patterns qu’il a choisis pour mettre en place son application.

Architecture Overview

Le début est assez classique, du AppEngine pour la partie présentation et du firebase pour stocker les données.
Pour la logique métier, tout ce qui est synchrone sera géré dans AppEngine, et pour tout ce qui est asynchrone, du Cloud Pub/Sub et des cloud functions.

Pour la relance des paniers abandonnés, Cloud Scheduler permettra de lancer de manière régulière une fonction qui ira les chercher en base et appellera un service externe d’envoi de mail.

On enchaîne sur un peu de machine learning pour la partie enrichissement produit. Lors de la création d’une fiche produit avec photos depuis la partie admin du site, on utilisera Cloud vision API et AutoML vision pour créer automatique les labels associés à la photo.  

La cerise sur le gâteau est de permettre au client d’effectuer ses commandes grâce à Google Assistant. Pour cela, on utilisera Dialogflow pour extraire les intentions et appeler les cloud fonctions qui enregistreront la commande.

En conclusion, un très bon talk pour une découverte des pattern serverless et une demo app complète pour découvrir le serverless.
Regarder cette session
Regarder le code

From Monolithic to MicroServices

On parle ici du retour d’expérience d’équipes de projets Google qui ont transformé des outils internes (Louhi et Glasspane).
Le but est de capitaliser sur les bonnes pratiques et éviter les erreurs communes lors de ce processus.

La première étape est de se demander : Quelle taille ou granularité doivent avoir mes microservices ?

• Réfléchir avec une approche DDD
• Principe de single responsability
• Garder en tête que une fonctionnalité => un microservice
• Une entité forte par service
• Attention de ne pas tomber dans l’anti pattern : nano-service

Ensuite,  la découpe du projet s’apparente à un déploiement green/blue :

• La première étape est de créer un proxy entre les endpoints et les nouveaux microservices.
• Ensuite, migrer une fonctionnalité dans un micro service
• Une entité forte -> une Db dédiée
• Débrancher l’ancien service
• …

Conseils généraux :

• Désigner chaque service
• Supprimer les dépendances interservices
• Déployer séparément
• Utiliser une API Gateway pour agréger les appels de services
• Utiliser des outils comme Istio ou Envoy pour enrichir les requêtes (correlation ID …)
• Utiliser des patterns de design tels que Strangler Pattern, Saga Pattern, Circuit Breaker…

À travers cette session, les équipes Google nous ont montré que la plateforme GCP dispose de tous les outils nécessaires pour arriver facilement à découpler des services (app engine, Api gateway, Cloud function, les métriques, …)

Plugin K8s dans VS Code : Cloud Code

L’idée est de permettre un déploiement rapide et hyper simplifié d’application “conteneurisée” depuis un IDE dans GKE.

Le plugin s’appuie sur un fichier de configuration (skaffold.yml) pour déployer une application (Skaffold est, entre autres, un prérequis). Il est ensuite possible de créer des fichiers de description pour les différents pods susceptibles d’être déployés. Ces fichiers se créent dans un dossier kubernetes-manifest.

Il faut créer autant de manifest que d’applications, le plugin facilite la création de ces fichiers grâce à différents snippets.

Enfin un plugin nous assiste également pour le déploiement.

Un deployment wizard permet également de compartimenter facilement, par profile, le build et déploiement d’application par environnement (vue simplifiée des profiles dans skaffold.yml).

Pour débugger, il est possible de configurer un fichier launch.json et grâce à un snippet spécifique basculer en debug. La configuration varie en fonction du buildpack (nodejs, go…). Le breakpoint fonctionne dans VS code en local. Avec Kubernetes Explorer, il est possible de créer un cluster Kubernetes directement dans VS code sur GKE via une interface, facilitant la configuration des nodes, replicas…tout comme dans Google console.

La démo que nous avons vue présentait ces fonctionnalités en se basant sur des applications telles que proposées dans les samples.

Pour résumé, le plugin supprime tout le boilerplate et apporte un grand confort dans la configuration fastidieuse des applications Cloud-Native pour K8s.

Le plugin existe également pour Intellij en version alpha et pour VS code en version beta.
https://github.com/GoogleCloudPlatform/cloud-code-vscode

Inside Google Data Center

Cette session animée par Joe Kava présentait l’intérieur des data centers de google.
Les datacenters de Google depuis plus de 20 ans sont de plus en plus nombreux et importants. Il y a maintenant plus de 50 datacenter répartis dans le monde entier.
Les serveurs sont construits directement par Google, que ce soit les puces électroniques ou les armoires les contenants.

Tout est fait pour simplifier la maintenance, le remplacement et le travail des personnes en charge du data center avec par exemple des tiroirs ou des armoires sur roulettes.
Le refroidissement des serveurs se fait en utilisant l’eau de mer, l’eau recyclée, l’air ambiant, autrement dit tout moyen écologique.

• Google possède un énorme réseau de fibre optique et de câbles sous-marins qui relient tous les datacenters.
• La surface d’un data center fait 235 terrains de football américain, et il doit être disponible à tout moment 24 * 7 * 365.
• Seulement 15,4% d’erreur humaine (contre 70% en moyenne dans l’industrie), mais aucune erreur humaine n’a provoqué un temps d’arrêt des datacenters.
• La sécurité est un point très important, les accès au data center sont contrôlés, et tout un ensemble d’éléments de sécurité sont installés.
• Google travaille énormément sur l’aspect écologique de ses data center, ils utilisent 50% d’énergie en moins qu’un autre data center.
• Google est la plus grosse société à acheter de l’énergie renouvelable et a par exemple installé 10665 panneaux solaires sur le datacenter en Belgique.
• Du machine learning est utilisé pour réguler le refroidissement des serveurs et ainsi réduire les coûts et l’utilisation d’énergie nécessaire.
• Google a pour volonté d’avoir 100% d’énergie renouvelable en 2020.

What’s New in TensorFlow, and How GCP Developers Benefit

Cette session animée par Paige Bailey (Developer Advocate,TensorFlow) et Lak Lakshmanan (Tech Lead, Google Cloud) parlais des nouveautés de TensorFlow et quels sont les bénéfices de GCP pour les développeurs utilisant TensorFlow.

TensorFlow est un des projets github les plus actifs, il a été téléchargé plus de 40 millions de fois, plus de 1800 contributeurs ont créé plus de 50 000 commit et 9 900 pull request.
TensorFlow a été publié en octobre 2015 et a connu de nombreuses évolutions en à peine 3 ans que ce soit dans les supports de processeurs graphiques (GPU ou CUDA puis les TPU), l’intégration d’APIs haut niveau (Keras, Estimators), de nouvelles façons d’exécuter (distribué ou eager) ou l’intégration d’outils (Tensorboard, Big table), mais TensorFlow Lite ou TensorFlow.js !

La nouvelle version TensorFlow 2.0 veut apporter une simplification et une unification des APIs. L’API haut niveau keras sera maintenant recommandé, mais sera compatible avec l’api bas niveau pour facilement ajouter des couches simples tout en pouvant avoir une couche plus complexe. L’exécution eager devient l’exécution par défaut. La syntaxe entre les différentes apis sera plus intuitive et consistante, tandis que les fonctionnalités dupliquées seront supprimées.

Mais surtout, TensorFlow 2.0 veut rester compatible avec tout l’écosystème existant et proposera un script pour migrer automatiquement votre code en indiquant les choses à changer s’il n’a pas réussi à le faire automatiquement.

Dans l’environnement GCP, il est possible d’utiliser des VM spécialement optimisés pour le machine learning utilisant des TPU (Tensor Processing Unit) qui sont 300 fois plus rapides que les VM utilisant des GPU (Graphics Processing Unit), pour un coût moins important.

L’API Keras supporte de manière simple les TPU.

Tensorflow 2.0 est dès maintenant disponible en version alpha sur les Notebooks, Cloud ML Engine, Kupeflow pipelines.

TensorFlow Extended (TFX) est une plateforme permettant de déployer un pipeline de machine learning en production qui est maintenant disponible sur Google Cloud en utilisant Google Kubernetes Engine (GKE) ou directement les produits pour cela comme Cloud Dataflow et Cloud ML Engine.

Conclusion

C’est une conférence très riche permettant de découvrir et approfondir l’ensemble des produits de la plateforme GCP.
Le cloud est clairement en train de modifier la façon dont nous travaillons et il nous offre quantité d’opportunités :

• Réduction des coûts
• Simplification des process et facilité à la mise en place de nouvelles architectures
• Accélération des développements

La plateforme GCP est clairement aboutie et continue sans cesse de s’étoffer de nouvelles possibilités. Elle nous permet de résoudre les problèmes que nous rencontrons au quotidien avec nos clients, le tout avec un seul leitmotiv : Se focaliser sur le business et accéder à de nouvelles possibilités.

Nous en sortons tous avec l’envie de tester ce que nous avons vu et d’utiliser tout cela dès demain chez nos clients.

Vous pouvez revoir l’ensemble des sessions de la conférence sur youtube

Cet article a été corédigé par nos consultants : Gregory Rolland (Zenika Bordeaux) Patrice De Saint Steban Charles-Henri Guérin Julien Landuré (Zenika Nantes) et moi-même (Zenika Lille)