Cases

En anden af vores helt store kundegrupper er webbureauer, hvor vi ofte har fungeret som underleverandør på den tekniske side at større projekter, det har udmøntet sig i en lang række opgaver indenfor specialudvikling. Typisk er scenariet at webbureauet sørger for den visuelle side af leverancen mens vi tager os af det bagvedliggende, eller i hvert fald de dele som webbureauet ikke selv er i stand til at løfte.

I samarbejde med en af vores mangeårige kunder, udviklede vi således en betalingsløsning for et af landets store pensionsselskaber. Der var ønske om at kunne lade kunderne foretage frivillige ekstraindbetalinger. Sådan et system indeholder selvsagt en masse personoplysninger. Selvom det var før GDPR var både vi og kunden selv meget opmærksomme på sikkerheden, og løsningen blev derfor udviklet med security og privacy first-principperne.

Løsningen blev bygget i 3 lag, der hver især var adskilt på hver sin fysiske server med et sikkerhedslag imellem. Først var der selve databasen og den omkringliggende business logic der lå isoleret på en krypteret server bag selvstændig firewall og vpn, denne eksponerede to forskellige API’er, der kommunikerede med de to andre lag.

Disse API’er stod for kommunikationen mellem hvert sit lag, henholdsvis kunde- og medarbejderlaget, og de webinterfaces de respektive brugere havde adgang til. Det betød at en successfuld angriber aldrig ville kunne få adgang til andre data end dem den aktuelt indloggede bruger i forvejen havde adgang til.

Medarbejdernes webinterface var udelukkende tilgængeligt fra virksomhedens interne netværk og brugte en anden indgang til databaselaget som var beskyttet med både firewall og kryptering af transportlaget.

Den utrolige popularitet der er tilfaldet WordPress de senere år har resulteret i rigtig mange sirlige og anderledes projekter bygget i eller udenomkring WordPress. Vi har været med siden starten af 00’erne og har både lavet WordPress-integrationer, plugins og hele koncepter baseret på WordPress.

Eksempelvis har vi for en af vores Software As A Service-kunder udviklet et WordPress shop-plugin der tillod deres kunder at udbyde onlinebestilling via deres almindelige WordPress-sites.

Selve pluginnet var sådan set kompliceret nok at skrive, det benyttede en kombination af et template-system og af shortcodes så kunderne selv kunne tilpasse designet. Det var designet på en måde så kunderne nemt selv kunne implementere integration med en fremmed betalingsgateway uden at risikere pluginnets integritet i forbindelse med opdateringer.

Nu vi er ved opdateringer, så byggede vi også et private repository til virksomheden. Altså et system hvorfra virksomhedens plugins, og opdateringer hertil, kunne distribueres automatisk ud til de betalende kunder.

For en anden kunde byggede vi et komplet online, branchespecifikt, annoncekatalog. Pointen var at udbydere af ydelser, i den givne branche, kunne oprette annoncer på sitet – virksomheden bag ville så promovere hele sitet, blandt andet i Google.

En af de helt store udfordringer her var at bygge en dynamisk URL-struktur, kunderne skulle selv kunne oprette og slette annoncer – man ønskede således ikke at bruge WordPress’ egen metode til at oprette indhold. Kunden havde haft kontakt til flere WordPress-specialister som meldte ud at det ikke var muligt, men efter et par ugers arbejde lykkedes det os at implementere funktionen som ønsket.

Mange webbureauer har nogle helt fantastiske designere og grafikere ansat, og som regel kan de også godt finde ud af at sætte et website op – sådan nogenlunde – men når det pludselig skal håndtere titusindevis af samtidige brugere er det her vi kommer på banen.

Det kan være en kunde der skal til at køre TV- eller Radiokampagner, der afholder et stort (online)event, eller måske vil man bare gerne være forberedt til julesalget, Black Friday eller noget helt tredje. Fælles for dem alle er at der pludselig kommer mange besøgende som man tjener penge på, og man vil gerne være sikker på at siden ikke går ned midt i festen.

Som oftest er et webhotel optimeret efter at alle kunder får en ligelig tildelig af resourcer, og samtidig er den belastning et givent website pålægger serveren, ikke nødvendigvis åbenlys. Derfor starter vi som regel med at udføre en test på den nuværende løsning, simpelthen for at se hvor mange samtidige brugere der skal til for at lægge websitet ned.

Dette udføres typisk om natten eller på et test-setup der ikke påvirker det website der er i drift, samtidig med at man kører denne test vil vi også udføre detaljeret overvågning af resourceforbruget. På baggrund heraf vil vi komme med et bud på hvor stor en server, eller eventuelt hvor mange, der skal bruges for at nå det ønskede mål.

Samtidig med udfører vi også profilering på både databasen og selve websitet, ofte kan små ændringer medføre store forbedringer uden at det nødvendigvis koster store summer at rette.

Når den, eller de, nye server(e) så er blevet sat op, kører vi selvfølgelig testen igen, for at bekræfte at det ønskede mål er opnåeligt, inden vi sætter det i produktion.