Google: Le Cloud est trop difficile

Dans son discours inaugural lors de la Google Cloud Platform Live qui a lieu en ce moment, Hözle affirme ensuite que le cloud est toujours trop difficile.;

  1. Il faut choisir entre le temps avant mise sur le marché et l’extensibilité ;
  2. Il faut choisir entre la flexibilité et la gestion automatique ;
  3. Il faut choisir entre Big data et temps réel.

Pour Hözle, il ne faut plus faire de compromis.

La première bonne nouvelle vient du directeur de développement de produit Greg Demichillie : les clients pourront désormais utiliser des machines virtuelles (VMs) Suse, RedHat et même Microsoft Windows Serveur 2008 R2.

Par ailleurs, les clients étaient gênés par la gestion des DNS, séparée de la gestion des réseaux. Google proposé donc le nouveau service Google Cloud DNS, intégré dans la console et pilotable par API. Ce service est comparable au service Route 53 qu’Amazon propose depuis 2010.

Temps avant mise sur le marché et extensibilité

Pour minimiser les délais de mise sur le marché, Google Cloud s’intègre avec les outils préférés des développeurs et ne leur demande pas de choisir.

Google Cloud facilite l’isolement et la réparation des problèmes lors de la phase de production. L’outil GCloud Console a été amélioré. L’appui sur tab tab permet d’afficher les commandes possibles. On est loin de la sophistication du PowerShell de Microsoft néanmoins.

La console Web permet de filtrer les logs en un seul endroit avec de très nombreux critères. Une fois la ligne d’erreur isolée, un lien hypertexte permet d’aller directement dans le code à changer.

Une fois le code changé, le système le sauvegarde automatiquement dans git, procède aux tests, et le déploie.

De cette façon, le programmeur n’a pas à sacrifier la rapidité de mise sur le marché pour l’extensibilité.

 

Des Hyperliens vers le code source
Des Hyperliens vers le code source

Flexibilité et gestion automatique

Nous détaillerons ce point sur les Managed VMs.

 

Big Data ou temps réel ?

Le problème du Big Data, c’est le temps à ingérer et préparer les données.

Il faut d’abord déplacer les données d’un point à un autre, puis il faut les transformer d’un format à un autre.

Ensuite il faut procéder au « sharding », c’est-à-dire de découper les tables pour que chaque instance de base de données en gère une partie, ce qui est absolument nécessaire au vu des quantités de données.

Mais toutes ces étapes sont préparatoires, elles n’ont rien à voir avec l’analyse des données.

Pour éviter tous ces désagréments, Google propose Big Query Streaming, qui permet d’utiliser les données dès qu’elles sont reçues en quasi temps réel, en automatisant toutes les étapes de préparation.

Le système était capable de traiter 1000 lignes de données par seconde, désormais il est capable de traiter 100 000 lignes par seconde !

Lors d’une démonstration qui s’appuyait sur le cas hypothétique d’une entreprise de compteurs communicants, on pouvait voir des réponses à des requêtes en moins de 10-20 s. Une carte de tous les compteurs d’une ville comme Seattle (630 000 habitants) était actualisée toutes les 10 s avec la consommation en temps réel des compteurs.

Enfin, la possibilité d’opérer des jointures entre les tables permet une certaine dénormalisation de la base de données, ce qui peut réduire considérablement son volume. Dans l’exemple, il s’agissait d’une table avec la latitude et la longitude des compteurs.

 

Visualisation en quasi temps-réel de Big Data
Visualisation en quasi temps-réel de Big Data