Det kan du ikke virtualisere!

Vi hører dette hele tiden i IT – en leverandør forteller oss at et system ikke kan virtualiseres. Grunnene er mange. På IT-siden blir vi alltid sjokkert over at en leverandør kommer med en så oppsiktsvekkende påstand, og ofte er vi like sjokkert over at en kunde (eller leder) tror på dem. Leverandører har jobbet hardt med å perfeksjonere dette salgsargumentet gjennom årene, og jeg mener det er viktig å dissekere det.

Rotårsaken til problemene er at leverandører nesten alltid søker måter å senke sine egne kostnader på, samtidig som de øker fortjenesten fra kundene. Dette driver mye av det som ellers ville blitt sett på som merkelig atferd.

Noe mange, mange leverandører forsøker å gjøre er å begrense scenariene der produktet deres vil bli støttet. Ved å gjøre dette forbereder de seg på rett og slett å ikke yte support – support er kostbart og upålitelig. Dette er en vanlig strategi. I noen tilfeller er dette så aggressivt at det ikke engang finnes et akseptabelt produksjonsscenario for utrulling.

En svært vanlig måte å gjøre dette på er å unnlate å støtte noe støttet operativsystem, og dermed de facto avvikle leverandørens eget programvare (for eksempel ville dette i dag bety at man kun støtter Windows XP og tidligere.) Et annet eksempel er å kun støtte produkter som ikke er lisensiert for det aktuelle bruksområdet (et eksempel ville være å kreve at et produkt som Windows 10 brukes som server.) Og ett av de vanligste tilfellene er å forby virtualisering.

Disse scenariene setter kunder i vanskelige posisjoner, fordi de på den ene siden har bransjens beste praksis, standard retningslinjer for utrulling, interne verktøy og retningslinjer å følge; og på den andre siden har leverandører som ofte forbyr riktig systemdesign, planlegging og administrasjon. Disse behovene er i konflikt med hverandre.

Selvfølgelig forventer ingen at enhver leverandør skal støtte alle mulige scenarioer. Begrensninger må brukes. Men det er et enormt gap mellom å støtte rimelige, godt utrullede systemer og aktivt kreve uakseptabelt dårlige utrullinger. Vi håper at leverandørene våre vil opptre som forretningspartnere og dele en felles interesse i vår suksess – eller i det minste suksessen til produktet deres – og ikke direkte forsøke å undergrave begge disse målene. Vi ville håpe at, som et aller minimum, det beste mulige forsøk på support ville bli gitt for ethvert rimelig utrullingsscenario, og at garantert support trolig ville bli tilbudt for riktig konstruerte, beste-praksis-scenarioer.

Tenk deg en verden der det å kjøre i fartsgrensen og bruke bilbelte ville ugyldiggjøre bilgarantien din, og at du bare ville få support hvis du kjørte hensynsløst og ubeskyttet!

Noen viktige ting må forstås om virtualisering. Det første er at virtualisering er en langvarig beste praksis i bransjen og forventes å brukes i ethvert produksjonsscenario for tjenester. Virtualisering er på ingen måte nytt – selv i småbedriftsmarkedet har det vært i beste-praksis-kategorien i godt over et tiår, og i mange tiår i enterprise-sammenheng. Vi er for lengst forbi det punktet der det å kjøre systemer ikke-virtualisert anses som akseptabelt, og det inkluderer eldre utrullinger som har vært på plass lenge.

Det finnes selvfølgelig alltid sjeldne unntak fra nesten enhver regel. Noen systemer trenger tilgang til svært spesialisert maskinvare og virtualisering er kanskje ikke mulig, selv om dette med moderne maskinvare-gjennomkobling er nesten uhørt i dag. Og noen systemer med ekstremt lav latens kan ikke virtualiseres, men disse er normalt begrenset til kun de største internasjonale investeringsbankene og de mest aggressive hedgefondene – og selv flertallet av disse tradisjonelle brukstilfellene har blitt eliminert av forbedringer i virtualiseringsteknologi, noe som gjør selv disse situasjonene sjeldne. Men bunnlinjen er: hvis du ikke kan virtualisere, bør du beklage at du ikke kan det, og du vil tydelig vite hvorfor det er umulig i din situasjon. I alle andre tilfeller må serveren din være virtuell.

Er det ikke viktig?

Hvis en leverandør ikke lar deg følge standard beste praksis for sunne utrullinger, hva sier dette om leverandørens syn på sitt eget produkt? Hvis vi snakket om en hvilken som helst annen utrulling, ville vi umiddelbart stille spørsmål ved hvorfor vi rullet ut et system så dårlig hvis vi planlegger å stole på det. Hvis leverandøren vår tvinger oss til å oppføre oss på denne måten, bør vi reagere på samme måte – hvis leverandøren ikke tar produktet på samme alvor som vi tar den minste av våre IT-tjenester, hvorfor skulle vi?

Dette er en «impedansfeil», som vi sier i ingeniørkretser, mellom våre behov (produksjonssystemer) og hvordan leverandøren som lager systemet tilsynelatende behandler dem (hobby- eller underholdningssystemer.) Hvis vi trenger å stole på dette produktet for virksomhetene våre, trenger vi en leverandør som er ombord og forstår forretningsbehov – har en produksjonsmentalitet. Hvis produktet ikke er rettet mot eller klart for forretningsbruk, må vi være klar over det. Vi må stille spørsmål ved hvorfor vi mener vi bør bruke en tjeneste i produksjon, som vi er avhengige av og krever support for, når den ikke er ment å brukes på den måten.

Er det støttet? Blir det testet?

Noe som ofte overses fra kundenes perspektiv er om de nødvendige supportressursene for et produkt er på plass. Det er ikke uvanlig at teamet som støtter et produkt blir slankere, eller til og med forsvinner, men at selskapet fortsetter å selge produktet i håp om å melke det for så mye som mulig og satse på enten å snuble seg gjennom et problem eller bare tilbakebetale kunden dersom leverandøren havner i en situasjon der de rett og slett ikke kan støtte det.

De fleste programvarekontrakter sier at den maksimale skaden som kan kreves fra leverandøren er kostnadene for produktet, eller beløpet brukt på å kjøpe det. I et slikt tilfelle har leverandøren ingen risiko ved å tilby et produkt de ikke kan støtte – selv om de tar betalt for support. Hvis kunden klarer å bruke produktet, flott – de får betalt. Hvis kunden ikke kan det og leverandøren ikke kan støtte det, mister de bare penger de aldri ville fått uansett. Kunden tar all risikoen, ikke leverandøren.

Dette antyder selvfølgelig at det er lite eller ingen fortsatt testing av produktet, og dette bør være en ekstra bekymring. Bare fordi produktet kjører betyr ikke det at det vil fortsette å kjøre. Å komme i gang med et ikke-støttet, eller verre ikke-støttbart, produkt betyr at du over tid i økende grad er avhengig av et produkt med et sannsynlig avtagende støttenivå, som sakte blir dårligere over tid selv om behovet for support og avhengigheten av programvaren forventes å øke.

Hvis et proprietært produkt rulles ut i produksjon, og beslutningen tas om å unnlate beste praksis for utrulling for å imøtekomme supportkrav, hvordan kan dette passe inn i en beslutningsmatrise? Burde dette antyde at riktig support ikke eksisterer? Igjen, som tidligere, antyder dette et misforhold i våre behov.

 

Er det fortsatt under utvikling?

Hvis programvarens utrullingsbehov følger gamle, utdaterte praksiser, eller krever utdatert (eller ikke rimelig aktuell programvare eller design), må vi stille spørsmål ved sannsynligheten for at produktet er under aktiv utvikling. I noen tilfeller kan vi fastslå dette ved å følge programvarens utgivelsessyklus over tid, men ikke i alle tilfeller. Det er en rimelig frykt for at produktet kan være dødt, uten noe gjenværende utviklingsteam som jobber med det. Koden kan rett og slett være gammel, teknisk gjeld som selges i håp om å tjene noen siste kroner på en gammel kodebase som er blitt forlatt. Denne prosessen er faktisk langt mer vanlig enn man ofte tror.

Mindre programvarehus klarer ofte å utvikle en innledende programvarepakke, få den på markedet og tilgjengelig for salg, men mislykkes i å ha råd til å beholde eller bemanne opp igjen utviklingsteamet etter den første utgivelsen. Dette er faktisk et svært vanlig scenario. Dette etterlater kunder med et produkt som forventes å bli stadig mindre levedyktig over tid, med utrullingsscenarioer som blir stadig mer risikable og data som blir stadig vanskeligere å trekke ut.

 

Hvordan kan det støttes hvis plattformen ikke er støttet?

Et vanlig paradoks i noen mer ekstreme situasjoner er programvare som, for å kvalifisere som «støttet», krever annen programvare som enten er ute av support eller aldri var støttet for det tiltenkte bruksområdet. Vanlige eksempler på dette er å kreve at et serversystem kjøres på et stasjonært operativsystem, eller å kreve versjoner av operativsystemer, databaser eller andre komponenter som ikke lenger er støttet i det hele tatt. Dette siste scenariet er skremmende vanlig. I en situasjon som denne må man spørre seg om det noen gang kan finnes en utrulling der programvaren kan anses som «støttet». Hvis en del av stakken alltid er ute av support, er hele stakken ikke-støttet. Det ville alltid finnes en grunn til at support kunne bli nektet uansett. Den samme grunnen til at vi krever at vi unngår beste praksis, ville like godt utelukke å velge selve programvaren i utgangspunktet.

Mangler bransjekunnskaper og -ferdigheter?

Kanskje det problemet vi møter med programvaresupportproblemer av denne arten er at teamene som lager programvaren rett og slett ikke vet hvordan god programvare lages og/eller hvordan gode systemer rulles ut. Dette er blant de mest rimelige og gyldige grunnene til hva som ville drive oss til denne situasjonen. Men, som de andre hypotesegrunnene, etterlater det oss bekymret for kvaliteten på programvaren og muligheten for at support virkelig er tilgjengelig. Hvis vi ikke kan stole på leverandøren til å håndtere de mest synlige delene av systemet på riktig måte, hvorfor skulle vi vende oss til dem som eksperter for de delene vi ikke kan verifisere?

Det store problemet

Det store, overordnede problemet med programvare som har tvilsomme krav til utrulling og vedlikeholdspraksis i bytte for å låse opp ellers tilbakeholdt support er ikke, som vi typisk antar, et spørsmål om generell programvarekvalitet, men ett om levedyktig support og utviklingspraksis. At disse problemene antyder en betydelig bekymring for langsiktig support, bør få oss til å sterkt stille spørsmål ved hvorfor vi velger disse pakkene i utgangspunktet, mens vi forventer sterk support fra dem når vi fra starten av har svært synlige og svært alvorlige bekymringer.

Det finnes selvfølgelig tilfeller der ingen andre programvareprodukter eksisterer for å dekke et behov, eller ingen av noen mer rimelig levedyktighet. Denne situasjonen bør være ekstremt sjelden, og hvis en slik situasjon eksisterer bør den sees på som en stor markedsmulighet for en leverandør som ønsker å entre det aktuelle markedet.

Fra et forretningsperspektiv er det avgjørende at de tekniske infrastrukturens beste praksiser ikke ignoreres fullstendig i bytte for blind eller nesten blind etterfølging av leverandørkrav som, i enhver annen sammenheng, ville blitt ansett som hensynsløst eller uprofesjonelt. Hvorfor forsømmer vi så ofte å kreve fremragende kvalitet fra kjerneproduktene som virksomhetene våre avhenger av på denne måten? Det setter virksomhetene våre i fare – ikke bare på grunn av handlingen i seg selv, men i langt større grad på grunn av de risikoene som er antydet ved eksistensen av et slikt krav.