Årh … *suk* … kunder!

Jeg blev for nogen måneder siden hyret ind til en webshop der skulle have hjælp til noget markedsføring … de vidste faktisk ikke rigtig hvad de solgte, og de havde ikke overblik over hvor de tjente deres penge og slet ikke over resultatet af deres noget spontane seo arbejde.

Jeg arbejdede meget med dem, og forsøgte at få dem til at tage nogle beslutninger ifht. fokus-områder men det var svært for kunden var ikke selv særlig IT Kyndig, og desuden også enormt konservativt anlagt.

Så her for et par måneder siden ringer kunden pludselig til mig og meddeler at “Den nye webshop skal snart online, så de skulle lige bruge adgangskoden til DNS Serveren” … og så sad jeg der som et spørgsmåltegn “Øhh … hvilken webshop?”

Det viste sig at de havde hyret en eller anden tilfældig gut til at bygge en webshop … fuldstændig uden at konsultere den marketingskonsulent som de allerede havde betalt for (mig).

Jeg fik sat et møde op, og kom ud og kigge på det. Shoppen var som sådan god nok, deres URL Struktur var helt hen i vejret og jeg sagde til dem at de skulle få ham til at sørge for at den nuværende URL Struktur skulle bibeholdes – “Jaja … det skal vi nok få ham til at sørge for”

Så for et par uger siden blev jeg ringet op, og blev bedt om DK-Hostmaster koderne … det viste sig at den her nye webfyr de havde ansat ville hoste webshoppen i holland og gemme den bagved Cloudflare … det undrede mig lidt, så jeg tog kontakt til ham for at høre hvordan serveren var sat op … og den her stakkels mand gik i forsvars-mode med det samme, det var klar for mig, og tilsyneladende også for ham at han var kommet ud hvor han ikke kunnde bunde og han begyndte at bortforklare og komme med alle mulige undskyldninger for hvorfor han ikke ville svare på mine spørgsmål.

Det endte dog med at han lovede at sende en mail “i næste uge”. Men ligeså snart han havde lagt på ringede han til kunden, og afleverede en flæbe-historie til kunden om at jeg hindrede hans arbejde, og kunden ringede til mig og skældte ud … så måtte jeg forklare kunden at når en leverandør tilbageholder den slags detaljer så svarer det til at købe et hus uden tilstandsrapport.

Jeg forklarer kunden hvorfor det er afgørende at vi får styr på de her ting, men det ser ikke ud til at kunden forstår det. Men jeg får ham da forklaret at webmanden har lovet at sende mig de detaljer i løbet af ugen og at jeg forventer at alt falder på plads når først vi har fået styr på de ting.

Webfyren sender dog ikke de detaljer som aftalt, og da jeg rykker for dem kommer der en besked om at han holder nytårsferie. Jeg informerer selvfølgelig kunden om dette, og skriver samtidig at jeg tager sagen op igen efter nytår.

Idag har jeg så opdaget at de har kørt den nye side online hen over hovedet på mig … og jeg må sku indrømme jeg forstår det ikke, de _har_ betalt for mine ydelser, jeg har fået flere penge en webmanden har fået for at lave webshoppen … alligevel lader de sig tage ved næsen i fuld dagslys på trods af at jeg står ved siden af og fægter med arme og ben og forsøger at advare dem …

Sometime i really don’t get people!

Heldigvis har jég da fået min betalingen, så jeg kan jo i princippet være ligeglad.

Hjælp … jeg er blevet populær.

Når dit website vokser dig overhovedet kommer det typisk bag på dig, det er ikke en situation du har forberedt dig og du har nu fået en mail fra dit webhotel med beskeden om din konto er suspenderet fordi du enten har brugt for meget trafik eller overbelastet serveren.

En anden mulighed er slet og ret at dit site begynder at blive så langsomt at dine brugere klager, og måske endda begynder at forlade siden. Det er selvfølgelig ikke rart, så hvad gør man for at løse problemet?

Den typisk fejl folk begår er at skifte til et andet, lidt større og måske lidt bedre webhotel hvorefter der går et par uger eller måneder indtil det hele gentager sig igen, som almindelig forbruger eller sågar som teknisk dygtig programmør kan det være svært for ikke at sige umuligt at vurdere kvaliteten på et tilfældigt webhotel.

En anden typisk fejl er at gå ud og leje den størst mulige server, og flytte din side derover. Det skal nok hjælpe i starten, primært fordi du pludselig har alle maskinens resourcer for dig selv, du vil opleve at størstedelen af din maskine slet ikke bruges eller at siden stadig er langsom selvom der er mange resourcer tilbage.

Det kan lidt sammenlignes med at købe en racerbil og så sætte din 7 årige søn til at køre i den, der er en ret go chance for at han ikke får den til at køre og hvis endelig han gør ødelægger han både sig selv og bilen.

Du bør selvfølgelig starte ud med at konsultere en person der har forstand på at køre racerbilen, og på samme måde skal du selvfølgelig også søge eksperthjælp når du skal have dit website til at bryde hastighedsgrænserne på internettet. En dårlig opsat dedikeret server eller virtuel server kan faktisk performe dårligere end et ganske almindeligt discount webhotel.

En anden observation man også er nødt til at gøre sig, hvad sker der den dag dit website kører på den størst mulige server med den størst mulige internet forbindelse med så meget ram som dit operativsystem kan håndtere … og du bliver ved med at få flere kunder og få højere og højere belastning på maskinen.

For at det hele ikke bare er metaforer vil jeg gennemgå nogle eksempler på hvad man rent praktisk kan gøre, og kort nævne et par fordele og ulemper:

  • Finjustering af serveren resourceforbrug, der er ikke nogen endelig løsning i din specifikke situation kan det være at din database kræver flere resourcer end din webserver, eller omvendt. Der er nødt til at foreligge en analyse af din applikation og dens resourceforbrug før der kan laves et brugbart estimat. Efterfølgende er man nødt til at finjustere løbende under drift.
  • Fordeling af roller til flere servere, det klassiske råd er at skille webserveren fra databasen og på den måde opnå flere resourcer end én fysisk maskine kan levere, men du rammer igen et problem når du så har brugt alle resourcer på begge maskiner og du ikke kan købe større maskiner.
  • Cluster setup med flere servere til hver rolle, en anden løsning er at sætte hhv. 2 eller flere database og webservere op, på den måde kan du skalere din løsning ved at tilføje flere maskiner af samme størrelse som din nuværende, du kan vælge at opgradere der hvor det giver mening og lade de dele som klarer sig fint være. Den største ulempe ved et cluster setup er at det er utroligt komplekst og typisk kræver en del tilpasning.
  • Flere forskellige former for cache, en cache er et midlertidigt lager hvor man opbevarer ting midlertidigt for hurtigt at kunne finde dem igen. Der findes flere forskellige caching teknikker og de har alle hver deres fordele og ulemper. Det er f.eks. muligt at sætte en række serveren foran webserverne som laver hjælper med at aflaste serverne, hvordan disse performer og generelt påvirker din applikation afhænger 100% af deres opsætningen.En anden mulighed er at installere en op-code cache som f.eks. APC, når webserveren udfører en PHP Fil skal den første fortolke alle kommandoerne i filen og oversætte dem til maskin-kode som serveren CPU kan forstå. Denne process foretages hvergang en PHP fil skal udføres, uanset om indholdet af filen er ændret eller ej. Dette er selvfølgelig et spild af resourcer og det er netop her en opcode cache kommer ind, den husker oversættelsen og genbruger den hvis der er behov for det. Det giver et enormt performanceboost på PHP tunge sider og det giver stort set ingen problemer.
  • Optimering af kildekoden og databasen, selv dygtige programmører laver dårlig kode, og dårlige programmører laver forfærdelig kode. Jo længere tid et projekt er under aktiv udvikling desto mere forværers koden og jævnlig oprydning er nødvendig. Tillæg dertil at de typiske iværksætter-projekter er startet eller udviklet af et par unge knægte, eller ihvertfald nogen som ikke er specialister indenfor deres felt. Det kan være ganske udemærket, men det kan sammenlignes lidt med at bygge et højhus på et fundament af halm og ler.Med andre ord er der næsten altid ydelse at hente i koden, og typisk vil der være behov for løbende at omskrive større eller mindre dele af koden, og det typiske tidspunkt at påbegynde dette arbejde er netop når den første opgradering, til f.eks. en virtuel server, er begyndt og man så småt begynder at øjne behovet for skallering i fremtiden.
  • Cloudløsninger og andre sky-basserede services, du har helt ret, det ligner ikke mig og bruge buzz-words, og pointen med det her punkt er også at afvise at “skyen” er svaret på alle dine bønner. For det første er sky ikke et fast defineret fagligt udtryk og det er derfor noget vrøvl at bruge det som sådan, det er derimod et buzzwork sælgere bruger for at lyde moderne. Alle steder du hører ordet “sky” eller “skyen” kan du sætte “internet” eller “internettet” ind i stedet, og på den måde afkode hvad din sælger forsøger at sælge dig.Lad mig slå det fast, Amazon, Microsoft Azure og den million af små private cloud-udbydere der skyder op verden over er direkte at sammenligne med en klassisk hosting udbyder der udlejer fysiske og virtuelle servere. Forskellen er 80% markedsføring og 20% smarte web-kontrolpaneler.Så ja, du kan sagtens bruge cloud til at løse dit problem, men det er kun en del af løsningen, alt ovenstående er stadig aktuelt uanset om du bruger en udbyder der kalder sit udstyr for en/flere serverpark(er) eller en/flere sky(er)

I min forretning har vi valgt at kombinere rådgivning og drift, således at vi kan designe en komplet hostingløsning og enten levere en projektplan eller slet og ret implementere den og servicere den for kunden, derudover har vi etableret professionel redundant hostingservice i Danmark, og hvis kunden har behov for hosting i udlandet har vi flere forskellige faste partnere vi trækker på. 

Det vigtige er altså ikke hvilken udbyder man vælger, men hvem man vælger til at administrere løsningen og hvordan man gør det.