Det vi i dag kalder On-Prem (forkortet af On-Premises) skal sælgere, kollegaer og frem for alt software-udviklerne forstå, ikke automatisk betyder at de servere vi har gjort tilgængelig, står i jeres egen kælder. For det meste står serverne i et andet datacenter – nogle gange sågar samme sted som serverne der er grundlaget for Microsoft Azure cloud infrastrukturen.

Grunden til jeg har behov for at komme af med dette brok, er at flere og flere software og løsnings-leverandører fjerner On-Prem. muligheden for deres software.

Tit hører jeg forklaringen “det kan ikke køre On-Prem” eller “vi kan ikke deploye til det hvis det står hos jer” eller “det bliver for dyrt hvis det skal køre på jeres egen server

Der er helt sikkert situationer hvor det er nemmere for leverandøren, at levere en løsning hvis det kører på i deres egen cloud tenant – men det skal vel ikke blive mit problem, hvis en leverandør vælger ikke at designe deres løsning, så den kan deployes til en server der står hos en hvilken som helst MSP. Der er grundlæggende ingen forskel om du deployer din Umbraco løsning til en IIS der står hos Itadel/GCOS/NNIT eller om den kører i en public cloud. Det er dine udviklere der skal lære at forstå forskellen, fremsende system-requirements og anvende en tidssvarende måde at frigive software på.

Når det er sagt, forstår jeg godt der er kommercielle forhold der gør det mere interessant for en leverandør at levere det som en as-a-service. Men så fortæl dog kunden sandheden, i stedet for at dækker jer bag forlorne tekniske grunde.

Årsager til i skal insistere på at der kører On-Prem:

  • I har et kørende setup, selv om leverandøren går konkurs.
  • Hvis en kundespecifik-løsning kører på jeres egne server, er i typisk bedre stillet ved en copyright/IP tvist.
  • I har oftest en SLA på de servere jeres MSP stiller til rådighed. Det har en leverandør sjældent med en Public Cloud tjeneste, selv om oppetiden ofte er høj.
  • Det er generelt meget billigere og hurtigere at integrere med andre systemer, hvis alle løsninger kører på jeres egen server.

Eksempel fra den virkelige verden.
Et firma jeg vælger at holde hemmeligt, får i øjeblikket leveret en løsning baseret på WordPress. I udviklingsfasen blev løsningen præsenteret kørende på en Ubuntu 16.04 LTS og vi gjorde fra starten opmærksom på det skulle køre på en af deres egne servere. Efter kontrakten blev indgået, fik vi ad bagveje at vide løsningen var blevet ca. kr. 70.000,- dyrere end aftalt. Det havde leverandøren forklaret vores marketing-afdeling, var forårsaget af det var sværere at vedligeholde sitet på vores server end forventet. Konfrontatorisk som jeg er, tager jeg fat i leverandøren og dette er en recap af kommunikationen(fyld fjernet):

  • Mig: Forklar i detaljer omstændighederne der gør det mere tidskrævende at vedligeholde sitet
  • Leverandør: Det tager længere tid at deploye
  • Mig: Hvordan deployer i?
  • Leverandør: Via. et automatisk system vi kalder octopussy
  • Mig: Er du sikker på det ikke er Octopus?
  • Leverandør: Det ved jeg ikke
  • Mig: Vil du spørge jeres udviklere?
  • Leverandør: Det er den samme vi bruger
  • Mig: Hvorfor skulle det være sværere at deploye til vores server, i stedet for en server til i Azure?
  • Leverandør: Det siger vores udviklingsafdeling
  • Mig: Vil du bede dem forklare specifikt hvilken årsag?
  • Leverandør: De siger de godt kan nu, men den server Azure stiller til rådighed er mere sikker
  • Mig: Hvordan mere sikker?
  • Leverandør: De har en større firewall
  • Mig: Målt i units, meter eller kilo?
  • Leverandør: (forstod ikke dårlig joke)
  • Mig: *undskylder utidig joke* Vi har løbende nogle af de bedste pen-testere til at gennemgå vores løsning, så jeg tror den er sikker nok. Hvordan opdatere i styresystemet på jeres Linux?
  • Leverandør: Det gør vi ikke for det er et Cloud OS
  • Mig: Cloud OS? er det ikke bare en Linux server i Azure i selv installere?
  • Leverandør: Det tror jeg ikke
  • Mig: Vil du spørge dine udviklere?
  • Leverandør: Vi har en SLA på oppetid
  • Mig: *begynder at blive træt* Kan du få jeres udviklere til at forklare hvordan de opdatere serveren?
  • Leverandør: *indrømmer de har misforstået noget* Det gør de åbenbart ikke
  • Mig: Så den server der kører hos vores hosting-leverandør, der opdatere mindst en gang hvert måned, vil du mene at den er mere eller mindre sikker end den i har i Azure og ikke opdatere
  • Leverandør: Vi begynder at opdatere den nu
  • Mig: Når i har udfærdiget en patch-procedure, vil du så sende mig en kopi. Hvor mange kvalificerede Linux folk har i ansat der kan vurdere om en patch skal installeres?
  • Leverandør: *lang forklaring på at er søger nye ansatte* ikke nogen i dag
  • Mig: Så hvem var det der vurderede at, den server der kørte i Azure var mere sikker, end den vores certificerede Linux-leverandør stiller til rådighed
  • Leverandør: Vores udviklere
  • Mig: Dem der ikke kender Linux godt nok til at patche en Ubuntu?
  • Leverandør: Jeg vender lige tilbage til dig efter vores fredagsmøde
  • Mig: Bed dine udviklere forklare dig hvad forskellen er på at køre websites på en Ubuntu server i Azure, kontra en anden hosting leverandør

… gæt selv hvor den server kører i dag, og om vi betaler mere for at den kører hos vores egen hosting-leverandør.

Formålet med dette indlæg er at anbefale kunder i hostingbranchen tilsikre leverandøren ikke kun kører ITIL processer på det papir kontrakten skrives på.

Stil krav til jeres hostingpartner:
Sørg for det konkret fremgår at kontrakten hvor ofte systemet gennemgås for fejl og hvordan man sikre et system ikke sander til, ved at have definerede kvalitetsmål for ydelsen på serveren. Der skal foreligge detaljeret beskrivelse af Capacity Management og Continual Service Improvement procedure.

Med en fortid som både senior-tekniker og driftschef i en anerkendt hostingvirksomhed, samt mange år som enten leverandør eller kunde i top10 inden for hosting i danmark, skal jeg være en af de første der lægger sig fladt ned og erkender mit medansvar. For de fleste kunder der betaler for Managed Service, ofte står tilbage med en løsning der ligger tættere på Infrastructure as a service (IaaS), efter systemet først er leveret og ibrugtaget.

Problem #1: Hovedparten af kundernes forventning til leverancer inden for hosting, står ikke mål med det de ønsker at betale – så hvor skal pengene til continual service improvement komme fra?
Problem #2: Leverandøren tør ikke bede om det beløb det koster at drive et dynamisk og frugtbart samarbejde med kunden.

ITIL hosting

En Continual Service Improvement Plan er en procedure der sikre services man køber hos leverandøren, løbende tilpasses kundes behov. En leverandør slår sig ofte på at være dynamisk, agil og skalerbar. I hverdagen sker det oftest kun på kundens opfordring, eller efter kundens installation er revideret af ekstern konsulent.

Eksempel #1
I 2017 henvendte en tidligere kunde sig personligt over Linkedin, for at få mig til at revidere deres nuværende MS-SQL løsning. En Løsning de fik leveret som en Managed Service hos en hostingpartner der slog sig på at køre på højeste klinge inden for ITIL og best-practice. Kundens oplevelse var at især at deres Navision var langsom. Ofte var det den første time om dagen der var værst, hvor selv de mest basale oprettelser eller kørsler tvang serveren i knæ. Leverandøren påstod der ikke var noget at komme efter, for der var massere af RAM, CPU og Disk kapacitet.

Efter en hurtig gennemgang af serveren viser det sig at opsætningen er 100% default. Det betyder bla.
– Autogrowth er sat til 1MB
– Temp database ligger på samme volume som OS, Data og Logfiler
– Max degree of parallelism var sat til 1, på trods af serveren havde 16 CPU cores tilgængeligt

Med under 10 minutters arbejde (ikke automatiseret) blev ydelsen i Navision hævet med over 180% – resultat = glad men uforstående kunde.

Eksempel #2
En kunde vil gerne bede mig kigge på en IIS løsning med ca. 2500 samtidige brugere i dagtimerne. Serveren løb hele tiden tør for plads, og løsningen blev mere og mere omkostningstung at holde kørende. Årsagen var IIS-logs ikke blev slettet, selv om kunden kun skulle bruge de sidste 30 dage. I stedet for at leverandøren brugte 10 minutter på at finde årsagen til det voksende behov for plads, blev kunden blodt bedt om at købe mere kapacitet. Kunden har købt en Managed Service, men hostingleverandøren skubber vedligeholdet retur på kunden. Hvorfor så opsige sin egen driftafdeling, og betale dyrt for ISO certificeret hosting efter de bedste ITIL principper?

Mit spørgsmål til jer:
– Hvordan skal de to partner kunne mødes, hvis kunden ikke ved hvad “continual service improvement” er, men leverandøren i øvrigt ikke mener kunden betaler for det og derfor ikke bringer det på banen?
– Hvordan får vi forankret ITIL i den daglige drift og ikke kun benytter det til at slå pressede driftstekniker i hovedet når de har lave udokumenterede ændringer?

Omkring hosting er min anbefaling til danske virksomheder er stadig den samme; Benyt altid en dansk hosting-leverandør, der som minimum er ISO27001 certificeret og gør kontrakten betinget af en gyldig ISAE 3402-erklæring

Flere benytter i dag cloud-hosting giganter som Amazon AWS, Google og Azure. Men samme flertal glemmer ofte at læse det der står med småt i betingelserne. Et eksempel på dette er Amazon AWS, som de fleste tror er sikker og at man som kunde overholder den EU-retsligt gældende persondataforordning – der tolker jeg betingelserne hos Amazon AWS anderledes!

Kilde: Amazon AWS betingelser
Opdateret 2017-12-08: AWS har opdateret deres betingelser. Men AWS er et amerikansk selskab, og skal derfor efterleve pågældende statslige retsplejelov, der i sidste ende diktere hvor meget slutkunden informeres og hvad der sker med data. (ie: FISC or FISA Court)

Access: We do not access or use customer content for any purpose other than as legally required and for maintaining the AWS services.

Storage: We will not move or replicate customer content outside of the customer’s chosen region(s), except as legally required and as necessary to maintain the AWS services.

Disclosure of customer content: We do not disclose customer content unless we’re required to do so to comply with the law or a valid and binding order of a governmental or regulatory body. Unless prohibited from doing so or there is clear indication of illegal conduct in connection with the use of Amazon products or services, Amazon notifies customers before disclosing customer content so they can seek protection from disclosure.

Med andre ord; Vi garantere dine data ligger sikkert hos os, der hvor du har bedt os om at placere det, indtil en domstol eller et efterretningsvæsen beder os om at udlevere det, eller vi har behov for at genskabe dine servere i et andet datacenter, hvis det du ligger i nu bryder sammen. Og vi har mulighed for at gøre det uden at informere dig.

Nyt EU rubber stamp:
Det nye tiltag kaldet “EU-US Privacy Shield” er en måde hvorpå man kan sende data fra EU til en lokation i USA, men samtidigt på papiret overholde EU’s persondataforordning – som sagt; “på papiret”. For i det sekundt data lander i USA, er det deres regler der gælder, og det kræver ikke at kunden er informeret omkring udleveringen af data. Personligt opfatter jeg det udelukkende som en skrivebordsmanøvre der skal sikre kunder stadig kan benytte services som Amazon AWS, Azure og Google.

Ikke et personligt vendetta:
Amazon AWS, Azure og Google er fantastiske services, og jeg er sikker på en stor del af fremtiden bliver baseret på ryggen af deres services, da komplexiteten i at opretholde en robust it-infrastruktur har overhalet den hastighed og de budgetter man tidligere har driftet lokale servere og services. Men det ændre ikke ved, at lovgivningen konflikter med services der er tilgængeligt i dag. Valget er derfor om man ændre eller bryde loven. Historisk set kan jeg ikke få øje på hvornår menneskeheden har været i stand til at stoppe udviklingen pga. juridiske bump på vejen… dvs. lige bortset fra Über og deleøkonomi 🙂