Non si può virtualizzare quella cosa!

Nell'IT ci capita di continuo: un fornitore ci dice che un sistema non può essere virtualizzato. Le ragioni sono molteplici. Dal lato IT, siamo sempre sorpresi che un fornitore possa avanzare un'affermazione così oltraggiosa; e spesso siamo altrettanto sorpresi che un cliente (o un manager) gli creda. Nel corso degli anni i fornitori hanno lavorato duramente per perfezionare questo argomento di vendita e penso che sia importante analizzarlo a fondo.

La causa di fondo dei problemi è che i fornitori cercano quasi sempre il modo di ridurre i propri costi aumentando al contempo i profitti ottenuti dai clienti. Questo è all'origine di gran parte di ciò che altrimenti verrebbe percepito come un comportamento bizzarro.

Una cosa che moltissimi fornitori tentano di fare è limitare gli scenari in cui il loro prodotto sarà supportato. In questo modo si predispongono a non fornire affatto supporto: il supporto è costoso e poco affidabile. Si tratta di una strategia comune. In alcuni casi è talmente aggressiva che non esiste nemmeno uno scenario di distribuzione in produzione accettabile.

Un mezzo molto comune per ottenere questo risultato è non supportare alcun sistema operativo a sua volta supportato, deprecando di fatto il software dello stesso fornitore (per esempio, oggi questo significherebbe supportare soltanto Windows XP e versioni precedenti). Un altro esempio è supportare esclusivamente prodotti che non sono concessi in licenza per il caso d'uso previsto (un esempio sarebbe richiedere l'utilizzo di un prodotto come Windows 10 come server). E uno dei casi più comuni è vietare la virtualizzazione.

Questi scenari mettono i clienti in posizioni difficili perché, da un lato, devono attenersi alle migliori pratiche del settore, alle linee guida standard di distribuzione, agli strumenti e alle politiche interne; dall'altro, hanno fornitori che spesso vietano una corretta progettazione, pianificazione e gestione dei sistemi. Queste esigenze sono in contrasto tra loro.

Naturalmente, nessuno si aspetta che ogni fornitore supporti ogni possibile scenario. È necessario applicare dei limiti. Ma c'è un baratro enorme tra il supportare sistemi ragionevoli e ben distribuiti e l'imporre attivamente distribuzioni inaccettabilmente scadenti. Ci auguriamo che i nostri fornitori si comportino da partner commerciali e condividano un interesse comune nel nostro successo o, quanto meno, nel successo del loro prodotto, e non cerchino direttamente di compromettere entrambe queste cause. Ci auguriamo che, come minimo assoluto, venga fornito un supporto basato sul massimo impegno per qualsiasi scenario di distribuzione ragionevole e che un supporto garantito venga probabilmente offerto per scenari progettati correttamente e conformi alle migliori pratiche.

Immaginate un mondo in cui rispettare i limiti di velocità e allacciare la cintura di sicurezza invalidasse la garanzia della vostra auto e in cui otterreste assistenza soltanto se guidaste in modo spericolato e senza protezioni!

Vanno comprese alcune cose importanti sulla virtualizzazione. La prima è che la virtualizzazione è una migliore pratica del settore di lunga data e ci si aspetta che venga utilizzata in qualsiasi scenario di distribuzione in produzione dei servizi. La virtualizzazione non è affatto una novità: anche nel mercato delle piccole imprese rientra nella categoria delle migliori pratiche già da ben oltre un decennio, e da molti decenni nell'ambito enterprise. Abbiamo da tempo superato il punto in cui far girare i sistemi in modo non virtualizzato è considerato accettabile, e questo vale anche per le distribuzioni legacy in essere da molto tempo.

Esistono, naturalmente, sempre rare eccezioni a quasi ogni regola. Alcuni sistemi necessitano dell'accesso a hardware molto particolari e la virtualizzazione potrebbe non essere possibile, sebbene con il moderno passthrough dell'hardware oggi questo sia pressoché inaudito. E alcuni sistemi a latenza estremamente bassa non possono essere virtualizzati, ma di norma si limitano soltanto alle più grandi banche d'investimento internazionali e agli hedge fund più aggressivi, e perfino la maggior parte di quei casi d'uso tradizionali è stata eliminata dai miglioramenti nella virtualizzazione, rendendo rare anche quelle situazioni. Ma la conclusione è che, se non potete virtualizzare, dovreste rammaricarvene, e saprete con chiarezza perché nella vostra situazione sia impossibile. In tutti gli altri casi, il vostro server deve essere virtuale.

Non è importante?

Se un fornitore non vi consente di seguire le migliori pratiche standard per distribuzioni sane, che cosa dice questo dell'opinione che il fornitore ha del proprio prodotto? Se stessimo parlando di qualsiasi altra distribuzione, ci chiederemmo immediatamente perché stiamo distribuendo un sistema in modo così scadente quando intendiamo dipenderne. Se il nostro fornitore ci costringe a comportarci in questo modo, dovremmo reagire allo stesso modo: se il fornitore non prende sul serio il prodotto nello stesso grado in cui noi prendiamo il minore dei nostri servizi IT, perché dovremmo farlo noi?

Si tratta di un "disadattamento di impedenza", come diciamo negli ambienti ingegneristici, tra le nostre esigenze (sistemi di produzione) e il modo in cui il fornitore che realizza quel sistema sembra trattarli (sistemi per hobby o intrattenimento). Se dobbiamo dipendere da questo prodotto per le nostre attività, abbiamo bisogno di un fornitore che sia allineato e comprenda le esigenze aziendali, che abbia una mentalità orientata alla produzione. Se il prodotto non è pensato per le aziende o pronto per esse, dobbiamo esserne consapevoli. Dobbiamo chiederci perché riteniamo di dover utilizzare in produzione un servizio, dal quale dipendiamo e per il quale richiediamo supporto, che non è destinato a essere utilizzato in tale modo.

È supportato? Viene testato?

Una cosa che spesso viene trascurata dalla prospettiva dei clienti è se le risorse di supporto necessarie per un prodotto siano effettivamente disponibili. Non è raro che il team che supporta un prodotto si riduca, o addirittura scompaia, mentre l'azienda continua a vendere il prodotto nella speranza di spremerlo il più possibile e conta o sul cavarsela alla meglio di fronte a un problema o sul restituire semplicemente i fondi al cliente qualora il fornitore venga colto in una situazione in cui è semplicemente incapace di supportarlo.

La maggior parte dei contratti software stabilisce che il danno massimo che può essere estratto dal fornitore è il costo del prodotto, ovvero l'importo speso per acquistarlo. In un caso come questo, il fornitore non corre alcun rischio offrendo un prodotto che non è in grado di supportare, anche facendo pagare un sovrapprezzo per il supporto. Se il cliente riesce a utilizzare il prodotto, benissimo: vengono pagati. Se il cliente non ci riesce e il fornitore non riesce a supportarlo, perdono soltanto del denaro che non avrebbero mai ottenuto altrimenti. È il cliente ad assumersi tutto il rischio, non il fornitore.

Questo suggerisce, ovviamente, che vi sia poco o nessun test continuativo del prodotto, e ciò dovrebbe destare ulteriore preoccupazione. Il solo fatto che il prodotto funzioni non significa che continuerà a funzionare. Avviare e mettere in funzione un prodotto non supportato, o peggio non supportabile, significa dipendere sempre più nel tempo da un prodotto con un livello di supporto potenziale probabilmente decrescente, che peggiora lentamente nel tempo proprio mentre ci si aspetterebbe che la necessità di supporto e la dipendenza dal software aumentino.

Se un prodotto proprietario viene distribuito in produzione e si decide di rinunciare alle distribuzioni conformi alle migliori pratiche per assecondare le richieste di supporto, come può tutto questo collocarsi in una matrice decisionale? Dovrebbe forse implicare che un supporto adeguato non esiste? Di nuovo, come prima, questo implica un disallineamento rispetto alle nostre esigenze.

 

Viene ancora sviluppato?

Se le esigenze di distribuzione del software seguono pratiche vecchie e superate, oppure richiedono software o progettazione obsoleti (o non ragionevolmente attuali), allora dobbiamo interrogarci sulla probabilità che il prodotto sia attualmente in fase di sviluppo. In alcuni casi possiamo accertarlo osservando per qualche tempo il ciclo di rilascio del software, ma non in tutti i casi. Esiste il ragionevole timore che il prodotto possa essere morto, senza alcun team di sviluppo rimasto a lavorarci. Il codice potrebbe semplicemente essere vecchio, debito tecnico che viene venduto nella speranza di guadagnare ancora qualche ultimo dollaro da una base di codice ormai abbandonata. Questo processo è in realtà molto più comune di quanto spesso si creda.

Le software house più piccole spesso riescono a sviluppare un pacchetto software iniziale, a immetterlo sul mercato e a renderlo disponibile per la vendita, ma non riescono a permettersi di trattenere o ricostituire il proprio team di sviluppo dopo il rilascio (o i rilasci) iniziale. Questo è, di fatto, uno scenario molto comune. Lascia i clienti con un prodotto che ci si aspetta diventi sempre meno valido nel tempo, con scenari di distribuzione sempre più rischiosi e dati sempre più difficili da estrarre.

 

Come può essere supportato se la piattaforma non è supportata?

Un paradosso comune di alcune situazioni più estreme è il software che, per qualificarsi come "supportato", richiede altro software che è a sua volta fuori supporto oppure non è mai stato supportato per il caso d'uso previsto. Esempi comuni di ciò sono richiedere che un sistema server giri sopra un sistema operativo desktop oppure richiedere versioni di sistemi operativi, database o altri componenti che non sono più affatto supportate. Quest'ultimo scenario è spaventosamente comune. In una situazione del genere, ci si deve chiedere se possa mai esistere una distribuzione in cui il software possa essere considerato "supportato". Se una parte dello stack è sempre fuori supporto, allora l'intero stack è non supportato. Ci sarebbe sempre un motivo per cui il supporto potrebbe essere negato, qualunque cosa accada. La stessa ragione per cui dovremmo quindi pretendere di evitare le migliori pratiche escluderebbe in egual misura la scelta del software stesso fin dall'inizio.

Mancano competenze e conoscenze del settore?

Forse il problema che affrontiamo con le difficoltà di supporto software di questa natura è che il team (o i team) che creano il software semplicemente non sanno come si realizza un buon software e/o come si distribuiscono buoni sistemi. Questa è tra le ragioni più ragionevoli e valide che potrebbero spingerci verso questa situazione. Ma, come le altre ragioni ipotetiche, ci lascia preoccupati riguardo alla qualità del software e alla possibilità che il supporto sia davvero disponibile. Se non possiamo fidarci del fornitore per gestire correttamente le parti più visibili del sistema, perché dovremmo rivolgerci a lui come ai nostri esperti per le parti che non possiamo verificare?

Il grande problema

Il grande problema di fondo del software che pone richieste discutibili in materia di distribuzione e manutenzione in cambio dello sblocco di un supporto altrimenti trattenuto non è, come tipicamente supponiamo, una questione di qualità complessiva del software, bensì una questione di pratiche di supporto e sviluppo sostenibili. Il fatto che questi problemi suggeriscano una preoccupazione significativa per il supporto a lungo termine dovrebbe indurci a interrogarci con forza sul perché stiamo scegliendo questi pacchetti in primo luogo, aspettandoci al contempo da essi un supporto robusto quando, fin dall'inizio, abbiamo preoccupazioni molto visibili e molto serie.

Esistono, naturalmente, casi in cui non esistono altri prodotti software a soddisfare una necessità, oppure nessuno di sostenibilità più ragionevole. Questa situazione dovrebbe essere estremamente rara e, se esiste, dovrebbe essere vista come una grande opportunità di mercato per un fornitore che intenda entrare in quel particolare ambito.

Da una prospettiva aziendale, è imperativo che le migliori pratiche dell'infrastruttura tecnica non vengano completamente ignorate in cambio di un seguire alla cieca, o quasi, requisiti del fornitore che, in qualsiasi altro caso, verrebbero considerati spericolati o poco professionali. Perché così spesso trascuriamo di pretendere l'eccellenza dai prodotti fondamentali da cui le nostre aziende dipendono in questo modo? Mette a rischio le nostre aziende, non solo per l'azione in sé, ma in misura assai maggiore per i rischi impliciti nell'esistenza stessa di un simile requisito.