Un’approfondita analisi condotta da Giulio Destri su come affrontare le problematiche di gestione di infrastrutture IT basate su software open source

[section_title title=La soluzione è open source? parte 4]

Infrastrutture diffuse basate su software open source

L’architettura LAMP (Linux, Apache, MySQL, PHP) è oggi senz’altro quella maggiormente usata per costruire siti e portali Web, come mostrato in figura 5 dalle percentuali di mercato dei tre sistemi di gestione contenuti (CMS) maggiormente diffusi, tutti basati su LAMP [6][7].

Soluzione open source 5

E’ possibile scomporre logicamente l’architettura LAMP come mostrato in figura 6, dove si vede che la visualizzazione dei contenuti è affidata ad una pila di elementi. Ogni strato della pila offre servizi agli strati superiori, consentendo ad essi di svolgere le funzioni affidate. Ma proprio per questo ogni strato della pila dipende dagli strati sottostanti. Le personalizzazioni possono essere fortemente dipendenti da una particolare versione del CMS. A sua volta il CMS dipende dalle versioni di PHP installate e spesso la migrazione ad una versione successiva di PHP richiede adattamenti più o meno ampi dei CMS. Il driver di comunicazione col DBMS MySQL di una particolare versione di PHP può avere problemi di funzionamento con nuove versioni di MySQL. Apache può richiedere aggiornamenti di sicurezza. Le librerie di run-time basate su un kernel Linux potrebbero non essere adatte ad eseguibili (MySQL, PHP, Apache) compilati per versioni precedenti.
Da questa analisi appare evidente la necessità di gestire l’installazione completa con i suoi strati con l’approccio ITIL/TOGAF visto in precedenza: per poter garantire la continuità di esercizio bisogna conoscere le dipendenze che ogni strato logico ha rispetto agli altri e rispettarle.
Si deve considerare che ciascuno di questi elementi è gestito da consorzi indipendenti, per quanto parzialmente coordinati fra loro. L’evoluzione dei vari elementi è quindi parzialmente indipendente da quella degli altri. L’aggiornamento degli elementi deve quindi essere gestito con estrema attenzione.

 Soluzione open source 6

In modo analogo possiamo analizzare la struttura di un application server Java basato su Linux, il cui contesto è mostrato in figura 7. L’application server si basa sulla versione di Java installato sul server Linux, che deve ovviamente essere compatibile con la versione del sistema operativo. Oltre alle librerie che formano l’application server, saranno presenti framework applicativi come Hibernate e Spring, sui quali si baserà il codice Java specifico dell’applicazione Web. Quindi ecco una stratificazione ancora più complessa del caso LAMP precedente. Anche in questo caso vale quanto detto in precedenza.

Soluzione open source 7

Un altro esempio è dato dal DBMS Oracle che, nella versione 9i, per dipendenza da librerie di run-time delle sue componenti Java, richiedeva di essere installato su versioni di Linux precedenti di un paio di anni.
Possiamo trarre un primo giudizio: i sistemi open source sono più complessi dei sistemi closed e il numero di variabili iniziali e di evoluzione dei vari componenti è superiore.
I vari elementi che formano un’architettura open source completa hanno evoluzione separata, ma proprio per questo potenzialmente più rapida. Ad esempio, la correzione dei bug di sicurezza è di solito molto più rapida nei software open source.
Diventa però più complessa la gestione dei sistemi di produzione, che deve essere necessariamente soggetta a maggiore controllo. E anche l’integrazione con sistemi closed source, come ad esempio tra Linux e Windows, è sicuramente complessa.
Nel prossimo paragrafo vedremo una metodologia per infrastrutture IT basate su open source.