Een cloudprovider kiezen

Bij het kiezen van een cloudprovider kun je kijken naar merkherkenning, beveiligings- en opslagfuncties en andere items. Maar cloudproviders zijn net als de rest van ons afhankelijk van netwerken, en ze zijn niet allemaal gelijk gemaakt of geconfigureerd.

Over het algemeen is het voor degenen die de cloud overwegen belangrijk om de locatie van uw eindgebruikers en de cloudlocatie die hen zal bedienen op elkaar af te stemmen. U moet er ook naar streven om de prestaties continu te baseren wanneer u voor het eerst met een cloudprovider aan de slag gaat, wat u op weg helpt als er prestatieproblemen zijn.

Aangezien elk van de grote cloudproviders meerdere aanwezigheidspunten heeft, is het van cruciaal belang dat u rekening houdt met de netwerkimpact van het verplaatsen van uw gegevens of apps uit uw kantoren naar de cloud. Om deze impact te illustreren, hebben we een snelle vergelijking gemaakt van de drie belangrijkste providers.

Testen, testen

Om een ​​kijkje te nemen onder de dekens van de grote drie providers, hebben we wat tests gedaan. We hebben een SaaS CRM-demosysteem opgezet in de noordwestelijke point of presence (exacte locaties verschillen per provider) voor de drie grootste public cloud providers:AWS, Azure en Google Cloud. Daarna hebben we gewacht tot de resultaten binnenkwamen, en ze waren zeker interessant.

Testen vanuit Los Angeles

Deze afbeelding hieronder toont netwerkverkeer van Los Angeles naar de dichtstbijzijnde locatie van de grote providers in de noordwestelijke regio. Met onze op het noordwesten gebaseerde CRM is er echt geen duidelijke winnaar. Google en AWS bevinden zich in het naburige Oregon, terwijl Azure zich op korte afstand van hen bevindt in Noord-Californië. Hier wint AWS misschien gewoon, maar ze vertonen allemaal extreme variabiliteit in de loop van een maand (lager is hier beter). Het verschil in fysieke afstand manifesteert zich niet volledig als extra netwerktijd voor webverzoeken (ter referentie, het duurt 40 ms voor cross-country verkeer). Wat hoogstwaarschijnlijk gebeurt, zijn wijzigingen in de routering.

Los Angeles → Regio noordwest  | AWS  | Azuurblauw  | Google

Testen vanuit Atlanta

Dit volgende voorbeeld toont de netwerkroutes van de drie providers vanaf onze monitor in Atlanta naar de noordwestelijke aanwezigheids- of beschikbaarheidszones. AWS is de langzaamste cloudprovider, hoewel ze alle drie variabiliteit ervaren gedurende de periode van een maand. Met een veel langere fysieke scheiding tussen synthetische gebruiker en server, kunnen we kleine variaties in netwerksnelheid negeren. Wel is duidelijk dat AWS last heeft van gemiddeld 1,5 seconde extra latency. De oorzaak kan verschillend zijn, maar met tot twee seconden extra tijd voor webverzoeken kan dit leiden tot meer frustratie bij gebruikers. We zien ook enige consistentie in de waargenomen pieken, wat aangeeft dat het verkeer routes en dagelijkse congestieproblemen kan delen.

Het is belangrijk om te onthouden dat onze implementatie in Seattle waarschijnlijk niet de ideale, noch gebruikelijke keuze is voor een in Atlanta gevestigd bedrijf. Maar met zoveel startups die uit de regio van Silicon Valley komen, is de kans groot dat veel SaaS-apps die je elke dag gebruikt deze lange reis maken.

Atlanta → Regio noordwest  | AWS  | Azuurblauw  | Google

Testen vanuit New York

Ons laatste voorbeeld hieronder toont de netwerkprestaties langs het netwerkpad van de New York-zone naar onze in het noordwesten gebaseerde CRM. AWS laat nog steeds de traagste reactietijden zien van de drie providers. Google en Azure zijn constant sneller, afgezien van één congestieprobleem dat eind januari werd waargenomen. Omdat we kunnen aannemen dat het internet in de loop van de tijd veel van dit verkeer op dezelfde manier door het land zal sturen, is er een goede indicatie dat routering achter de firewall van AWS de oorzaak kan zijn van de extra latentie.

New York → Regio noordwest  | AWS  | Azuurblauw  | Google

Wat onze cloudtests hebben gevonden

We hebben geen grote steekproefomvang en onze testimplementatie is niet aangepast aan de complexiteit van de meeste moderne apps, maar onze resultaten herinnerden ons eraan hoe belangrijk het is om locatieonderzoek te doen wanneer u uw cloudimplementaties plant. Bekijk de kaart om te zien waar uw services en apps zich bevinden wanneer ze zich in de cloud bevinden. Koppel ze vervolgens aan waar de gebruikers van die apps en services zijn.

Er zijn een aantal redenen die kunnen bijdragen aan wat lijkt op een falen van AWS om snelle reacties te leveren, zoals peering-overeenkomsten in het midden van het land of extra routering achter hun firewall. Wat wel duidelijk is, is dat de prestaties verschillen afhankelijk van waar uw eindgebruikers zich bevinden. Als u zich hiervan bewust bent, leidt dit tot betere beslissingen als het gaat om prestaties.

Het testen van cloudproviders is niet ons enige doel, maar u kunt de zichtbaarheid krijgen die we hebben (en nodig hebben) met AppNeta's tools voor al uw cloud-apps. Dit soort netwerkinzicht kan de dag redden wanneer gebruikers klagen over vertragingen of storingen en u de hoofdoorzaak van prestatievermindering moet identificeren.