lunedì 23 agosto 2010

Pirro e l'Oracolo

Quando iniziai ad occuparmi di Linux e di open source nel 2001 l'unico antagonista del colosso microsoft nel campo dell'office era il pacchetto openoffice che, staccatosi da staroffice iniziava a muovere i primi passi. In quegli anni il logo della suite, pesante e monolitica era un globo azzurro con due gabbiani a simboleggiare la libertà dal software proprietario.
È quindi per me abbastanza buffo aprire l'evoluzione ultima di questo prodotto e trovarci la scritta ORACLE che nell'ultima release ha sostituito SUN. Sia chiaro, sono entrambi due aziende i cui interessi non necessariamente sono allineati con quelli della comunità open source, ma Oracle per me rappresenta qualcosa di più per il semplice fatto che appartengo a quella che chiamo la setta dei DBA ORACLE che, un po' come il mondo parallelo degli inservienti di scrubs, ha un modo molto particolare di porsi nei confronti dei database.

I migliori prodotti del mondo
Non ci sono dubbi. Quando si parla di Oracle stiamo avendo a che fare con il miglior software presente sul mercato. Niente e nessuno lo batte. I vari prodotti a disposizione di clienti e sviluppatori, offrono una vasta gamma di funzioni che progressivamente si sono affiancate al database per definizione. E se qualcun altro fa le stesse cose, Oracle le fa meglio.
Questa è più o meno la conversazione tipo che si può affrontare con un DBA Oracle parlando dei prodotti della casa di Redwood Shores. Personalmente, facendo parte di questa categoria mi sento di confermare quasi tutte queste affermazioni, principalmente per un motivo.
La qualità di un qualsiasi professionista che abbia lavorato con Oracle è fuori discussione. Chiunque lavori con questi sistemi è forzato a dare il massimo senza sconti in quanto l'elevata complessità e la ricchezza di funzionalità rappresentano una sfida costante con la quale confrontarsi e accrescere il proprio bagaglio di conoscenze.
Se poi ci mettiamo un settore marketing che fa bene il suo lavoro allora le affermazioni in corsivo possono essere prese come memento da scolpire nella pietra anche se poi nei fatti, specialmente per alcuni prodotti non strettamente legati alla gestione dei dati, si fa fatica a riconoscerne il primato.
Alla luce di ciò è quindi stato un evento significativo nella mia vita professionale, quando di punto in bianco ho deciso di occuparmi di PostgreSQL, il vero concorrente open source di Oracle, che in maniera alquanto altisonante dichiara di essere il più avanzato database libero.

Un elefante dai piedi d'argilla
Nel lontano 2005 la versione di produzione era la 7.4 che, confrontata con la sua controparte, Oracle 9i, risultava essere alquanto arretrata e rudimentale.
Difficile reggere il passo con l'assenza di una gestione seria della memoria una rozza gestione dello spazio disco e con carenze strutturali che esponevano al rischio di corruzione dei dati sia in caso di crash che di riempimento della directory data.
La mia scelta però fu ben motivata in quanto il salto generazionale che stava per avvenire con la versione 8.0 era notevole. Con questa versione venivano finalmente introdotti concetti moderni come le tablespace e nel contempo avveniva una ristrutturazione dell'algorimo di gestione della memoria, che passava dal rudimentale LRU al più complesso 2queue. Venivano infine risolti i problemi di corruzione dati dovuti a crash del database e finalmente compariva un meccanismo di protezione per il failure prodotto dal wrap around dei transaction id.
Alla luce di ciò viene spontaneo chiedersi come mai il livello di penetrazione di questo notevole prodotto è ancora modesto. Le motivazioni che ho analizzato sono varie e complesse ma generalizzando posso inquadrarle in due grossi blocchi.
L'assenza di un sistema strutturato per il supporto e la documentazione e un'advocacy che fa acqua da tutte le parti.

Che ce ne facciamo del petrolio? Noi abbiamo il boiler!
Torniamo un attimo al mondo dei DBA Oracle. La risposta alla domanda “dove trovo la documentazione per l'operazione XY?” è sempre la stessa: “il metalink”. Chiunque abbia esperienza su Oracle prima o poi s'è confrontato con questo repository di documentazione e, in caso di prodotti con licenza non da sviluppatore, anche di supporto e assistenza tecnica.
La stessa domanda rivolta ad un DBA PostgreSQL ha un range di risposte non deterministico: “la mailing list admin, il wiki, la chat IRC, il sito tal dei tali, mandami una mail che ti dico, etc. etc.”. Se poi osserviamo lo scalcinato panorama italiano la situazione è ancora peggiore in quanto, a parte il tentativo che ho portato avanti da solo di produrre un sito di documentazione in italiano con annessa mailing list, non c'è assolutamente nulla che dia un minimo di parvenza di professionalità comunitaria.
Difficile quindi convincere qualcuno ad adottare un prodotto senza che sia definito un sistema di documentazione ufficiale che imponga uno standard di formattazione dei documenti con contenuti ufficialmente approvati dal team di sviluppo.
Una cosa che ho imparato a fare nei primi mesi di apprendistato come DBA Oracle è stata proprio la messa in opera di documenti organizzati ed esaustivi per permettere a chi non fosse informato sullo stato dei sistemi di avere una visione della situazione e degli eventuali rischi/problemi ad essa legati.
Devo ammettere che l'azienda per cui ho lavorato e che mi ha permesso di raggiungere una buona professionalità è particolarmente strutturata, ma queste cose non si imparano dall'oggi al domani e sicuramente un buon incentivo ad attestarsi in pratiche di questo genere è dato anche dal lavoro quotidiano con un un prodotto, le cui metodiche sono orientate alla chiarezza ed al consolidamento di pratiche di qualità.
Pertanto finché gli utenti non avranno un sistema che cataloghi la documentazione in maniera strutturata e dotato di un motore di ricerca che permetta di accedere ai singoli documenti in maniera mirata le possibilità di portare un utente dal mondo dove la risposta è sempre rintracciabile, quale è un Oracle o un MySQL, volendo restare nel mondo open source, saranno sempre molto basse. Inutile dire che il wiki o l'accesso agli archivi delle mailing list, non sono assolutamente adatti a tale scopo.

La vittoria di Pirro
Sottovalutare la strategia di marketing è una grave mancanza, ma ci sono comportamenti decisamente peggiori.
Ad esempio insistere in una modalità operativa priva di spunti innovativi che va avanti da anni è assolutamente deleterio sia per il prodotto che per la comunità.
Per spiegarmi meglio farò un esempio che mi ha toccato di persona.
Fino al 2006 intorno a PostgreSQL ruotavano, e tuttora esistono, un tot di conferenze organizzate con cadenza annuale e prettamente orientate agli addetti ai lavori. Eventi di questo genere permettono un incontro fisico degli sviluppatori che sono sparsi ai quattro capi del mondo e, oltre a delineare la direzione dello sviluppo, permettono un interscambio decisamente più efficiente dell'approccio remoto.
Nel 2007 grazie ad una mia idea fu organizzato un evento completamente diverso per natura e per contenuti, il PostgreSQL Day, meglio conosciuto come PGDay. La novità di questa conferenza, della cui organizzazione mi sono occupato nella prima edizione, fu prima di tutto negli argomenti dei talk, che finalmente erano diretti ad un pubblico di non addetti con sostanziali ammiccate ai responsabili dei CED.
Altra due novità importanti sono state la presenza di mini corsi di formazione tecnica e la quasi totale assenza di spesa per i visitatori, salvo i suddetti mini corsi la cui iscrizione aveva un costo di 11 euro.
Il risultato di questa conferenza fu decisamente entusiasmante visto che una buona percentuale dei circa 200 partecipanti era composta da responsabili IT o addirittura titolari d'azienda, venuti ad informarsi su di un prodotto potenzialmente valido le loro imprese.
Sfortunatamente la conferenza del 2007, tenutasi a Prato, è rimasto un evento isolato in quanto, nel 2008 si è tenuta quella che è poi è diventata la conferenza del PGDay europeo, con un programma internazionale che si è appiattito di nuovo su argomenti per addetti ai lavori e al cui interno è stato inserito il PGDay Italiano.
Il programma di quest'ultimo lo considero, oggettivamente alquanto mediocre con dei talk ad argomentazione prettamente tecnica e privi di omogeneità di traccia.
Sfortunatamente, non avendo preso parte all'organizzazione di questo evento ne del successivo, avvenuto nel 2009 e il cui programma è sostanzialmente identico a quello del 2008, non posso entrare nel merito delle scelte fatte dal comitato organizzatore.
Fatto sta che, dopo un evento che sembrava aver scosso il panorama di PostgreSQL dal suo torpore di prodotto di nicchia, nessuno ha voluto continuare su quella strada che aveva reso visibile il database a potenziali utilizzatori, rendendo il PGDay del 2007 una vittoria di Pirro.

sabato 21 agosto 2010

Cracks in time and space

The Doctor Who season 5 breadcrumb path was the obsessing precence of cracks in time and space chasing the Doctor and companion.
Now the mistery of the cracks is unveiled as a simple whovian paradox.


cracks in time by ~who-fan96 on deviantART

lunedì 2 agosto 2010

Il delfino e l'elefante

È qualche giorno che il google alert settato sulla parola chiave PostgreSQL mi inonda di link ad articoli, per lo più in italiano, che parlano dello spegnimento dei server dedicati alla buildfarm, un sistema applicativo per il test e la ricerca di bug su PostgreSQL in maniera automatizzata, da parte di Oracle.

Faccio una piccola divagazione a beneficio di chi non conosce le varie vicissitudini che hanno caratterizzato il mondo dei DBMS open source negli ultimi anni.
Fino al 2007 la Sun Microsystems ha investito molto nel database PostgreSQL sia in termini di supporto che di sviluppo offrendo alla comunità un gruppo di server applicativi per la suddetta buildfarm e ponendo il DBMS dell'elefante al centro di un pacchetto integrato che sembrava potesse mettersi in competizione con prodotti commerciali di grande caratura e costo.

Successivamente ci fu un dietrofront clamoroso e le attenzioni di Sun si concentrarono su MySQL culminando nell'acquisizione di MySQL AB.
Nell'ultimo anno l'acquisto di Sun da parte di Oracle ha fatto si che MySQL stesso divenisse un prodotto di Oracle pur restando nella situazione anomala della doppia licenza GPL/Commerciale.

Personalmente dello spegnimento di questi server non mi importa nulla, anzi mi sembra una cosa alquanto normale visto che molto più di MySQL, che in tutta onestà non riesco a definire un Database Relazionale in senso ortodosso, PostgreSQL è un pericoloso concorrente della casa che produce il database per definizione.

Capisco che questa mia affermazione può essere oltremodo forte, specialmente per le orecchie delicate degli informatici italiani che spesso confondono la considerazione tecnica con l'attacco personale, ma non approfondirò ulteriormente questo concetto per evitare che questo mio scritto diventi un pesante trattato sui database relazionali infarcito di termini tecnici.
Lo stesso farò per il discorso sulla doppia licenza di MySQL.
Se volete approfondire questo pdf http://www.flameeyes.eu/articoli/mysqlsevil.pdf che chiarisce in maniera molto dettagliata tutte le implicazioni di questa anomalia.
Il motivo che mi ha spinto a scrivere è sostanzialmente una perplessità indotta da alcuni colloqui di lavoro su posizioni in cui veniva ricercato un DBA MySQL.

Le situazioni in cui mi sono ritrovato sono state fondamentalmente due.
La prima in cui una grossa ditta aveva deciso di affidarsi alla versione GPL di MySQL in quanto quella commerciale non aveva le funzionalità di cui avevano bisogno, e un'altra in cui era in atto una migrazione da una soluzione closed con database Oracle, ad una open source su database MySQL.

In entrambe le situazioni la domanda che mi è salita in gola è stata “why not PostgreSQL?”, considerato che l'utilizzo del DBMS dell'elefante porterebbe vantaggi non da poco grazie alle sue peculiarità che lo rendono molto più gestibile rispetto alla sua controparte forse-sono-open-source-ma-dipende-dalla-tua-licenza.

Nel primo caso l'utilizzo di PostgreSQL, essendo rilasciato sotto licenza BSD che a differenza della GPL non è infettiva, garantirebbe alla ditta il controllo completo sul codice sorgente senza dover sottostare a logiche commerciali ne tanto meno a politiche di rilascio forzato degli hack.
A discapito di ciò verrebbe da obiettare che PostgreSQL non ha un supporto commerciale solido ne tanto meno una comunità ricca come quella di MySQL. Inoltre l'assenza di funzionalità di replica degne di questo nome lo rendono inadatto a configurazioni di bilanciamento di carico tipiche invece della piattaforma MySQL.
In risposta a ciò posso solo affermare che con una struttura societaria in grado di personalizzarsi un DBMS il supporto esterno ha poco senso visto che la forza per fare tutto in casa c'è. Riguardo alla replica e al bilanciamento è da valutare quanto la necessità di averla dipenda da carenze di scalabilità del database piuttosto che da un vero bisogno indotto da carichi di lavoro importanti.

La seconda situazione, la migrazione dal prodotto closed ad open, dimostra una scarsa conoscenza del prodotto di destinazione e delle notevoli difficoltà che vanno a manifestarsi nel passaggio da un mero sistema operativo, solido ed efficiente quale Oracle è, ad un caricatore di plugin con una gestione della memoria rudimentale e con la gestione dello storage demandata a soluzioni di terze parti, quale MySQL è.
Inoltre, ricordando che MySQL AB acquisita da Sun è diventata un'azienda di Oracle, a conti fatti la transizione avviene da un Oracle affidabile ad un Oracle che fa finta di essere un database relazionale e che, secondo la mia modesta opinione, rischia di fare una brutta fine in quanto in diretta concorrenza con il prodotto gratuito, la XE, del colosso dei database.

Alla fine di questa breve considerazione viene quindi da chiedermi come mai i responsabili IT siano all'oscuro di un prodotto di classe enterprise come PostgreSQL.
Un DBMS non è un detersivo, la sua adozione avviene sulla base della conoscenza delle funzionalità del prodotto e sulla possibilità di ottenere documentazione chiara ed efficiente.

Da questo punto di vista la documentazione a corredo di PostgreSQL è notevole, ben fatta chiara e senza punti ambigui.
Quello che davvero manca affinché il prodotto venga visto dagli utilizzatori e dagli ISP sotto la stessa luce di MySQL è la presenza di una forma di certificazione di qualità sulle professionalità in gioco.

Volendo fare un paragone, vedo la rete di professionalità su PostgreSQL alla stessa maniera del web in Italia. In guazzabuglio di voci, spesso incompetenti, che però, per il fatto che non esista un'autorità certificante, si sentono autorizzate a dire la loro, spesso producendo castronerie dall'esito catastrofico.
È quindi chiaro come, nell'ambito ambito commerciale, una simile giungla sia un deterrente potentissimo all'adozione di un prodotto che invece potrebbe migliorare, e non di poco, le dinamiche aziendali.

Va bene quindi fare conferenze, documentazioni on line, promozioni e volantini.
Ma finché non ci sarà la certezza nei potenziali clienti che potranno contare su di una soglia di competenza minima nei professionisti di PostgreSQL il più avanzato database open source del mondo sarà sempre visto alla stregua di un gioco per smanettoni privo di potenzialità commerciali.