Google Compute Engine (lire notre article « Compute Engine : l’IaaS hautes performances de Google »), l’offre d’hébergement cloud de Google, se veut séduisante et en tout cas financièrement attractive face à ses concurrents Amazon Web Services et Microsoft Windows Azure. Sauf qu’en limitant les technologies accessibles sur sa plateforme et en créant sa propre unité de mesure, Google modifie les règles du jeu en s’interdisant a minima 80% des clients cloud et ne permettant pas la comparaison entre les offres.
Rappel : lors de la conférence développeurs Google I/O qui s’est tenue la semaine dernière, Google a dévoilé Google Compute Engine, son offre IaaS (Infrastructure as a Service) d’hébergement des projets dans le nuage, dont les instances virtuelles tournent sur l’hyperviseur KVM (Google a travaillé avec Red Hat sur ce projet) sous Linux Ubuntu et CentOS.
Une semaine après l’annonce, des doutes sur Google Compute Engine émergent. De toute évidence, les projets Windows ne sont pas les bienvenus. Du coup, Google se coupe de 80% des clients du cloud qui tournent sous l’OS de Microsoft, mais également sous VMware et sous Citrix. Signe de faiblesse ou stratégie construite ? A moins que Google n’ait pas souhaité affronter Amazon AWS ? La question mérite d’être posée, surtout lorsqu’on apprend que Red Hat Enterprise Linux n’est pas non plus invité à la fête, alors que l’éditeur reconnaît avoir participé au développement de l’offre Google ! RHEL (Red Hat Enterprise Linux) viendra plus tard, a indiqué Google. Certes, mais quid d’une roadmap ?
Google a placé les tarifs de Compute Engine en dessous de ceux pratiqués par ses deux grands concurrents. En effet, une configuration d’infrastructure cloud de base – une CPU avec de la mémoire vive (3,75 Go selon Google) et du stockage (420 Go) – se négocie, prix de départ, moins cher chez Google. Mais est-ce la même CPU ? Le surplus de mémoire ne provient-il pas d’un noyau Linux de taille plus réduite ? Et pourquoi Microsoft propose-t-il plus de stockage ? Décidément, nous manquons d’éléments pour comparer les offres !
Pour corser la chose, Google n’a pas repris les unités de mesures adoptées par ses concurrents, mais propose au contraire sa propre unité de mesure de consommation d’une VM dans la CPU : la GCEU (Google Compute Engine Unit). Une VM Compute Engine sur un serveur Google consommerait 2,75 GCEU, ou encore 2,75 GQ comme indiqué par Google qui place on ne sait trop comment les acronymes GCEU et GQ dans ses documents pour représenter semble-t-il la même unité de mesure ! Il se pourrait que CGEU corresponde à l’ECU (EC2 Compute Unit) d’Amazon. Si c’est le cas, et en comparant des valeurs égales, cela signifierait que Compute Engine s’exécute sur un serveur équipé d’un processeur Intel Xeon Sandy Bridge, et qu’une instance consommerait un demi CPU, soit une thread.
Si la comparaison s’arrête là, notons que les premiers utilisateurs de la solution dédiée aux développeurs qui a précédé Compute Engine ont souligné la puissance de l’offre de Google, qui serait plus rapide que celle de ses concurrents, nécessiterait moins de ressources, avec un taux d’erreur plus réduit. Et elle offrirait un avantage important, les communications entre VM seraient automatiquement cryptées, quelque soit la localisation du datacenter. En revanche, 3 datacenters seulement hébergeraient Google Compute Engine, un au centre des Etats-Unis et deux à l’Est. Rédhibitoire pour les amateurs européens du moteur de recherche qui ne peuvent se permettre de placer leurs données hors du territoire de la Communauté…
Diverses tendances animant l'univers des LLM transparaissent en filigrane du discours de Meta sur Llama…
Mandiant a attribué un APT à Sandworm, considéré comme le principal groupe cybercriminel à la…
Les deux startup proposent un connecteur entre la platefome OpenCTI de Filigran et l’EDR de…
Des chercheurs ont mis des agents LLM à l'épreuve dans la détection et l'exploitation de…
Dans la lignée de Signal, iMessage intègre une couche de chiffrement post-quantique.
Douze fournisseurs sont classés dans le dernier Magic Quadrant des infrastructures LAN.