Het is tijd voor iets nieuws, maar niet zonder eerst terug te blikken. De afgelopen twee jaar heb ik een mooie inkijk gekregen in het toch wel bijzondere wereldje van hostingbedrijven. Want ondanks dat zoiets als websitehosting een commodity is geworden, blijven veel ondernemingen uitermate afhankelijk van de kwaliteit, kunde en expertise die hostingbedrijven bieden.
Hieronder vind je vijf aspecten inzake webhosting waarvan ik vind dat iedereen die professioneel met websites bezig is, op de hoogte moet zijn:
1. Vergeet 100 procent uptime
Zowat alle hosters pakken uit met een fantastische uptime: minimaal 99,99x procent! Hoe meer negens, hoe beter. En ja, zoiets wekt heel wat vertrouwen op. Besef echter dat uptimebeloftes vooral … tja, beloftes zijn. Uiteindelijk is de praktijk de enige graadmeter. En geloof me, downtime is iets waar hosters liefst zo weinig mogelijk over communiceren. Sommige downtimes worden zelfs niet opgemerkt, niet door de hoster noch door de klant, bijvoorbeeld omdat ze ’s nachts plaatsvinden, of omdat ze te kort en/of occasioneel zijn.
De door een hoster beloofde uptime moet je bovendien correct weten te interpreteren. Een hoster stelt immers niets meer dan dat zijn (en énkel zijn) infrastructuur beschikbaar zal zijn gedurende de beloofde minimumtijd. Klinkt nog altijd goed, niet? Maar vertaal je dat naar de behoefte van de klant, dan staat daar eigenlijk:
… dit wil NIET zeggen dat JOUW website eveneens 99,xxx procent van de tijd online is!
Het kan immers perfect dat vanuit infrastructuurstandpunt (het netwerk, de servers, zelfs de webserversoftware) alles werkende is, maar dat een website toch niet (goed/snel) laadt. Voor de hoster is er niets aan de hand, maar jij zit wel met de gebakken peren. Daar sta je dan met je uptime. Hosters monitoren dan ook in de eerste plaats de status van de onderliggende infrastructuur, en niet of die ene belangrijke bestelpagina van je webshop laadt.
Sorry, telt niet mee
En dan zijn er nog de vele uitzonderingen. Zaken die een doorsnee webhoster niet beschouwt als zijnde vallende onder de beloofde uptime, maar die wel degelijk hun impact hebben. Denk maar aan al dan niet gepland onderhoud aan de infrastructuur, menselijke fouten (ook door de klant!), onverwachte pieken, externe oorzaken (netwerkroutering) en overmacht (een aanslag of ongeval). Allemaal zaken die een hoster doorgaans zal uitsluiten bij het berekenen van de werkelijke uptime. Trouwens, zonder eerst een dure SLA (zie punt 2) af te sluiten, zul je zelden of nooit aanspraak kunnen maken op enige vergoeding als de uptime niet gehaald wordt.
Slimme webmasters voorzien zelf monitoringtools die vanaf een of meerdere externe locaties de werking van de website continu in de gaten houden. Zelf gebruik ik o.a. Pingdom, met zijn handige uptime-rapportjes en de mogelijkheid om laadtijden van webpagina’s te monitoren. Gewapend met dat soort harde data kun je trouwens gemakkelijker naar je hoster stappen om beschikbaarheidsproblemen aan de kaak te stellen.
2. Aan een SLA heb je niks. Totdat…
De fameuze service level agreement of SLA. De oplossing voor al je uptime-problemen volgens niet-ingewijden.
Zucht…
Hoe vaak ik niet een potentiële klant aan de lijn heb gehad die per sé een SLA bij zijn product wou. Omdat het management dat eiste. En enerzijds kudos, want een SLA is absoluut iets om over te denken… zolang je maar weet waar je over praat.
Een SLA formaliseert immers de verwachtingen (uptime) en procedures die gelden bij probleemsituaties, en de eventuele schadevergoedingen die daar uit voortvloeien. Een soort van verzekering dus, en voor bedrijfskritische e-commerceapplicaties toch wel een must. Maar uiteindelijk geldt voor een SLA hetzelfde als voor de uptime: veel beloftes, maar pas als het serieus misgaat weet je wat een hoster echt waard is.
Beheerders van websites kan ik alleen maar adviseren om naast de SLA, minstens even goed na te denken over zaken zoals business continuity en disaster recovery. Wat als het allerergste gebeurt? Je zal verbaasd staan over het aantal mogelijke rampscenario’s en hun gevolgen. En laat de hoster gerust reageren op een aantal van die scenario’s, en vraag naar zijn disaster recovery-plan als hij dat heeft.
Overigens ga ik er bij dit alles van uit dat de hoster wel degelijk zijn zaakjes op orde heeft als het op infrastructuur aankomt, en je als klant kunt rekenen op een stabiele, performante en veilige omgeving. Durf daarbij doorvragen over de onderliggende infrastructuur waar je webapplicaties op gehost worden. Hoe transparanter de hoster voor de dag komt, al dan niet met een geheimhoudingsverklaring, hoe beter.
3. Zorg zelf voor back-ups
Data is heilig. Wis dus nooit data. En als de dag komt dat je toch data nodig hebt uit het verleden… wat dan? Heb je zelf back-ups gemaakt? Nee?! Je hoster wel? Ja, oef! Maar: hoe oud zijn die back-ups? En wat kost het, zowel in tijd als geld, om de boel terug werkende te krijgen?
Toen ik nog redacteur voor Clickx was, schreef ik zowat om de maand over hoe back-ups te maken. Nuttige info, ongetwijfeld, maar tegelijkertijd besefte ik dat slechts een minderheid zich om zoiets banaals als back-ups bekommert. En met de komst van de cloud, heb je toch geen nood meer aan back-ups?
Fout!
Met de komst van de cloud heb je geen excuus meer om geen (extra) back-ups te voorzien. Goedkope opslagdiensten zijn er genoeg. En veel is te automatiseren. Ik kan daarom alleen maar adviseren om naast de back-updiensten die de hoster zelf aanbiedt, hoe goed en betrouwbaar deze ook moge zijn, nog altijd een eigen back-up te voorzien… just in case. Zelf gebruik ik daarvoor Managewp.com, dat niet alleen WordPress back-ups maakt en deze op Google Drive of Dropbox bewaart, maar ook de sites en plug-ins kan updaten. Wat er ook moge gebeuren met mijn data, ik heb altijd een (tweede, derde, tigste) versie beschikbaar op een eigen, onafhankelijke locatie.
4. Jouw webdeveloper suckt (wellicht) als het op schaalbaarheid aankomt
In tip 1 over de uptime heb ik dit al aangehaald, maar toch vind ik het de moeite om er wat dieper op in te gaan. Wanneer een website down gaat, is dat heel vaak omdat de server het niet meer “aankan”. Dé remedie is dan om simpelweg meer geheugen en/of meer rekenkracht te voorzien… tot de server een volgende keer onderuit gaat.
Een webhoster zal je maar al te graag een zwaardere server verkopen. Want daar leven ze uiteindelijk voor een deel van.
Zwaardere (en duurdere) servers zijn echter maar een deel van de oplossing.
Een veelgehoorde klacht op de helpdesk van een hoster: “mijn website is traag!”. Natuurlijk begint alles met een goed uitgekiend hostingplatform en voldoende resources, maar heel vaak blijkt de website zelf gewoon te log te werken (b.v. tig plugins en modules), en slibt alles vast zodra het aantal gelijktijdige bezoekers toeneemt. Ook inefficiënte databasequeries zijn dagelijkse kost. Zoiets merken website-eigenaars pas als de website plots meer volk trekt, en dan is het vaak te laat om de code ingrijpend aan te passen. En zo zijn we terug bij af: snel wat extra serverresources bijprikken, en we kunnen er weer tegen, nietwaar?
In mijn hostingcarrière heb ik echter vaak het tegenovergestelde advies durven geven: in plaats van duurdere servers, steek je je geld beter (of: eerst) in een webontwikkelaar die weet hoe je een slimme, resource-efficiënte, en dus schaalbare applicatie bouwt. Onnoemelijk veel factoren spelen daarbij een rol, en het viel me op dat heel wat webbouwers noch de ervaring noch de kennis in huis hebben om de schaalbaarheid van een website op langere termijn, te garanderen. Overigens zal een hoster je al snel aanraden om waar mogelijk cachingtechnieken te gebruiken wanneer een website slecht presteert. Maar ook daar is de nodige kennis voor nodig.
Mijn advies: laat in het lastenboek of offerte van de website gedetailleerd de maximale laadtijden bij een bepaald aantal gelijktijdige bezoekers opnemen. Zo ben je van in het begin zeker dat de ontwikkelaar aandacht besteedt aan optimalisaties.
5. Eigen land eerst
Je zou denken dat in een geglobaliseerde markt zoals die van de cloud, de fysieke locatie van de hosting niet bijster veel uitmaakt. Het tegendeel is echter waar. Zo is een Belgische website hosten in een Amerikaanse datacentrum niet optimaal, tenzij je veel Amerikaanse bezoekers hebt. Datacommunicatie mag dan wel aan lichtsnelheid gebeuren, bij zo’n grote fysieke afstanden zitten er uiteraard meer tussenstations, en dat heeft vertragingen tot gevolg.
Een en ander hangt daarbij ook af van de netwerkconnectiviteit die de hoster biedt, maar de algehele regel blijft dat hoe groter de fysieke afstand tussen server en bezoeker, hoe trager de netwerkverbinding reageert. Zeker in bedrijfskritische omgevingen telt elke milliseconde. Gelukkig valt voor internationaal druk bezochte websites veel te fixen, denk maar aan het opzetten van een content delivery network (CDN).
Naast connectiviteit speelt ook de plaats van de opslag van data een belangrijk rol bij de keuze van cloudprovider. Waar je data zich fysiek bevinden, is niet bij elke hoster helemaal duidelijk, laat staan wie er allemaal toegang toe (kan) krijg(t)(en).
Deze bijdrage verscheen eerder op de website van Bart Stoffels.
