Det Kan Ikke Virtualiseres!

Vi hører det hele tiden i IT — en leverandør fortæller os, at et system ikke kan virtualiseres. Begrundelserne er mange. På IT-siden er vi altid chokerede over, at en leverandør vil fremsætte et så vanvittigt krav; og ofte er vi lige så chokerede over, at en kunde (eller leder) tror på dem. Leverandørerne har i årevis arbejdet hårdt på at perfektionere dette salgspitch, og jeg mener, det er vigtigt at dissekere det.

Årsagen til problemerne er, at leverandørerne næsten altid søger måder at sænke egne omkostninger på, mens de øger profitten fra kunderne. Det driver meget af det, der ellers ville blive betragtet som underlig adfærd.

Noget som rigtig mange leverandører forsøger at gøre, er at begrænse de scenarier, under hvilke deres produkt vil være understøttet. Ved at gøre dette forbereder de sig på simpelthen ikke at yde support — support er dyrt og upålideligt. Dette er en almindelig strategi. I nogle tilfælde er dette så aggressivt, at der ikke engang eksisterer et acceptabelt produktionsscenario.

Et meget almindeligt middel til at opnå dette er at undlade at understøtte noget aktuelt operativsystem, hvilket de facto udfaser leverandørens egen software (for eksempel ville dette i dag betyde kun at understøtte Windows XP og tidligere). Et andet eksempel er kun at understøtte produkter, der ikke er licenseret til den pågældende use case (et eksempel ville være at kræve, at et produkt som Windows 10 bruges som server). Og et af de mest almindelige tilfælde er at forbyde virtualisering.

Disse scenarier sætter kunder i vanskelige situationer, fordi de på den ene side har branchens bedste praksis, standardiserede implementeringsretningslinjer, interne værktøjer og politikker at overholde; og på den anden side har leverandører, der ofte forbyder korrekt systemdesign, planlægning og administration. Disse behov er i konflikt med hinanden.

Selvfølgelig forventer ingen, at alle leverandører understøtter alle mulige scenarier. Begrænsninger må sættes. Men der er en enorm kløft mellem at understøtte fornuftige, velimplementerede systemer og aktivt at kræve uacceptabelt dårlige implementeringer. Vi håber, at vores leverandører vil opføre sig som forretningspartnere og have en fælles interesse i vores succes — eller i det mindste deres produkts succes — og ikke direkte søge at underminere begge disse mål. Vi ville håbe, at som et absolut minimum ville bedst mulig support tilbydes for ethvert rimeligt implementeringsscenario, og at garanteret support sandsynligvis ville tilbydes for korrekt konstruerede, best practice-scenarier.

Forestil dig en verden, hvor det at overholde hastighedsgrænserne og bruge sikkerhedssele ville ugyldiggøre din bilgaranti, og at du kun ville få support, hvis du kørte hensynsløst og ubeskyttet!

Nogle vigtige ting skal forstås om virtualisering. Den første er, at virtualisering er en mangeårig branchebedste praksis og forventes at blive brugt i ethvert produktionsimplementeringsscenario for tjenester. Virtualisering er på ingen måde ny — selv på small business-markedet har den været i best practice-kategorien i godt over et årti nu, og i mange årtier i enterprise-verdenen. Vi er for længst forbi det punkt, hvor det anses for acceptabelt at køre systemer ikke-virtualiseret, og det gælder også legacy-implementeringer, der har været på plads i lang tid.

Der er selvfølgelig altid sjældne undtagelser fra næsten enhver regel. Nogle systemer har brug for adgang til meget specialiseret hardware, og virtualisering er måske ikke mulig, selvom dette med moderne hardware-passthrough er næsten uhørt i dag. Og nogle ultra-lav-latens-systemer kan ikke virtualiseres, men disse er normalt begrænset til kun de største internationale investeringsbanker og de mest aggressive hedgefonde, og selv flertallet af disse traditionelle use cases er blevet elimineret af forbedringer i virtualisering, hvilket gør selv disse situationer sjældne. Men bundlinjen er: Hvis du ikke kan virtualisere, bør du beklage, at du ikke kan, og du vil tydeligt vide, hvorfor det er umuligt i din situation. I alle andre tilfælde skal din server være virtuel.

Er det ikke vigtigt?

Hvis en leverandør ikke tillader dig at følge standardbedste praksis for sunde implementeringer, hvad siger det så om leverandørens syn på sit eget produkt? Hvis vi talte om enhver anden implementering, ville vi straks stille spørgsmålstegn ved, hvorfor vi implementerede et system så dårligt, hvis vi planlægger at afhænge af det. Hvis vores leverandør tvinger os til at opføre os på denne måde, bør vi reagere på samme måde — hvis leverandøren ikke tager produktet lige så seriøst som vi tager den mindste af vores IT-tjenester, hvorfor skulle vi så?

Dette er en "impedansmismatch", som vi siger i ingeniørkredse, mellem vores behov (produktionssystemer) og hvordan leverandøren, der laver det system, tilsyneladende behandler dem (hobby- eller underholdningssystemer). Hvis vi skal afhænge af dette produkt til vores virksomheder, har vi brug for en leverandør, der er med ombord og forstår forretningsbehov — har en produktionstankegang. Hvis produktet ikke er rettet mod erhvervslivet eller forretningsklar, skal vi være opmærksomme på det. Vi er nødt til at stille spørgsmålstegn ved, hvorfor vi mener, vi bør bruge en tjeneste i produktion, som vi er afhængige af og kræver support til, der ikke er beregnet til at blive brugt på den måde.

Er det understøttet? Bliver det testet?

Noget der ofte overses fra kundernes perspektiv er, om de nødvendige supportressourcer til et produkt er på plads. Det er ikke ualmindeligt, at det team, der understøtter et produkt, bliver slankere eller endda forsvinder, men virksomheden fortsætter med at sælge produktet i håb om at malke det for så meget som muligt og satse på enten at klare sig igennem et problem eller blot tilbagebetale kunderne, hvis leverandøren befinder sig i en situation, hvor de simpelthen ikke er i stand til at yde support.

De fleste softwarekontrakter angiver, at den maksimale erstatning, der kan kræves af leverandøren, er produktets pris eller det beløb, der er brugt på at købe det. I en sådan situation har leverandøren ingen risiko ved at tilbyde et produkt, de ikke kan understøtte — selv ved at opkræve et premium for support. Hvis kunden formår at bruge produktet, fantastisk — de får betalt. Hvis kunden ikke kan, og leverandøren ikke kan understøtte det, mister de kun penge, som de aldrig ville have fået alligevel. Kunden påtager sig al risikoen, ikke leverandøren.

Dette antyder selvfølgelig, at der er lidt eller ingen løbende test af produktet, og dette bør give yderligere bekymring. Bare fordi produktet kører, betyder det ikke, at det vil fortsætte med at køre. At komme i gang med et ikke-understøttet, eller endnu værre ikke-understøtteligt, produkt betyder, at du over tid i stigende grad er afhængig af et produkt med et sandsynligvis faldende niveau af potentiel support, der langsomt forringes over tid, selv som behovet for support og afhængigheden af softwaren forventes at stige.

Hvis et proprietært produkt implementeres i produktion, og beslutningen træffes om at afstå fra best practice-implementeringer for at imødekomme supportkrav, hvordan kan dette så passe ind i en beslutningsmatrix? Bør dette antyde, at korrekt support ikke eksisterer? Igen, som før, antyder dette en mismatch i vores behov.

 

Er det stadig under udvikling?

Hvis softwarens implementeringsbehov følger gamle, forældede praksisser eller kræver forældet (eller ikke rimeligt aktuel software eller design), så er vi nødt til at stille spørgsmålstegn ved sandsynligheden for, at produktet i øjeblikket er under udvikling. I nogle tilfælde kan vi bestemme dette ved at observere softwarens udgivelsescyklus over nogen tid, men ikke i alle tilfælde. Der er en rimelig frygt for, at produktet måske er dødt, uden noget tilbageværende udviklingsteam, der arbejder på det. Koden kan simpelthen være gammel, teknisk gæld, der sælges i håb om at tjene de sidste få kroner på en gammel kodebase, der er opgivet. Denne proces er faktisk langt mere almindelig, end man ofte tror.

Mindre software-virksomheder formår ofte at udvikle en indledende softwarepakke, bringe den på markedet og til salg, men er ikke i stand til at have råd til at fastholde eller genbesætte deres udviklingsteam efter den indledende udgivelse. Dette er faktisk et meget almindeligt scenarie. Dette efterlader kunderne med et produkt, der forventes at blive mindre og mindre levedygtigt over tid med implementeringsscenarier, der bliver stadig mere risikable, og data, der bliver stadig sværere at udtrække.

 

Hvordan kan det understøttes, hvis platformen ikke er understøttet?

Et almindeligt paradoks i nogle mere ekstreme situationer er software, der for at kvalificere som "understøttet" kræver anden software, der enten er ude af support eller aldrig var understøttet til den tiltænkte use case. Almindelige eksempler på dette er at kræve, at et serversystem køres oven på et desktop-operativsystem eller at kræve versioner af operativsystemer, databaser eller andre komponenter, der slet ikke længere er understøttet. Dette sidste scenarie er skræmmende almindeligt. I en sådan situation er man nødt til at spørge, om der overhovedet kan eksistere en implementering, hvor softwaren kan betragtes som "understøttet"? Hvis en del af stakken altid er ude af support, er hele stakken ikke-understøttet. Der ville altid være en grund til, at support kunne nægtes uanset hvad. Den meget grund til, at vi ville kræve at undgå best practices, ville i samme grad udelukke valget af selve softwaren i første omgang.

Mangler der branchekendskab og -kompetencer?

Måske er det problem, vi står over for med softwaresupportproblemer af denne art, at det eller de teams, der skaber softwaren, simpelthen ikke ved, hvordan god software laves og/eller hvordan gode systemer implementeres. Dette er blandt de mest rimelige og gyldige grunde til det, der ville bringe os til denne situation. Men ligesom de andre hypotetiske grunde efterlader det os bekymret over softwarens kvalitet og muligheden for, at support faktisk er tilgængelig. Hvis vi ikke kan stole på leverandøren til at håndtere de mest synlige dele af systemet korrekt, hvorfor skulle vi så vende os til dem som vores eksperter for de dele, vi ikke kan verificere?

Det store problem

Det store, overordnede problem med software, der har tvivlsomme implementerings- og vedligeholdelsespraktikkrav i bytte for at låse op for ellers tilbageholdt support, er ikke, som vi typisk antager, et spørgsmål om den overordnede softwarekvalitet, men om levedygtig support og udviklingspraksis. At disse problemer antyder en betydelig bekymring for langsigtet support bør få os til kraftigt at stille spørgsmålstegn ved, hvorfor vi vælger disse pakker i første omgang, mens vi forventer stærk support fra dem, når vi fra starten har meget synlige og meget alvorlige bekymringer.

Der er selvfølgelig tilfælde, hvor der ikke eksisterer andre softwareprodukter til at dække et behov, eller ingen med en mere rimelig levedygtighed. Denne situation bør være ekstremt sjælden, og hvis en sådan situation eksisterer, bør den ses som en stor markedsmulighed for en leverandør, der ønsker at træde ind på dette marked.

Fra et forretningsmæssigt perspektiv er det bydende nødvendigt, at teknisk infrastrukturs bedste praksis ikke ignoreres fuldstændigt til fordel for blind eller næsten blind efterlevelse af leverandørkrav, der i enhver anden sammenhæng ville blive betragtet som hensynsløse eller uprofessionelle. Hvorfor negligerer vi så ofte at kræve excellence fra kerneprodukter, som vores virksomheder afhænger af på denne måde? Det sætter vores virksomheder i fare — ikke kun fra selve handlingen, men i langt højere grad fra de risici, der er antydet af eksistensen af et sådant krav.