Dans la course d’aujourd’hui pour accélérer le temps de chargement de site Web, chaque milliseconde compte. L’équipe de Kinsta a testé et étudié l’impact de la vitesse de site Web sur les ventes, les conversions, l’expérience utilisateur et l’engagement des utilisateurs.
Mais il y a une mise en garde. Bien que l’optimisation sur un site soit importante pour améliorer la vitesse, ce n’est pas le seul aspect sur lequel nous devrions nous pencher. Le matériel et l’infrastructure réseau qui prennent en charge notre site Web et qui le connectent à nos visiteurs sont importants.
Aujourd’hui, nous allons discuter des raisons pour lesquelles Google investit beaucoup d’argent dans son infrastructure réseau, et certaines des différences entre le réseau de niveau premium de Google Cloud Platform et le réseau de niveau standard.
Bande Passante et Latence (Critères Clés de Performance de L’infrastructure D’hébergement)
Avant d’entrer dans les détails du réseau de Google Cloud, il est important de comprendre les deux concepts suivants : la bande passante et la latence.
La largeur de bande est la capacité de débit du réseau, mesurée en Mbps, tandis que la latence est le retard ou la somme de tous les retards que différents routeurs ajoutent en cours de route à nos requêtes et réponses Web.
Au sens figuré, la largeur de bande ou le débit peut être représenté comme la capacité d’un tuyau à permettre un certain volume d’eau par seconde. La latence peut être comparée au délai qui s’écoule entre le moment où la conduite d’eau est ouverte et celui où elle commence à couler.
En raison de la faible surcharge liée à l’établissement de la connexion entre les différents routeurs, chaque « saut » en cours de route ajoute une petite quantité de latence aux requêtes et réponses finales.
Ainsi, plus le visiteur et le serveur sur lequel le site est hébergé sont éloignés, plus la latence sera grande. De plus, plus le réseau est fragmenté, plus la latence est grande.
Nous pouvons l’imaginer à l’aide d’un outil appelé traceroute, ou tracert sur Windows. Dans les captures d’écran suivantes, nous l’avons utilisé pour inspecter les délais de routage de deux requêtes, en provenance d’Europe. Plus précisément :
Pour weibo.com :
et pour bbc.co.uk :
Comme nous nous y attendions, le nombre de sauts sur le site en Chine est presque 2 fois plus élevé qu’en Europe. C’est donc une latence supplémentaire par rapport à une requête sur un site hébergé au Royaume-Uni.
Les trois colonnes que tracert affiche représentent trois allers-retours (RTT). Chaque ligne représente différents routeurs ou sauts en cours de route. Ils ont souvent des URL qui nous aident à déterminer où se trouve ce routeur spécifique.
Le temps aller-retour pour les routeurs en Chine / Hong Kong prend près d’un tiers de seconde.
Nous avons utilisé les outils pingdom pour charger un site web hébergé à Londres à partir de l’emplacement Pingdom en Australie, pour essayer d’établir la part que le réseau a dans le temps de chargement global d’un site web.
Ce sont les données d’un petit fichier CSS chargé dans ce scénario de test. La partie connexion a la part la plus élevée dans le chargement de cette ressource, suivie par SSL et Wait. Tout le temps jusque là, y compris le temps d’attente, est également connu sous le nom de temps au premier octet (TTFB), qui inclut la latence du réseau.
Lorsque les fournisseurs d’accès Internet annoncent la vitesse de la connexion Internet, ils font généralement de la publicité sur leur bande passante (la « largeur du tuyau », vous vous souvenez ?) qui n’est pas vraiment une mesure de la vitesse. L’augmentation de la largeur du tuyau peut augmenter la vitesse du site Web seulement dans une certaine mesure. C’est plus utile lorsque nous avons besoin d’une grande quantité de données envoyées par seconde, comme lorsque nous diffusons du contenu vidéo haute définition. Mais pour les utilisateurs qui jouent à des jeux multijoueurs en ligne en temps réel, la latence sera beaucoup plus importante.
Mike Belshe, l’un des co-auteurs de la spécification HTTP/2 et du protocole SPDY, a analysé l’impact de l’augmentation de la bande passante sur la vitesse de chargement du site Web par rapport à l’effet de la diminution de la latence sur la vitesse de chargement du site Web.
Voici les conclusions de Belshe, présentées dans un joli tableau :
Il devrait être clair que l’amélioration de la vitesse du site Web en augmentant la bande passante n’est pas le moyen le plus efficace d’atteindre de meilleures performances. D’autre part, en réduisant le RTT (round-trip-time) ou la latence, nous pouvons constater des améliorations constantes de temps de chargement de la page.
Réseaux vs Peering Internet vs Transit
Pour mieux comprendre notre sujet, nous devons expliquer les bases de la topologie de l’internet. Au cœur de l’Internet mondial, il y a de multiples réseaux mondiaux, régionaux et locaux.
Depuis 2018, il y a plus de 60.000 AS (systèmes autonomes). Ces réseaux appartiennent aux gouvernements, aux universités, aux FAI.
Parmi ceux-ci, on distingue les réseaux de niveau 1, de niveau 2 et de niveau 3. Ces niveaux représentent l’indépendance de chaque réseau sur Internet dans son ensemble.
- Les réseaux de niveau 1 sont indépendants, en ce sens qu’ils n’ont pas à payer pour se connecter à un autre point de l’Internet.
- Les réseaux de niveau 2 ont conclu des accords d’échange de trafic avec d’autres FAI, mais ils paient également pour le transit.
- Les réseaux de niveau 3, le niveau le plus bas, se connectent au reste de l’Internet en achetant du transit aux niveaux supérieurs. Ils sont pratiquement comme les consommateurs qui doivent payer pour accéder à Internet.
La relation de peering signifie que deux réseaux échangent le trafic sur une base égale, de sorte qu’aucun d’entre eux ne paie l’autre pour le transit.
Le principal avantage du peering est une latence considérablement réduite.
Dans l’image ci-dessus, nous voyons un scénario classique, où la requête web passe par le réseau hiérarchique des FAI de niveau 1, 2 et 3 afin de retrouver un site web hébergé dans un centre de données situé dans un endroit éloigné.
Les flèches représentent le parcours de la requête Web. Les flèches en pointillés représentent les correspondances de transit et les flèches en trait plein représentent les correspondances de peering.
Une fois que le fournisseur de niveau 1 est atteint, sa relation avec un autre fournisseur du même niveau est une relation avec ses pairs. Les réseaux de niveau 1 se connectent aux autres et relaient leurs requêtes exclusivement par l’intermédiaire de partenaires de peering. Ils peuvent accéder à tous les autres réseaux sur Internet sans payer pour le transit.
Nous pouvons également voir un autre scénario, dans lequel deux fournisseurs de niveau 2 ont un accord d’échange de trafic, désigné par une couleur turquoise. Le nombre de sauts dans ce scénario est plus faible et le chargement du site web prendra beaucoup moins de temps.
Protocole sur la Porte D’entrée de Passerelle (BGP)
BGP est un protocole dont on parle rarement, sauf dans des contextes très techniques. Cependant, ce protocole est au cœur même de l’Internet tel que nous le connaissons aujourd’hui. C’est fondamental pour notre capacité d’accéder à peu près à tout ce qui se trouve sur Internet et c’est l’un des liens vulnérables de la pile du protocole Internet.
Le protocole Border Gateway Protocol est défini dans les IETF Request For Comments #4271 de 2006 et a depuis reçu plusieurs mises à jour. Comme le dit la RFC :
« La fonction principale d’un système BGP est d’échanger des informations sur l’accessibilité du réseau avec d’autres systèmes BGP. »
En d’autres termes, BGP est un protocole chargé de décider de l’itinéraire exact d’une requête réseau, sur des centaines et des milliers de nœuds possibles vers sa destination.
Nous pouvons imaginer chaque nœud comme un système autonome ou un réseau composé de plusieurs nœuds ou routeurs, serveurs et systèmes qui y sont connectés.
Dans le protocole BGP, il n’y a pas d’algorithme d’auto-découverte (un mécanisme ou protocole par lequel chaque nœud nouvellement connecté peut découvrir des nœuds adjacents pour se connecter), à la place, chaque pair BGP doit avoir ses pairs spécifiés manuellement. Quant à l’algorithme de chemin, pour citer un expert Cisco :
« BGP n’a pas de métrique simple pour décider quel chemin est le meilleur. Au lieu de cela, il annonce un ensemble complet d’attributs avec chaque itinéraire et utilise un algorithme complexe comprenant jusqu’à 13 étapes pour décider quel chemin est le meilleur. »
Les systèmes autonomes transmettent les données de routage à leurs pairs, mais il n’y a pas de règles strictes qui seraient appliquées en ce qui concerne la sélection du chemin. BGP est un système implicitement basé sur la confiance et c’est peut-être l’une des plus grandes failles de sécurité de l’internet actuel. En 2018, lorsque le trafic de MyEtherWallet.com a été détourné et plus de 200 Ether ont été volés (d’une valeur de 152 000$) cela a mis en évidence cette vulnérabilité.
En réalité, cette faiblesse des BGP se traduit le plus souvent par l’émission de données BGP par divers réseaux (AS) avec d’autres intérêts en tête que l’efficacité et la vitesse pour les utilisateurs finaux. Il peut s’agir d’intérêts commerciaux, comme le transit payant, ou même de considérations politiques ou de sécurité.
Développement du Cloud Computing, du CDN et du Edge Market
En raison des besoins croissants du marché informatique, de l’industrie du web, des jeux en ligne, de l’Internet des objets et autres, le marché pour les fournisseurs de services et les produits qui résolvent le problème de latence est devenu évident.
Année après année, nous voyons de plus en plus de produits basés sur le cloud qui mettent en cache des ressources statiques à proximité des visiteurs (Content Delivery Networks) ou rapprochent l’informatique réelle des utilisateurs finaux. L’un de ces produits est le Cloudflare’s Workers, qui exécute le javascript V8 compatible avec les moteurs sur le réseau de nœuds de Cloudflare. Cela signifie que même WebAssembly ou GO code peut être exécuté très près du visiteur.
Lambda@Edge d’Amazon est un autre exemple de cette tendance, ainsi que le partenariat Intel et Alibaba Cloud pour fournir une plate-forme informatique de pointe commune ciblant le marché de l’IoT.
Un autre réseau mondial de nœuds de mise en cache de Google sert à la fois de CDN ,de réseau de mise en cache et de diffusion vidéo pour sa filiale YouTube.
Pour illustrer à quel point l’industrie ducloud est devenue avancée, et à quel point elle a réussi à réduire les latences du réseau pour les utilisateurs finaux, jetons un coup d’œil sur GaaS.
GaaS est l’abréviation de Gaming as a Service. Il s’agit d’une offre de cloud qui donne aux utilisateurs la possibilité de jouer à des jeux hébergés et exécutés dans le cloud. Cet article compare quelques produits phares dans le créneau du GaaS.
Tous ceux qui ont déjà acheté un téléviseur ou un vidéoprojecteur pour jouer, ou qui ont passé du temps à installer Miracast ou une autre connexion de diffusion entre un téléviseur et un autre appareil, savent à quel point la latence est critique. Pourtant, il existe des fournisseurs de GaaS qui offrent aujourd’hui du Game Streaming avec une résolution de 4k et un taux de rafraîchissement de 60Hz…et les joueurs n’ont pas besoin d’investir dans du matériel.
Le drame de la récente interdiction de Huawei par les États-Unis a attiré l’attention sur la question des réseaux 5G et sur le besoin urgent d’une voie claire pour améliorer l’infrastructure mondiale des réseaux.
Les capteurs qui relaient d’énormes quantités d’informations en temps réel, avec une latence minimale, pour coordonner les villes intelligentes, les maisons intelligentes, les véhicules autonomes dépendront de réseaux denses d’appareils périphériques. La latence est le plafond actuel pour des choses comme les voitures autonomes, avec différentes informations sur les capteurs, les données LIDAR, le traitement de ces données par rapport aux données des autres véhicules.
Les réseaux de diffusion de contenu et les fournisseurs de cloud computing sont à l’avant-garde de cette course. Nous avons déjà parlé du protocole QUIC / HTTP3 qui est déployé par les leaders du secteur capables de contrôler le cycle demande-réponse.
Comment les Fournisseurs du Cloud Résolvent-ils le Problème de Latence ?
AWS est peut-être le plus gros fournisseur de services dans le cloud en termes de part de marché. En 2016, ils ont investi dans Hawaiki Transpacific Transpacific Submarine Cable System visant à fournir une plus grande bande passante et à réduire la latence entre Hawaii, l’Australie et la Nouvelle-Zélande, ce qui était leur premier investissement dans l’infrastructure sous-marine. Cela est entré en service en 2018.
À l’époque, Google avait déjà une longueur d’avance sur ses concurrents en ce qui concerne la mise en place de backbones sous-marines. Un an avant le premier investissement d’Amazon, ITWorld a publié un article intitulé : « Les centres de données de Google grandissent trop vite pour les réseaux normaux, alors il construit le sien ».
En fait, c’est en 2005 qu’un journaliste technique, Mark Stephens, alias Robert X Cringely a écrit pour PBS.org, commentant la frénésie d’achats de Google sur le site Web de dark fiber (infrastructure de fibre optique non utilisée mais aménagée) :
« C’est plus qu’un autre Akamai ou même un Akamai sous stéroïdes. Il s’agit d’un Akamai thermonucléaire intelligent et dynamique, doté d’un back-channel dédié et d’un matériel spécifique aux applications. Il y aura l’Internet, et puis il y aura l’Internet Google, superposé dessus. »
En 2010, dans le cadre d’un article sur zdnet.com, Tom Foremski dit :
« Google est l’une de ces entreprises qui possèdent une grande partie de l’Internet », et continue : « Google s’est concentré sur la création de l’Internet privé le plus efficace et le moins coûteux à exploiter. Cette infrastructure est la clé de Google, et c’est la clé pour comprendre Google. »
À l’époque, l’article de Cringley soulevait certaines préoccupations au sujet des tentatives de Google de prendre le contrôle d’Internet, mais les choses sont devenues plus claires lorsque l’entreprise a lancé Google Fiber, la tentative de Google de conquérir le marché des FAI dans les plus grandes villes américaines. Le projet s’est depuis ralenti, à tel point que TechRepublic a publié un avis de décès du projet en 2016, mais les investissements dans les infrastructures, désormais à l’échelle mondiale, n’ont pas ralenti.
Le dernier investissement de Google dont la mise en service est prévue cette année, est un backbone reliant Los Angeles aux Etats-Unis et Valparaiso au Chili, avec une succursale pour la future connexion au Panama.
« Internet est communément décrit comme un nuage. En réalité, il s’agit d’une série de tubes humides et fragiles, et Google est sur le point d’en posséder un nombre alarmant. » – VentureBeat
Pourquoi Google Investit Autant dans son Infrastructure Réseau ?
Nous savons tous que Google est le moteur de recherche numéro un, mais il est aussi :
- Le propriétaire de la plus grande plateforme vidéo
- Le plus grand fournisseur d’e-mail (Gmail et Google Workspace)
- Il gagne pas mal d’argent sur ses produits de cloud-computing (taux annuel de plus de 8 milliards de dollars)
C’est pourquoi il a besoin de la latence la plus faible possible et de la bande passante la plus large possible. Google veut aussi posséder l’infrastructure réelle, parce que sa « soif insatiable » de plus de bande passante et de latence met Google, et ses homologues de grandes entreprises comme Amazon ou Microsoft, dans une position où ils doivent trouver des solutions matérielles et logicielles entièrement personnalisées.
Les points de présence, ou nœuds PoP, se trouvent aux limites du réseau câblé privé mondial de Google. Là, ils servent de points d’entrée et de sortie pour le trafic de connexion aux centres de données de Google.
La loi de Moore est une observation de Gordon Moore, cofondateur d’Intel, selon laquelle tous les deux ans, le nombre de transistors que nous pouvons mettre sur un circuit intégré doublera. Pendant des décennies, cette observation est restée vraie, mais maintenant, l’industrie informatique est sur le point de mettre la loi de Moore à rude épreuve, peut-être en signant sa fin dans un avenir proche. Pour votre information, Le PDG de NVIDIA a proclamé la loi de Moore morte plus tôt cette année.
Quel est donc le lien avec l’industrie du cloud et l’infrastructure réseau de Google ?
Lors de l’Open Networking Foundation Connect Event en Décembre 2018, le vice-président de Google et TechLead pour le réseau, Amin Vahdat, a admis la fin de la loi de Moore et expliqué l’énigme de l’entreprise :
« Notre demande en informatique continue de croître à un rythme effarant. Nous allons avoir besoin d’accélérateurs et de calculs plus étroitement couplés. Le tissu du réseau va jouer un rôle crucial pour lier ces deux éléments. »
Une façon pour les fournisseurs de cloud computing de répondre à la demande croissante de puissance de calcul est le clustering. Le clustering, pour le dire simplement, signifie mettre ensemble plusieurs ordinateurs pour travailler sur un problème unique, pour exécuter les processus d’une seule application. Évidemment, une condition préalable pour bénéficier d’une telle configuration est une faible latence ou une capacité réseau sérieuse.
Quand Google a commencé à concevoir son propre matériel, en 2004, les fournisseurs de matériel réseau pensaient en termes de boîtiers, et les routeurs et commutateurs devaient être gérés individuellement, via la ligne de commande. Jusque-là, Google achetait des grappes de switches à des fournisseurs comme Cisco, dépensant une fortune par switch. Mais l’équipement n’arrivait toujours pas à suivre la croissance.
Google avait besoin d’une architecture réseau différente. La demande sur l’infrastructure de Google augmentait de façon exponentielle (un article de recherche de Google 2015 affirme que la capacité de leur réseau a été multipliée par 100 en dix ans) et leur croissance a été si rapide que le coût d’achat du matériel existant les a également poussés à créer leurs propres solutions. Google a commencé à construire des switchs personnalisés à partir de puces de silicium, en adoptant une topologie de réseau différente qui était plus modulaire.
Les ingénieurs de Google ont commencé à construire sur un vieux modèle de réseau téléphonique appelé Clos Network, qui réduit le nombre de ports requis par commutateur :
« L’avantage du Clos Network est que vous pouvez utiliser un ensemble d’appareils identiques et peu coûteux pour créer l’arborescence et obtenir des performances et une résilience élevées qui seraient autrement plus coûteuses à construire. » – Clos Networks : Ce qu’il y a d’ancien est encore une fois nouveau, Network World
Pour ce nouveau matériel modulaire, l’équipe de Google a également dû redéfinir les protocoles existants et construire un système d’exploitation réseau personnalisé. Le défi qu’ils avaient à relever était de prendre un grand nombre de commutateurs et de routeurs et de les faire fonctionner comme s’il s’agissait d’un seul système.
La pile réseau personnalisée et la nécessité de redéfinir les protocoles ont amené Google à se tourner vers le réseautage défini par logiciel (SDN). Voici une keynote d’Amin Vahdat, vice-président de Google, Engineering Fellow, et chef d’équipe de l’infrastructure réseau, à partir de 2015, expliquant tous les défis et les solutions qu’ils ont apportées :
Pour les plus curieux, il y a cet article de blog intéressant qui vaut la peine d’être lu.
Espresso
L’espresso est le dernier pilier du SDN de Google. Il permet au réseau de Google d’aller au-delà des contraintes des routeurs physiques en apprenant et en coordonnant le trafic entrant et sortant vers les partenaires de peering de Google.
Espresso permet à Google de mesurer la performance des connexions en temps réel et de baser la décision sur le meilleur point de présence pour un visiteur spécifique sur des données en temps réel. De cette façon, le réseau de Google peut répondre dynamiquement à différents ralentissements, ou pannes dans son peering / ISP.
De plus, Espresso permet d’utiliser la puissance de calcul distribuée de Google pour analyser toutes les données du réseau de ses pairs. Tout le contrôle et la logique de routage ne résident plus dans les routeurs individuels et le Border Gateway Protocol, mais sont transférés sur le réseau informatique de Google.
« Nous utilisons notre infrastructure informatique à grande échelle et les signaux de l’application elle-même pour apprendre comment les flux individuels fonctionnent, en fonction de la perception de la qualité par l’utilisateur final. » — Espresso rend Google Cloud plus rapide, 2017
Comment tout Cela est-il Pertinent pour le Réseau Google Cloud ?
Ce que nous avons abordé jusqu’à présent met en évidence tous les problèmes et les défis (tant matériels que logiciels) que Google a dû affronter pour assembler ce qui est probablement le meilleur réseau privé mondial actuellement disponible.
En termes de parts de marché, Google Cloud Platform est le troisième fournisseur mondial (après AWS et parts de marché d’Azure de Microsoft). Mais pour ce qui est de son infrastructure de réseau privé haut de gamme, elle laisse ses concurrents loin derrière, comme le montrent les données de BroadBand Now :
En 2014, GigaOM a publié un article comparant AWS et Google Cloud Platform, mais seulement une semaine plus tard, ils en publiaient un autre intitulé : « Ce que j’ai manqué dans le débat Google vs. Amazon ». Où ils reconnaissent que Google a des années d’avance en termes d’infrastructure.
« Avoir de gros tuyaux rapides à disposition de votre trafic – et de celui de vos clients – est une affaire d’or. » – Barb Darrow, GIGAOM
Réseau Premium de Google par Rapport aux Réseaux de Niveau Standard
La plateforme Google Cloud offre deux niveaux de réseau différents qui diffèrent à la fois par leur prix et leurs performances.
Réseau Premium Google
Avec le réseau Premium de Google, les utilisateurs peuvent profiter du réseau mondial de fibres optiques, avec des points de présence répartis dans le monde entier. Tout le trafic entrant (inbound) du client vers les centres de données de Google est acheminé vers le point de présence le plus proche, qui est distribué dans le monde entier, et la requête est ensuite acheminée à 100% sur le réseau privé de Google. Comme nous l’avons mentionné dans un article précédent – cela peut signifier une amélioration de 30% de la latence ou 50% de bande passante en plus.
Sur le chemin du retour, toutes les données envoyées du centre de données au visiteur sont acheminées à l’aide de la politique de la patate froide. Contrairement au routage patate chaude, utilisé sur le réseau Standard, où le trafic est, le plus tôt possible, transféré (ou abandonné) à d’autres FAI, le routage Premium signifie que le trafic de sortie est conservé le plus longtemps possible sur la fibre de Google, et est transmis aux pairs ou aux FAI de transit le plus près possible du visiteur.
Pour le dire en termes simples. Les paquets de niveau Premium passent plus de temps sur le réseau de Google, avec moins de rebondis, et sont donc plus performants (mais coûtent plus cher).
Pour les amateurs de science-fiction, cela pourrait être comparé à un vortex cosmique, qui transfère notre trafic directement vers notre destination sans passer par Internet.
Chez Kinsta, nous utilisons le réseau premium de Google Cloud avec toutes nos offres d’hébergement. Ceci minimise la distance et les sauts, ce qui permet un transport global plus rapide et plus sécurisé de vos données.
Réseau Google Standard
D’autre part, le réseau Standard utilise des points de présence près du centre de données où se trouve notre contenu ou application web. Cela signifie que le trafic de nos visiteurs passera par de nombreux réseaux différents, systèmes autonomes, FAI, et à travers de nombreux sauts jusqu’à ce qu’il atteigne sa destination. Dans ce scénario, la vitesse est compromise.
Le contenu voyageant sur le réseau standard ne sera pas en mesure de profiter pleinement des avantages du SDN de Google et de la grande puissance de calcul pour calculer les meilleurs itinéraires de façon dynamique. Le trafic sera soumis aux politiques BGP de tous les systèmes situés entre Google et le visiteur.
Pour le dire en termes simples. Les paquets de niveau standard passent moins de temps sur le réseau de Google, et plus de temps à jouer à la patate chaude sur les réseaux publics, et donc, sont moins performants (mais moins chers).
De plus, le niveau premium utilise l’équilibrage global de charge, alors que le niveau standard n’offre que l’équilibrage régional de charge, ce qui apporte plus de complexité et plus de « pas » pour les clients sur Standard.
Le réseau de niveau Premium propose un accord mondial sur les niveaux de service (SLA), ce qui signifie que Google accepte la responsabilité contractuelle de fournir un certain niveau de service. C’est un signe de garantie de qualité. Les niveaux de réseau standard n’offrent pas ce niveau de SLA.
Pour ceux qui veulent en savoir plus, il existe une comparaison et une documentation assez complète des deux niveaux sur le site de Google Cloud. Ils fournissent même un tableau pratique pour vous aider à déterminer plus facilement quel niveau de réseau vous devriez utiliser :
Résumé
Depuis des années, Google investit dans la création d’une infrastructure réseau mondiale, le déploiement de ses propres protocoles et de ses propres piles réseau matérielles et logicielles. À une époque où la loi de Moore semble s’affaiblir d’année en année, l’infrastructure de Google permet à l’entreprise de répondre à la demande sans cesse croissante de ressources de cloud.
Bien qu’en termes de parts de marché, elle soit toujours derrière Amazon Cloud et Azure Cloud de Microsoft, Google a acquis un avantage crucial tant pour la fibre qu’elle possède que pour les solutions matérielles et logicielles de pointe déployées par ses ingénieurs.
On peut s’attendre à ce que Google joue un rôle clé dans la technologie de l’IoT, des villes intelligentes, des voitures sans conducteur, et la demande en informatique de pointe ne cesse de croître.
Le réseau Google Cloud de niveau Premium est le premier produit à utiliser les innovations de Google en matière de réseaux. Il permet aux clients de profiter du réseau de Google et de l’ensemble de la pile pour diffuser du contenu à grande vitesse. Avec les garanties de Google concernant la latence.
Kinsta se consacre à fournir les meilleures performances d’hébergement d’applications, d’hébergement de bases de données et d’hébergement WordPress infogéré à l’échelle mondiale. C’est pourquoi Kinsta est propulsé par l’hébergement Google Cloud et nous utilisons le réseau Premium Tier de Google pour tous nos plans d’hébergement.
Tonino is an entrepreneur, Linux & OSS enthusiast, developer, and tech educator. He has over ten years of experience in development and has been in the blockchain space for 3+ years. When he's not coding, he writes for SitePoint and Alibaba Cloud, binge-watches the newest works of fiction on Netflix, and explores new travel destinations.
Laisser un commentaire