Det där kan man inte virtualisera!

Vi stöter på detta hela tiden inom IT: en leverantör säger att ett system inte kan virtualiseras. Skälen är många. På IT-sidan blir vi alltid chockade över att en leverantör skulle framföra ett så orimligt påstående, och ofta blir vi lika chockade över att en kund (eller chef) tror på dem. Leverantörer har under årens lopp arbetat hårt för att finslipa detta säljargument, och jag anser att det är viktigt att dissekera det.

Grundorsaken till problemen är att leverantörer nästan alltid söker sätt att sänka sina egna kostnader samtidigt som de ökar vinsten från kunderna. Detta driver mycket av det som annars skulle uppfattas som ett egendomligt beteende.

En sak som väldigt, väldigt många leverantörer försöker göra är att begränsa de scenarier under vilka deras produkt får support. Genom att göra detta förbereder de sig för att helt enkelt kunna avstå från att tillhandahålla support – support är kostsamt och opålitligt. Detta är en vanlig strategi. I vissa fall är detta så aggressivt att det inte ens existerar något godtagbart driftscenario för produktionsmiljö.

Ett mycket vanligt sätt att göra detta är att underlåta att stödja något operativsystem som fortfarande får support, och därigenom i praktiken fasa ut leverantörens egen programvara (i dag skulle detta till exempel innebära att endast stödja Windows XP och tidigare). Ett annat exempel är att endast stödja produkter som inte är licensierade för det aktuella användningsområdet (ett exempel vore att kräva att en produkt som Windows 10 används som server). Och ett av de allra vanligaste fallen är att förbjuda virtualisering.

Dessa scenarier försätter kunder i besvärliga situationer, eftersom de å ena sidan har branschens bästa praxis, standardiserade riktlinjer för driftsättning, interna verktyg och policyer att följa, och å andra sidan har leverantörer som ofta förbjuder korrekt systemdesign, planering och förvaltning. Dessa behov står i konflikt med varandra.

Givetvis förväntar sig ingen att varje leverantör ska stödja varje tänkbart scenario. Gränser måste sättas. Men det finns en enorm avgrund mellan att stödja rimliga, väl driftsatta system och att aktivt kräva oacceptabelt undermåliga driftsättningar. Vi hoppas att våra leverantörer ska uppträda som affärspartner och dela ett gemensamt intresse för vår framgång eller, åtminstone, för framgången för sin egen produkt, och inte direkt försöka undergräva båda dessa mål. Vi skulle hoppas att man, som ett absolut minimum, tillhandahåller support efter bästa förmåga för varje rimligt driftscenario, och att garanterad support sannolikt skulle erbjudas för korrekt konstruerade scenarier enligt bästa praxis.

Föreställ dig en värld där det att hålla hastighetsgränsen och använda bilbälte skulle upphäva din bilgaranti, och där du endast skulle få support om du körde vårdslöst och oskyddat!

Några viktiga saker måste förstås om virtualisering. Den första är att virtualisering är en sedan länge etablerad branschpraxis och förväntas användas i varje produktionsscenario för tjänster. Virtualisering är på intet sätt nytt; även på småföretagsmarknaden har det räknats till bästa praxis i långt över ett decennium nu, och under många decennier inom företagssegmentet. Vi har sedan länge passerat den punkt där det att köra system icke-virtualiserat anses godtagbart, och det inkluderar äldre driftsättningar som funnits på plats under lång tid.

Det finns naturligtvis alltid sällsynta undantag från nästan varje regel. Vissa system behöver åtkomst till mycket specialiserad hårdvara, och virtualisering kanske inte är möjlig, även om detta med modern hårdvarugenomströmning (passthrough) är närmast oerhört ovanligt i dag. Och vissa system med extremt låg latens kan inte virtualiseras, men dessa är normalt begränsade till enbart de allra största internationella investmentbankerna och de mest aggressiva hedgefonderna, och till och med majoriteten av dessa traditionella användningsfall har eliminerats genom förbättringar inom virtualisering, vilket gör att även dessa situationer är sällsynta. Men slutsatsen är: om du inte kan virtualisera bör du vara ledsen över att du inte kan det, och du kommer tydligt att veta varför det är omöjligt i din situation. I alla andra fall behöver din server vara virtuell.

Är det inte viktigt?

Om en leverantör inte tillåter dig att följa standardiserad bästa praxis för sunda driftsättningar, vad säger det om leverantörens egen uppfattning om sin produkt? Om vi talade om vilken annan driftsättning som helst skulle vi omedelbart ifrågasätta varför vi driftsatte ett system så undermåligt om vi planerar att förlita oss på det. Om vår leverantör tvingar oss att bete oss på detta sätt bör vi reagera på samma sätt – om leverantören inte tar produkten på lika stort allvar som vi tar den minsta av våra IT-tjänster, varför skulle då vi göra det?

Detta är en “impedansmissanpassning”, som vi säger i ingenjörskretsar, mellan våra behov (produktionssystem) och hur leverantören som tillverkar det systemet tycks behandla dem (hobby- eller underhållningssystem). Om vi behöver förlita oss på denna produkt för våra verksamheter behöver vi en leverantör som är med på tåget och förstår verksamhetens behov – som har en produktionsinriktad inställning. Om produkten inte är riktad mot eller redo för affärsverksamhet behöver vi vara medvetna om det. Vi behöver ifrågasätta varför vi tycker att vi bör använda en tjänst i produktion, som vi förlitar oss på och kräver support för, när den inte är avsedd att användas på det sättet.

Får den support? Testas den?

Något som ofta förbises ur kundens perspektiv är huruvida de nödvändiga supportresurserna för en produkt finns på plats eller inte. Det är inte ovanligt att teamet som ger support för en produkt blir bantat, eller till och med försvinner, men att företaget fortsätter att sälja produkten i hopp om att mjölka den på så mycket som möjligt och förlitar sig på att antingen ta sig igenom ett problem på något vis eller helt enkelt återbetala kundens pengar om leverantören skulle ertappas i en situation där de helt enkelt inte kan ge support för den.

De flesta programvaruavtal anger att den maximala ersättning som kan utkrävas av leverantören är kostnaden för produkten, eller det belopp som spenderats för att köpa den. I ett fall som detta löper leverantören ingen risk genom att erbjuda en produkt som de inte kan ge support för – även om de tar betalt en premie för support. Om kunden lyckas använda produkten, jättebra, då får de betalt. Om kunden inte kan och leverantören inte kan ge support, förlorar de bara pengar som de aldrig skulle ha fått annars. Kunden tar på sig hela risken, inte leverantören.

Detta antyder förstås att det också sker föga eller ingen fortlöpande testning av produkten, och detta bör vara en ytterligare källa till oro. Bara för att produkten kör betyder det inte att den kommer att fortsätta köra. Att få igång en produkt utan support, eller än värre en produkt som är omöjlig att ge support för, innebär att du med tiden förlitar dig allt mer på en produkt med en sannolikt minskande nivå av potentiell support, som långsamt blir sämre med tiden, samtidigt som behovet av support och beroendet av programvaran förväntas öka.

Om en proprietär produkt driftsätts i produktion, och beslutet fattas att avstå från driftsättningar enligt bästa praxis för att tillmötesgå supportkrav, hur kan detta passa in i en beslutsmatris? Bör detta antyda att korrekt support inte existerar? Återigen, som tidigare, antyder detta en missanpassning i förhållande till våra behov.

 

Utvecklas den fortfarande?

Om programvarans driftsättningsbehov följer gammal, föråldrad praxis, eller kräver föråldrad (eller inte rimligt aktuell programvara eller design), då måste vi ifrågasätta sannolikheten för att produkten alls utvecklas i dag. I vissa fall kan vi avgöra detta genom att under en tid följa programvarans utgivningscykel, men inte i alla fall. Det finns en rimlig farhåga att produkten kan vara död, utan något kvarvarande utvecklingsteam som arbetar med den. Koden kan helt enkelt vara gammal teknisk skuld som säljs i hopp om att tjäna några sista kronor på en gammal kodbas som har övergetts. Denna process är i själva verket långt vanligare än vad man ofta tror.

Mindre programvaruföretag lyckas ofta utveckla ett initialt programvarupaket, få ut det på marknaden och tillgängligt för försäljning, men misslyckas med att ha råd att behålla eller återbemanna sitt utvecklingsteam efter den eller de initiala utgåvorna. Detta är i själva verket ett mycket vanligt scenario. Det lämnar kunderna med en produkt som förväntas bli allt mindre livsduglig med tiden, med driftscenarier som blir allt mer riskfyllda och data som blir allt svårare att få ut.

 

Hur kan den få support om plattformen inte får support?

En vanlig paradox i vissa mer extrema situationer är programvara som, för att kvalificera sig som “supporterad”, kräver annan programvara som antingen inte längre får support eller aldrig fick support för det avsedda användningsfallet. Vanliga exempel på detta är att kräva att ett serversystem körs ovanpå ett operativsystem avsett för skrivbordsdatorer, eller att kräva versioner av operativsystem, databaser eller andra komponenter som inte längre får support över huvud taget. Detta sistnämnda scenario är skrämmande vanligt. I en situation som denna måste man fråga sig om det då över huvud taget kan finnas en driftsättning där programvaran kan anses vara “supporterad”? Om en del av stacken alltid saknar support, då saknar hela stacken support. Det skulle alltid finnas ett skäl till att support kunde nekas, oavsett vad. Själva skälet till att vi därmed skulle kräva att vi undviker bästa praxis skulle på samma sätt utesluta att vi alls valde själva programvaran från första början.

Saknas det branschkompetens och kunskap?

Kanske är problemet vi står inför med programvarusupportproblem av detta slag att det eller de team som skapar programvaran helt enkelt inte vet hur bra programvara skapas och/eller hur bra system driftsätts. Detta hör till de mest rimliga och giltiga skälen till vad som skulle kunna leda oss till denna situation. Men, liksom de andra hypotetiska skälen, lämnar det oss bekymrade över programvarans kvalitet och över möjligheten att support verkligen finns att tillgå. Om vi inte kan lita på att leverantören hanterar de mest synliga delarna av systemet på rätt sätt, varför skulle vi då vända oss till dem som våra experter för de delar som vi inte kan verifiera?

Det stora problemet

Det stora, övergripande problemet med programvara som ställer tvivelaktiga krav på driftsättnings- och underhållspraxis i utbyte mot att låsa upp support som annars hålls inne är inte, som vi typiskt antar, en fråga om programvarans övergripande kvalitet, utan en fråga om livsduglig support- och utvecklingspraxis. Att dessa frågor antyder en betydande oro för långsiktig support bör få oss att starkt ifrågasätta varför vi alls väljer dessa paket från första början, samtidigt som vi förväntar oss stark support från dem, när vi redan från början har mycket synliga och mycket allvarliga farhågor.

Det finns naturligtvis fall där ingen annan programvaruprodukt existerar för att fylla ett behov, eller ingen med någon rimligare livsduglighet. Denna situation bör vara ytterst sällsynt, och om en sådan situation existerar bör den ses som en stor marknadsmöjlighet för en leverantör som vill ge sig in på just det området.

Ur ett affärsperspektiv är det avgörande att bästa praxis för den tekniska infrastrukturen inte fullständigt ignoreras i utbyte mot ett blint eller närmast blint följande av leverantörskrav som, i vilket annat sammanhang som helst, skulle anses vårdslösa eller oprofessionella. Varför underlåter vi så ofta att kräva förträfflighet av de kärnprodukter som våra verksamheter på detta sätt är beroende av? Det utsätter våra verksamheter för risk, inte bara från handlingen i sig, utan i vida högre grad från de risker som antyds av att ett sådant krav alls existerar.