Tegenwoordig draait alles om het verminderen van de laadtijd van je website: elke milliseconde telt. Het team van Kinsta heeft onderzoek en tests gedaan naar de impact van de snelheid van een website op verkoop, conversies, gebruikerservaring, en betrokkenheid van gebruikers.
Maar één aspect mist nog. Hoewel on-site optimalisatie belangrijk is voor verbeterde snelheid, is dit niet het enige aspect waar we naar moeten kijken. De hardware en netwerkinfrastructuur die onze website ondersteunt en verbindt met onze bezoekers zijn ook van belang. Erg van belang.
Vandaag bespreken we waarom Google zoveel geld investeert in hun netwerkinfrastructuur en enkele van de verschillen tussen de Premium en Standard Tier binnen Google Cloud Platform.
Bandbreedte en wachttijd (kerncriteria voor de prestaties van hosting-infrastructuur)
Voordat we ingaan op de details van het netwerk van Google Cloud, is het noodzakelijk dat we twee begrippen goed begrijpen: bandbreedte en latentie.
Bandbreedte is de doorvoercapaciteit van een netwerk, gemeten in Mbps, terwijl latentie de vertraging is, of de som van alle vertragingen die onze webverzoeken oplopen bij de verschillende routers onderweg.
Ter illustratie kun je bandbreedte of doorvoercapaciteit zien als de capaciteit die een waterslang heeft om een bepaalde hoeveelheid water per seconde door te laten. Latentie kun je dan vergelijking met de vertraging tussen het moment dat je de kraan opent tot het moment dat er water uit de slang begint te spuiten.
Door de kleine overhead van het maken van een verbinding tussen verschillende routers, zorgt elke ‘hop’ onderweg voor een klein beetje vertraging van de uiteindelijke verzoeken en antwoorden.
Dus hoe verder de bezoeker en de host server van elkaar verwijderd zijn, hoe groter de latentie zal zijn. En hoe gefragmenteerder het netwerk onderweg is, hoe groter de latentie.
We kunnen dit in beeld brengen door middel van een tool die traceroute heet, of tracert bij Windows. In de volgende screenshots bekijken we de vertragingen van de routes van twee verzoeken, gedaan vanuit Europa. Specifiek:
één aan weibo.com:
En een andere aan bbc.co.uk:
Zoals te verwachten is, zijn er ongeveer twee keer zoveel hops nodig naar China dan naar de Europese website. Dit betekent dus meer latentie voor een verzoek dat gehost wordt in China ten opzichte van het Verenigd Koninkrijk.
De drie kolommen die tracert laat zien staan voor drie retourtrips (Round Trip Time). Elke rij geeft een router of hop onderweg weer. Er staan vaak URLs bij zodat we kunnen zien waar die specifieke router zich bevindt.
De tijd voor een retourtrip naar de routers in China/Hong Kong is bijna één derde seconde.
We gebruiken pingdom tools om een website te laden die wordt gehost in London, vanaf Pingdom’s locatie in Australië, om te bepalen wat het aandeel is van het netwerk in de totale laadtijd van een website.
In dit testscenario zijn de gegevens voor een klein CSS-bestand dat geladen wordt. Het ‘Connect’ onderdeel kost het meeste tijd om dit bestand te laden, gevolgd door ‘SSL’ en ‘Wait’. Alle tijden samen, inclusief de ‘Wait’-tijd, wordt meestal Time To First Byte (TTFB) genoemd, waar de netwerklatentie dus onderdeel van is.
Wanneer Internet Service Providers (ISPs) reclame maken met de snelheid van hun internetverbinding, doen ze dat meestal met hun bandbreedte (de breedte van de waterslang), wat eigenlijk niet echt de échte maatstaf voor snelheid is. Het breder maken van de pijp maakt deze slechts tot op zekere hoogte sneller. Dit is vooral handig als we een grote hoeveelheid data per seconde moeten versturen, bijvoorbeeld wanneer we een high-definition video aan het streamen zijn. Maar voor gebruikers die real-time online multiplayer games spelen heeft latentie een veel grotere invloed.
Mike Belshe, één van de co-auteurs van de HTTP/2-specificatie en het SPDY-protocol, heeft een analyse gemaakt van de impact van een grotere bandbreedte op de laadtijd van een website ten opzichte van een lagere latentie.
Hier is wat Belshe gevonden heeft in een mooi grafiekje:
Het moge duidelijk zijn dat het verbeteren van de snelheid van een website door de bandbreedte te vergroten niet de meest efficiënte manier is om betere prestaties te bereiken. Aan de andere kant zien we dat door de RTT of latentie te verlagen, er een consistente verbetering van de laadtijd van een website bereikt wordt.
Netwerken vs internet peering vs transit
Om dit onderwerp wat beter te begrijpen moeten we de basis van internet-topologie uitleggen. In de basis bestaat het wereldwijde internet uit meerdere wereldwijde, regionale en lokale netwerken.
In 2018 waren er meer dan 60.000 Autonomous Systems (AS). Deze netwerken zijn bijvoorbeeld van overheden, universiteiten en ISP’s.
Hierbij maken we verschil tussen Niveau 1, Niveau 2 en Niveau 3 netwerken. Deze niveaus staan voor de onafhankelijkheid van de netwerken ten opzichte van het gehele internet.
- Niveau 1 netwerken zijn onafhankelijk, in zoverre dat ze niet hoeven te betalen om verbinding te maken met enig ander punt op het internet.
- Niveau 2 netwerken hebben peering-afspraken met andere ISPs, maar moeten wel betalen voor de toegang.
- Niveau 3 netwerken, het laagste niveau, maken verbinding met het internet door toegang te kopen van de hogere niveaus. Dit zijn in feite consumenten die moeten betalen voor toegang tot het internet.
Het hebben van een ‘peering’ relatie betekent dat twee netwerken op gelijkwaardige wijze verkeer uitwisselen, zodat ze elkaar niet hoeven te betalen voor de toegang.
Het belangrijkste voordeel van peering is een drastisch lagere latentie.
In de afbeelding hierboven zien we een klassiek scenario, waarbij het webverzoek via het hiërarchische netwerk van ISPs gaat via niveau 1,2 en 3 om uiteindelijk een website op te kunnen halen dat gehost wordt in een datacenter op een locatie ver weg.
De pijlen verbeelden de weg die het webverzoek aflegt. De gestippelde pijlen staan voor de transitverbindingen en volle pijlen staan voor peering-verbindingen.
Zodra de niveau-1 provider is bereikt, is de relatie tot een andere provider op hetzelfde niveau een gelijkwaardige relatie. Niveau 1 netwerken verbinden met andere netwerken en sturen de verzoeken alleen door via gelijkwaardige partners. Ze kunnen alle andere netwerken op het internet bereiken zonder voor de toegang te hoeven betalen.
We zien ook een ander scenario, waarbij twee niveau-2 providers een peering-afspraak hebben, aangegeven met de turquoise kleur. Het aantal hops in dit scenario is lager, en daardoor kost het veel minder tijd om de website te laden.
Border Gateway Protocol
BGP is een protocol waar eigenlijk niemand het over heeft, behalve in bijzonder technische context. Het is echter een protocol dat deel is van het fundament van het internet zoals wij het vandaag de dag kennen. Het is fundamenteel voor de mogelijkheid om toegang te krijgen tot nagenoeg alles en het is ook één van de kwetsbare onderdelen in de stack van internetprotocollen.
Border Gateway Protocol is gedefinieerd in het Request for Comments #4271 van IETF in 2006 en heeft sindsdien een aantal updates gehad. Zoals de RfC zegt:
“De belangrijkste functie van een systeem dat BGP gebruikt is om informatie over de bereikbaarheid van een netwerk uit te wisselen met andere BGP-systemen.”
Om het wat eenvoudiger te zeggen is BGP een protocol dat de precieze route van een netwerkverzoek bepaalt, en beslist via welke van de duizenden knooppunten een verzoek reist.
We kunnen elk knooppunt afbeelden als een Autonomous System of als een netwerk dat zelf weer bestaat uit meerdere knooppunten of routers, servers, en systemen die daar mee verbonden zijn.
Binnen het Border Gateway Protocol bestaat er geen algoritme voor automatische ontdekking (een mechanisme of protocol waarbij elk nieuw knooppunt zelf ontdekt met welke nabijgelegen knooppunten het verbinding kan maken), maar moet elke BGP-peer zelf handmatig zijn eigen peers bepalen. Wat betreft het route-algoritme, zoals een Cisco-expert het eens zei:
“BGP heeft geen eenvoudige maatstaf om te bepalen welk pad het beste is. In plaats daarvan publiceert het een uitgebreide set van eigenschappen bij elke route, en gebruikt het een complex algoritme bestaande uit maximaal 13 stappen om te bepalen welk pad het beste is.”
Autonomous Systems versturen routing data naar hun peers, maar er zijn geen harde regels die gevolgd moeten worden voor wat betreft de selectie van de route. BGP is een systeem dat impliciet gebaseerd is op vertrouwen en dit zou wel eens van de grootste veiligheidsrisico’s kunnen zijn van het internet op dit moment. Een diefstal in 2018, toen het verkeer van MyEtherWallet.com gekaapt werd waarbij meer dan 200 Ether werden gestolen (met een waarde op dat moment van $152.000) liet deze kwetsbaarheid goed zien.
In werkelijkheid zorgt deze zwakte in BGP er vaker voor dat verschillende netwerken (AS) BGP-data versturen met andere belangen dan het verbeteren van de efficiëntie en snelheid van de eindgebruiker. Dit kunnen commerciële belangen zijn zoals betaald verkeer, maar ook politieke of veiligheidsbelangen.
Ontwikkeling van Cloud Computing, CDN, en de Edge-markt
Door de groeiende vraag vanuit de hele ICT-markt, van de web-industrie, online games, tot het Internet of Things (IoT) en dergelijke, kwam er steeds meer ruimte voor dienstverleners die het latentie-probleem oplossen.
Elk jaar zien we meer cloud-based producten die statische resources dicht bij de bezoekers cachen (via Content Delivery Networks) of de daadwerkelijke verwerking dichter naar de eindgebruiker brengen. Eén van dit soort producten is Workers van Cloudflare, die code uitvoert die compatibel is met de V8-javascript engine op het netwerk van edge-knooppunten van Cloudflare. Dit betekent dat zelfs WebAssembly of GO code dicht bij de gebruiker uitgevoerd kan worden.
Lambda@Edge van Amazon is nog een ander voorbeeld van deze trend, net als de samenwerking tussen Intel en Alibaba Cloud om een Joint Edge Computing Platform te gaan leveren, specifiek gericht op de IoT-markt.
Nog één die het vernoemen waard is, is het wereldwijde netwerk van caching-knooppunten van Google, dat zowel functioneert als een CDN als een video-caching en leveringsnetwerk voor dochteronderneming YouTube.
Om te laten zien hoe elegant en geavanceerd de cloud-sector tegenwoordig is, en in hoeverre al de netwerklatentie heeft teruggebracht voor eindgebruikers, kijken we naar GaaS.
GaaS staat voor Gaming as a Service. Het is een cloud-product dat gebruikers de mogelijkheid geeft om games te spelen die volledig gehost en uitgevoerd worden in de cloud.
Iedereen die ooit rondgekeken heeft voor een TV-scherm of projector om op te gamen, of bezig is geweest met het opzetten van Miracast of dergelijke casting-verbindingen tussen een TV en een ander apparaat, weet precies hoe cruciaal latentie eigenlijk is. Maar er zijn nu al GaaS-aanbieders die game streaming aanbieden op een resolutie van 4k met een 60Hz refresh rate… en de gebruikers hoeven niet eens zelf te investeren in hardware!
Het drama rond de recente ban op Huawei vanuit de VS liet duidelijk zien dat het probleem rondom 5G-netwerken opgelost moet worden. Het liet ook zien dat er een directe noodzaak is voor een duidelijke route naar het upgraden van de wereldwijde netwerk-infrastructuur.
Sensors die enorme hoeveelheden real-time informatie versturen met minimale vertraging, om smart cities, smart housing en autonomie voertuigen te coördineren zijn volledig afhankelijk van dichte netwerken van edge-apparaten. Latentie is op dit moment de grootste beperking voor zaken zoals zelfrijdende auto’s, die informatie van verschillende sensoren, LIDAR data en data van andere voertuigen moeten verwerken.
Content Delivery Networks en Cloud Computing Providers bevinden zich aan het front van deze race. We hebben het er al over gehad dat het QUIC/HTTP3 protocol momenteel uitgerold wordt door de leiders binnen de sector om de verzoek-antwoord-cyclus te kunnen beheren.
Hoe lossen cloud-providers het latentie-probleem op?
Amazon Web Services is op dit moment de grootste cloud provider op basis van marktaandeele. In 2016 investeerden ze in het Hawaiki Transpacific Submarine Cable System, gericht op het aanbieden van grotere bandbreedte en het verminderen van de latentie tussen Hawaï, Australië en Nieuw-Zeeland, wat hun eerste investering was in onderwater-infrastructuur. Het is in 2018 operationeel geworden.
Tegen die tijd was Google de competitie al ver vooruit met het aanleggen van hun onderwater-fundament. Een jaar voor de eerste investering van Amazon, publiceerde ITWorld een artikel met de titel: “De datacenters van Google groeien te snel voor de normale netwerken, dus nu bouwen ze hun eigen netwerken”.
In 2005 schreef tech-journalist Mark Stephens, ook bekend als Robert X Cringely zelfs al in zijn column op PBS.org het volgende over Google’s aankopen van dark fiber (aangelegde maar ongebruikte glasvezel-infrastructuur). Hij vergeleek de situatie met een groot Amerikaans internet-techbedrijf genaamd Akamai:
“Dit is nog groter dan Akamai of zelfs een Akamai die aan de anabole steroïden heeft gezeten. Dit is een dynamisch gedreven, intelligente, thermo-nucleaire Akamai met een exclusief back-channel en toepassingsspecifieke hardware. Er zal straks het Internet zijn, en daar bovenop zal het Google Internet zijn.”
En in 2010 in een artikel op zdnet.com, zei Tom Feromski:
“Google is één van de bedrijven die een groot deel van het internet bezitten” en hij gaat vervolgens door: “Google is gefocust op het bouwen van het meest efficiënte, goedkoopst te beheren, private internet. Deze infrastructuur is van groot belang voor Google, en het is de sleutel tot het begrijpen van Google.”
Op dat moment deed het artikel van Cringley vragen rijzen of Google van plan was om het internet over te nemen, maar alles werd wat duidelijker toen het bedrijf Google Fiber lanceerde, wat Google’s poging is om de ISP-markt in de grootste steden in de VS over te nemen. Het project is inmiddels wat afgekoeld, zelfs in zo verre dat TechRepublic in 2016 een soort lijkschouwing van het project publiceerde. Maar de investeringen, nu zelfs op wereldwijde schaal, zijn zeker niet afgekoeld.
De laatste investering van Google, die dit jaar operationeel zou moeten worden, is een hoofdlijn die Los Angelos in de VS verbindt met Valparaiso in Chili, met alvast een aftakking voor een toekomstige verbinding naar Panama.
“Het internet wordt vaak beschreven als een wolk. In werkelijkheid is het eigenlijk een verzameling natte, kwetsbare buizen, en Google bezit straks een alarmerend aantal van deze buizen.” — VentureBeat
Hoe lossen cloud-providers het latentie-probleem op?
We weten allemaal dat Google de belangrijkste zoekmachine is, maar ook dat het:
- Het grootste videoplatform bezit (YouTube)
- De grootste e-mailprovider is (Gmail en Google Workspace)
- Een heel behoorlijk inkomen heeft vanuit hun cloud-computing producten (jaarlijkse vaste omzet van meer dan 8 miljard dollar)
Dit is waarom het de kleinst mogelijke latentie en grootst mogelijke bandbreedte nodig heeft. Google wil ook de daadwerkelijke infrastructuur bezitten, omdat hun “onstilbare honger” naar meer bandbreedte en minder latentie Google, samen met soortgelijk grote bedrijven als Amazon of Microsoft, noodzaakt om volledig op maat gemaakte hardware- en softwareoplossingen te bedenken.
Points of Presence (PoP), of PoP edge knooppunten, zitten aan de rand van Google’s wereldwijde privé-kabelnetwerk. Ze dienen als in- en uitgangspunt voor verkeer dat verbinding maakt met de datacenters van Google.
De Wet van Moore, een constatering van Gordon Moore, mede-oprichter van Intel, stelt dat we elke twee jaar het aantal transistors op een enkele geïntegreerde chip zullen kunnen verdubbelen. Deze verwachting is tientallen jaren lang waarheid gebleken, maar de computer-industrie gaat de komende jaren de Wet van Moore voor een zware beproeving plaatsen, en waarschijnlijk binnenkort zelfs opheffen. Goed om te weten: de CEO van NVIDIA riep al uit dat de Wet van Moore dood is, eerder dit jaar.
Hoe verhoudt dit alles zich tot de cloud-sector en tot de netwerkinfrastructuur van Google?
Op het Open Networking Foundation Connect Event in december 2018 gaf de vice-president en TechLoad for Networking van Google, Amin Vahdat, toe dat de Wet van Moore ten einde was en legde ook de uitdaging van het bedrijf uit:
“Onze vraag voor rekenkracht blijft met een verbazingwekkende snelheid groeien. We gaan versnellers nodig hebben, en dichter gelinkte computers. De structuur van het netwerk gaat een vitale rol spel in het verbinden van die twee.”
Eén manier voor cloudproviders om bij te blijven met de steeds grotere vraag naar computerkracht is clusteren. Simpel gezegd is clusteren en samen laten werken van meerdere computers aan één probleem, om de processen van een enkele toepassing uit te voeren. Een voorwaarde voor een dergelijke installatie is natuurlijk het hebben van een lage latentie of serieuze netwerkcapaciteit.
Toen Google begon met het ontwerpen van hun eigen hardware in 2004, dachten verkopers van netwerkhardware nog in dozen, routers en schakelaars die allemaal individueel beheerd moeten worden via de command line. Tot dat moment kocht Google schakelaars per cluster van verkopers zoals Cisco, waarbij ze een fortuin uitgaven per schakelaar. En nog steeds kon de apparatuur de groei niet bijbenen.
Google had een compleet andere netwerkarchitectuur nodig. De eisen aan de infrastructuur van Google groeide exponentieel (een research paper van Google uit 2015 claimt dat hun netwerkcapaciteit in 10 jaar met verhonderdvoudigde) en dit was zo snel dat de kosten van het kopen van bestaande hardware ze dwongen om dan maar zelf hun eigen oplossingen te maken. Google begon met het bouwen van schakelaars op maat uit standaard siliconen-chips, waarbij ze een andere netwerktopologie gebruikten die meer modulair was.
De ingenieurs van Google begonnen met het bouwen op basis van een oud netwerkmodel voor telefonie, genaamd het Clos Network, die het aantal benodigde poorten per schakelaar beperkt.
“Het voordeel van het Clos-netwerk is dat je een aantal identieke en goedkope apparaten kunt gebruiken om de ‘boom’ te bouwen en zodoende hoge prestaties én robuustheid te krijgen die anders veel meer zou kosten.” — Clos Networks: Wat oud was, is nu weer nieuw, Network World
Voor deze nieuwe, modulaire hardware moest het team van Google de bestaande protocollen opnieuw definiëren, en een eigen Network Operating System bouwen. De uitdaging die ze hadden was dat het enorme aantallen schakelaars en routers moesten beheren alsof het een enkel systeem was.
De op maat gemaakte netwerk stack samen met de noodzaak voor het herdefiniëren van protocollen zorgde ervoor dat Google bezig ging met Software Defined Networking (SDN). Hier is een keynote uit 2015 door Amin Vahdat, de Vice President van Google, Engineering Fellow, en de teamleider voor netwerkinfrastructuur, die de uitdagingen en de gevonden oplossing uitlegt:
Voor de geïnteresseerde is er ook dit interessante blogartikel die zeker het lezen waard is.
Espresso
Espresso is de nieuwste pilaar van het SDN van Google. Het zorgt ervoor dat het netwerk van Google de beperkingen van fysieke routers achter zich kan laten voor wat betreft het identificeren en beheren van verkeer dat uitgewisseld wordt met de peering partners van Google.
Espresso zorgt ervoor dat Google de prestaties van een verbinding in realtime kan meten, en de beslissing voor de beste Point of Presence voor een specifieke bezoeker kan baseren op realtime data. Op deze manier reageert het netwerk van Google dynamisch op verschillende opstoppingen, vertragingen of uitval bij hun ISP en peering partners.
Daarbovenop maakt Espresso het mogelijk om Google’s distributed computerkracht te gebruiken om alle netwerkdata van hun peers te analyseren. Al het beheer betreffende routing en logica bevindt zich niet langer in de individuele routers door middel van het Border Gateway Protocol maar wordt nu gedaan door het computernetwerk van Google.
“We doen ons voordeel met onze grootschalige computing infrastructuur en signalen van de toepassing zelf om er achter te komen hoe individuele stromen presteren, zoals de eindgebruiker ze ervaart.” — Espresso maakt Google Cloud sneller, 2017
Hoe is dit alles relevant voor het Google Cloud Network?
Wat we tot nu toe hebben besproken helpt om de zorgen en uitdagingen (zowel qua hardware als software) uit te lichten waar Google oplossingen voor moest vinden om wat nu waarschijnlijk het beste wereldwijde private netwerk is te maken.
Voor wat betreft marktaandeel is Google Cloud Platform momenteel de derde op de wereldwijde markt (na AWS marktaandeel en Azure Cloud van Microsoft). Maar wanneer het gaat om premium private netwerkinfrastructuur, laat het de concurrentie vér achter zich, zoals te zien is in de data van BroadBand Now:
In 2014 publiceerde GigaOM een artikel dat AWS en Google Cloud Platform vergeleek, maar een week later publiceerden ze nog een artikel, met de titel: “Wat ik over het hoofd gezien heb in de Google vs Amazon cloud-discussie: glasvezel!” waarin ze erkennen dat Google op dat moment de concurrentie al jaren vooruit is voor wat betreft infrastructuur.
“Het beschikbaar hebben van grote, snelle buizen voor jouw verkeer — en dat van je klanten — heeft een enorme invloed.” — Barb Darrow, GIGAOM
De Premium Tier vs Standard Tier bij Google Networks
Google Cloud Platform biedt twee verschillende niveaus qua netwerk aan die verschillen qua prijs en prestaties.
Google Premium Tier Netwerk
Met de Premium Tier van Google kunnen klanten gebruik maken van het wereldwijde glasvezelnetwerk, met wereldwijd verspreide Points of Presence. Al het inkomende verkeer van de klant naar de datacenters van Google gaat via het dichtstbijzijnde Point of Presence, die over de hele wereld verspreid zijn, en vervolgens wordt het verzoek 100% afgehandeld via Google private hoofdlijnen. Zoals we in een eerder artikel al noemden – dat kan wel 30% minder latentie of 50% betere bandbreedte betekenen.
Op de terugweg wordt alle data die van het datacenter naar de bezoeker gestuurd op basis van het Cold Potato protocol. Hierbij wordt uitgaand verkeer zo lang mogelijk op de eigen glasvezel van Google gehouden, tot het zo dicht mogelijk bij de bezoeker overgedragen wordt naar peers of ISPs. Dit in tegenstelling tot Hot Potato routing dat gebruikt wordt op het Standard Tier-netwerk, waarbij het verkeer juist zo vroeg mogelijk wordt overgedragen aan andere ISPs.
Of in normale taal: pakketten van de Premium Tier bevinden zich langer op het netwerk van Google, met minder hops onderweg, en hebben dus veel betere prestaties (tegen hogere kosten).
De sci-fi fans onder ons kunnen het vergelijken met een kosmisch wormgat, dat ons verkeer direct naar de bestemming brengt in plaats van dat het over het internet zwerft.
Bij Kinsta gebruiken we het Premium Tiernetwerk van Google Cloud bij alle hostingpakketten. Dit minimaliseert zowel afstand als hops, waardoor je data veiliger en sneller getransporteerd wordt.
Google Standard Tier netwerk
Aan de andere kant gebruikt het Standard Tier netwerk Points of Presence dichtbij het datacenter waar de content of web-app zich bevindt. Dit betekent dat het verkeer van een bezoeker via een lading verschillende netwerken, Autonomous Systems en ISPs reist, en dus veel hops maakt voor het bij de bestemming aankomt. Op deze manier heeft de snelheid erg te lijden.
Content die via de Standard Tier reist zal niet de voordelen hebben van Google’s SDN en de enorme rekenkracht die gebruikt wordt om de beste routes te berekenen. Verkeer wordt beheerd door de standaard BGP-regels van alle systemen tussen Google en de bezoeker.
Of weer in normale taal: pakketten van Standard Tier bevinden zich korter op het netwerk van Google, en langer op publieke netwerken en krijgen dus veel slechtere prestaties (maar kosten ook minder).
Daarnaast gebruikt de Premium Tier Global Load Balancing, terwijl de Standard Tier alleen maar Regional Load Balancing gebruikt, wat zorgt voor meer complexiteit en ‘voetenwerk’ voor Standard-klanten.
Premium Tier Network biedt een wereldwijde Service Level Agreement (SLA), wat betekent dat Google contractuele verantwoordelijkheid aanvaardt om een bepaald serviceniveau te leveren. Het is als een teken van kwaliteitsgarantie. Standard Network Tiers bieden dit SLA niveau niet.
Voor mensen die meer willen weten is er een vrij uitgebreide vergelijking met documentatie van de twee tiers op de website van Google Cloud. Ze geven je zelfs een handig overzichtje om te bepalen welk niveau het beste voor jou is:
Samenvatting
Jarenlang heeft Google geïnvesteerd om een wereldwijde netwerk-infrastructuur aan te leggen, waarbij ze hun eigen protocollen en op maat gemaakte hardware en software gebruikten. Nu de Wet van Moore steeds minder op lijkt te gaan, zorgt de infrastructuur van Google ervoor dat het bedrijf de immer groeiende vraag naar cloud-resources bij kan blijven benen.
Alhoewel het qua marktaandeel nog achterloopt op Amazon Cloud en Azure Cloud van Microsoft, heeft Google nu een groot voordeel vanwege het bezig van hun glasvezel, naast de hypermoderne hardware en software die hun ingenieurs hebben ontwikkeld.
We voorspellen dat Google een sleutelrol zal spelen in de technologie rondom IoT, smart cities, autonome voertuig en in de groeiende vraag naar edge-computing.
De Premium Tier van Google Cloud Network is het eerste product dat gebruik maakt van Google’s innovatieve prestaties op netwerkgebied. Het zorgt ervoor dat klanten hun voordeel kunnen doen met het netwerk en de stack van Google om hun content op premium snelheid bij hun bezoekers te krijgen. Terwijl Google ondertussen garanties geeft betreffende de latentie.
Kinsta is toegewijd aan het aanbieden van de beste applicatie hosting, database hosting en managed WordPress hostingprestaties wereldwijd. Daarom wordt Kinsta aangedreven door Google Cloud hosting en gebruiken we Google’s Premium Tier Network voor al onze hostingpakketten. We gebruiken Google Cloud Network voor ál onze hostingpakketten.
Tonino is een ondernemer, Linux & OSS enthousiasteling, developer en tech-educator. Hij heeft meer dan tien jaar ervaring in development en is al meer dan 3 jaar actief in de blockchain-wereld. Als hij niet aan het coderen is, schrijft hij voor SitePoint en Alibaba Cloud, kijkt hij de nieuwste fictie op Netflix en verkent hij nieuwe reisbestemmingen.
Laat een reactie achter