In un mio articolo precedente ho descritto Scalix come una valida alternativa a Microsoft Exchange. Non rinnego nulla di quanto ho scritto ed in effetti, nella nostra organizzazione, continuiamo ad utilizzare Scalix con ottima soddisfazione. Ma le osservazioni da me espresse sono assolutamente incomplete se non si inquadra il problema in un ambito più vasto, ponendosi una domanda più generica, ovvero : “Può una soluzione open-source sostituire Microsoft Exchange ?”
Di fronte a questa domanda, specialmente quando si analizza il problema nell’ottica di una nuova installazione presso un cliente, la mera scelta di un software server alternativo ad Exchange non è assolutamente sufficiente. Ci sono parecchie considerazioni da fare, e su tutte troneggia la più pesante : “Come funzionerà poi Outlook ?”
Già, perchè il vero problema non risiede nel tipo di software server che intendiamo sostituire, quanto piuttosto nella qualità e quantità di servizi che dovranno essere continuativamente erogati dai client Outlook distribuiti in azienda. Per quanto riguarda noi, il problema è stato aggirato eliminando proprio Outlook (in favore di Thunderbird) , ma non sempre questo è possibile, specialmente in ambiti nei quali (mi si passi lo sfogo) utenti “mentalmente” pigri troverebbero motivo di contestare la presenza di un nuovo client (con molte funzionalità non così immediatamente disponibili) in modo estremamente deciso. E questo è un altro degli effetti della sofisticata tecnica di lock-in utilizzata da Microsoft per lo sviluppo dei propri prodotti.
Un po’ di storia può aiutare a capire: nei lontani anni 80 lo standard RFC 822 iniziava a dare una forma organica alla messaggistica email, esisteva un protocollo antagonista (CMC X.400) al quale, nel 1992, il produttore di Windows iniziò ad aggiungervi il concetto di cartelle rinominando così il prodotto finale con l’acronimo MAPI (Mail Application Programming Interface). Da quei giorni il mondo delle email si è spaccato in due : da un lato i sistemi “puri” RFC 822, dall’altro il gruppo di applicazioni MAPI che sublima nell’accoppiata Microsoft Outlook/Exchange.
E’ opinione diffusa che la gestione delle email si riconduca essenzialmente alla manipolazione di indirizzi del tipo “nome@qualchecosa.xxx”, ma non è così. La tecnologia MAPI in abbinamento a CDO, che è diventato il protocollo di default per Exchange 2003, è in grado di gestire anche la “tipologia” dell’oggetto messaggio, adattandosi a comportamenti diversi in funzione dell’argomento trattato. Accade quindi che con Outlook/Exchange diventa possibile gestire non solo messaggi email, ma anche contatti, calendari, attività ecc. In realtà già Outlook da solo è in grado di gestire queste informazioni (all’interno dei propri file .PST), ma con l’accoppiata Exchange si estendono queste funzionalità aggiungendone di nuove come le condivisioni delle cartelle, la gestione del workflow e l’evidenza degli orari libero/occupato (Free/Busy) per gli altri utenti (nella medesima organizzazione) con i quali intendiamo pianificare dei meeting (solo per fare alcuni esempi).
E’ per questo che ci si riferisce spesso ad Outlook/Exchange come ad una soluzione GroupWare più che ad un server di posta. E da questa affermazione già si comprende come la domanda relativa alla sostituzione del solo server di posta sia espressa in modo errato. In realtà la domanda vera deve essere : “Come posso sostituire Microsoft Exchange facendo in modo che Outlook continui a darmi gli stessi servizi che mi dava con Exchange ?”
Questo è il nocciolo duro dell’analisi di una possibile migrazione. E a questo va aggiunto un altro pezzo di ragionamento che comprenda tutti quei software di terze parti che si integrano nell’accoppiata Outlook/Exchange. Restando in tema di messaggistica vengono subito alla mente i problemi legati alla sincronizzazione dei dati gestiti da Outlook con i dispositivi portatili come PDA e SmartPhones. Quasi tutti questi “attrezzi” sono dotati di software di comunicazione prevalentemente basati su ActiveSync o su software proprietari (vedasi ad esempio il Dektop Manager di RIM BlackBerry).
Nonostante esistano diversi software server che si propongono come replacement di Exchange (Scalix, OpenXchange, Zimbra, Kerio – quest’ultimo completamente closed), non sembra che questi riescano veramente ad incontrare un largo pubblico e, secondo la mia modesta opinione, la causa è proprio dovuta al fatto che in qualche modo devono rendere disponibili dei “connettori” per Outlook che “traducano” al volo tutte le comunicazioni con il software server in operazioni MAPI, con l’aggravante che spesso questi connettori non sono pienamente compatibili con ActiveSync o non vengono riconosciuti dai software di sincronizzazione. Giusto recentemente, per esempio, abbiamo provato ad installare Outlook in abbinamento ad un server Scalix (11.4) per testare la sincronizzazione di OL con i BlackBerry dotati del software Desktop Manager 4.7: niente da fare. Scalix garantisce la compatibilità solo con Desktop Manager fino alla versione 4.2. (Esistono comunque delle vie alternative come AstraSync oppure Notify ma sono soluzioni, non open e soprattutto non free, che fanno crescere lo stack di investimento necessario alla sostituzione di Exchange, riducendo di conseguenza l’economicità dell’operazione).
Ecco dunque perchè Outlook è stato, è ancora, e continuerà ad essere il client di posta preferito in ambiente professionale. Se è vero infatti che applicazioni per end-user di tipo open-source in altre categorie, come Firefox nei browser, oppure OpenOffice nella produttività desktop, hanno avuto un notevole successo, non di altrettanta fortuna godono le applicazioni open-source per la gestione delle email/PIM (Personal Information Manager), e restano relegate ad una utenza di nicchia che le preferisce o per motivi ideologici o per requisiti di alta specializzazione. Per esempio, nel confronto tra Outlook e Thunderbird, il primo soccombe se si cercano funzionalità avanzate quali la gestione delle identità, l’estensibilità, l’utilizzo di server SMTP preferenziali ecc. mentre è Thunderbird a perdere la battaglia quando ci si addentra nella gestione di Contatti e Calendari (il supporto Lightning è ancora alla versione 0.9 !!!! Nemmeno un major build !!!). Certamente utenti smaliziati potranno, con Thunderbird, ottenere comunque rubriche condivise (LDAP) cartelle pubbliche (IMAP) e calendari (iCal) ma non avranno un sostituto completo e paragonabile al 100% ad Outlook.
Quindi il problema legato alla sostituzione del server Exchange non deve essere affrontato dal lato “server” bensì dal suo lato client, ovvero dal lato di Outlook. Come per altri argomenti legati alla problematica di migrazione dal mondo Closed-Source al mondo Open-Source è necessario rivedere lo stack applicativo spesso dal basso. Se dovete fornire ai vostri utenti un semplice (si fa per dire) servizio di sola posta elettronica allora Exchange non vi serve e potrete trovare soluzioni molto affidabili (ed in alcuni casi anche più sicure) gettando un occhio nel mondo open-source. Se al contrario prevedete di “ingrassare” a causa di quella che chiamo la “bulimia tecnologica” che si concretizza nella necessità di integrare device diverse, fornire servizi di groupware avanzati (che raramente ho visto utilizzati appieno), probabilmente è necessario rivedere i piani con orizzonti di più lungo termine rinunciando per il momento all’open-source.
Da ultimo un occhio a costi complessivi: lo stack di investimento per l’installazione di Exchange è indubbiamente molto oneroso anche in considerazione del fatto che è costoso lo stesso sistema operativo su cui poggia. Il deployment di una soluzione Open-Source non è comunque esente da costi: a parte i costi di licenza del software server (sicuramente inferiori) per esempio Scalix 11.4 necessita di Apache, PostrgreSQL, Tomcat e Sendmail per poter funzionare. Non è particolarmente difficile installarli ma quando si iniziano ad analizzare le performance complessive si iniziano ad incontrare dei problemi. I server di posta accusano le peggiori criticità nell’aumento delle dimensioni dei dati da gestire e se l’azienda non è proprio di piccole dimensioni diventano necessari array di dischi condivisi per evitare i colli di bottiglia. Mettendo tutto insieme ci si ritrova per le mani un serio lavoro di amministrazione, molto più articolato di quanto un “Amministratore di Exchange” sia in grado di gestire. Se dunque nel lungo periodo i costi della soluzione open-source possono essere vincenti, nell’immediato abbandonare un sistema Exchange-centrico può non essere proprio facile. Si aggiunga anche il fatto che è quasi obbligatorio, se si intende mantenere Outlook, che si dovrà intervenire con l’installazione di idonee applicazioni anche su tutti i client.
Ancora una volta, quindi, se siete alla ricerca nel mondo open-source, di un sostituto di Exchange libero, gratuito e che lavori perfettamente con il vostro Outlook (e con tutto quello che ad Outlook viene attaccato), rimarrete sicuramente delusi.
2 Commenti
Francesco Vendola
18-Lug-2009 1Non sono daccrodo con la conclusione di questo articolo……dai una occhiata a POSTFIX e tutte le sue implementazioni e al progetto di yahoo ZIMBRA
admin
20-Lug-2009 2Grazie Francesco per il tuo commento. Sono assolutamente convinto che esistano molte soluzioni che possono validamente essere adottate quali server di posta, e solo poche che possano davvero rimpiazzare Exchange. In ogni caso pero’ c’e’ del lavoro da fare e nessuna puo’ dirsi perfettamente integrata con Outlook come lo e’ Exchange (del resto mi pare ovvio). Non era mia intenzione denigrare.