#OpenERP breve recensione

OpenERP è uno dei pochi software ERP OpenSource. Gli ERP sono sostanzialmente software gestionali che integrano funzionalità avanzate quali, ad esempio, sistemi di controllo di produzione, CRM, gestione del magazzino e molto altro.
OpenERP è un software stabile (siamo ormai giunti alla versione 6.1), tradotto in numerose lingue e ovviamente c’è una traduzione italiana ufficiale: quindi è un sistema che certamente è utilizzabile in produzione e si adatta agevolmente sia alle piccole aziende sia alle grandi corporate.

Una delle cose che personalmente reputo importanti in OpenERP è l’architettura che sta alla base: OpenERP è un sistema client-server realizzato avendo in mente l’apertura che hanno tutti i software più blasonati.
Il server è solo “il motore” del sistema, è realizzato in Python e si appoggia ad un database PostgreSQL; è possibile comunicare con il server solo attraverso delle API raggiungibili attraverso il protocollo standard XML-RPC.
Per utilizzare queste API, è possibile ovviamente usare delle interfacce installabili sulla propria workstation già pronte: sono tutte realizzate in Python attraverso la libreria PyGTK, sono aperte e funzionano su client Windows, MacOS e Linux. Oltre ai client installabili sul PC, c’è un ottimo client web che è possibile anche installare direttamente sulla stessa macchina ove è installato OpenERP Server.

E’ ovviamente possibile usare direttamente le API e il protocollo XML-RPC per far comunicare la propria applicazione con OpenERP. Ad esempio un ecommerce può sfruttare le API per avere in tempo reale la situazione del magazzino e per generare automaticamente i documenti ed i processi in caso d’ordine. A tal proposito, già esiste un interfacciamento funzionante e collaudato con il software di e-commerce “Magento”.

Essendo un software OpenSource, è aperto anche a funzionalità aggiuntive. Difatti OpenERP ha una architettura modulare ed è già presente un ecosistema di moduli ufficiali e di terze parti, comprese alcune interessanti verticalizzazioni già pronte come quella per le associazioni e per le case d’asta.
Il mio spassionato consiglio, è di non partire con una installazione completa di tutti i moduli, ma di partire con una installazione base e di aggiungere i moduli necessari solo in caso di effettiva esigenza: una installazione complenta, difatti, mette a disposizione una tale quantità di opzioni che è facile perdersi e disorientarsi.

Il capitolo moduli riserva però una sorpresa riguardo al meccanismo di licenza, che è una anomalia nel panorama delle modalità di distribuzione di software OpenSource. OpenERP, come molti altri software, esiste in due versioni: gratuita e a pagamento. Queste due versioni sono identiche, non esiste alcuna funzionalità aggiuntiva nella versione a pagamento ripetto alla versione gratuita.
La differenza riguarda esclusivamente la metodologia di sviluppo dei moduli: se una azienda ha necessità di una particolare funzione che non è presente originariamente nel sistema o in uno dei moduli installati, è possibile contattare una delle aziende certificate per farsi realizzare il modulo che soddisfi le proprie esigenze. Se si sta utilizzando la versione gratuita è obbligatorio rendere disponibile nell’ecosistema il modulo realizzato, altrimenti è possibile mantenerlo “riservato”.

Lo sviluppo di una applicazione sul cloud

Si fa molto parlare di cloud, ma se si spera che solo spostando una propria applicazione web da un comune hosting ad un cloud essa diventi scalabile… beh, si è parecchio lontani dalla realtà.
Una applicazione sul cloud non scala automaticamente, deve esserci un sistema in grado di far scalare l’applicazione aprendo nuove istanze all’occorrenza: quindi ci deve essere un approccio sistemistico con un load balancer in grado di dirottare il traffico su più host facendo scalare il sistema. Nella più semplice delle ipotesi, fissiamo un massimo di carico per ciascun application server e usiamo i successivi solo dopo una saturazione del primo; in ipotesi più complesse, sarà lo stesso load balancer in grado di interfacciarsi con le API del proprio IaaS per aprire/chiudere istanze di application server in modo da destinare le risorse della propria infrastruttura a ciò che realmente serve in quel preciso istante.
Sembrerebbe solo una questione sistemistica… invece no: il codice deve essere adatto a lavorare in una simile configurazione e questo lo può fare solo chi sviluppa il codice.
A mio avviso, due sono le cose fondamentali che devono essere tenute in considerazione in fase progettuale: l’architettura del datastore e, ovviamente, gli stati macchina.

Riguardo al datastore, bisogna fare i conti con la qualità/velocità del sistema di memorizzazione del cloud. Chi possiede un proprio cloud, ci tiene che sia totalmente scalabile e, quindi, avrà sia un sistema di virtualizzazione “plug-and-play” ma anche uno storage che ragiona con la stessa logica. Ciascun operatore si affiderà al sistema che più gli aggrada: sul versante opensource, troviamo un discreto numero di filesystem cluster tra cui i più conosciuti sono GlusterFS, Cheph e MooseFS.
Questi filesystem hanno tutti in comune il fatto che per aumentare lo spazio disponibile, è suffuciente aggiungere un nuovo nodo al cluster, quindi il filesystem scala virtualmente all’infinito. Di contro, le prestazioni di un filesystem di questo tipo, in assoluto non sono minimamente paragonabili ad una SAN Fibre Channel, anche se la possibilità di mantenere un considerevole numero di repliche su più server li rende ottimi in situazioni in cui si richiedono molte letture contemporanee ad uno stesso file.
Conoscendo a priori questo limite dell’infrastruttura hardware, si faranno le dovute considerazioni a livello sistemistico riguardo la scelta del datastore più adatto: ad esempio, un comune database relazionale come PostgreSQL o MySQL, nonostante l’abbinamento a sistemi di cache come memcached, non è certo il sistema più adatto, sia perchè richiederebbe una buona velocità del disco, sia per la difficolta nello scalare.
Ultimamente, proprio per far fronte a questo problema, stanno fiorendo molti database del tipo NoSQL che perdono la sintassi e alcune caratteristiche tipiche dell’SQL ma che permettono di avere maggiori prestazioni e un migliore funzionamento in caso di architettura distribuita su più server. Giusto per citarne qualcuno: MongoDB, Cassandra, CouchDB; vi rimando a questo articolo per un confronto tra queste soluzioni.
Ricordiamoci che in una applicazione “sul cloud” il Datastore non è semplicemente il posto dove vengono registrati i dati dell’applicazione ma è il luogo dove vengono registrati TUTTI i dati dell’applicazione. Questo per dire, giusto per fare un esempio, che se la nostra applicazione eseguirà l’upload di una immagine, questa dovrà essere memorizzata sul Datastore e non sul filesystem locale, in modo da evitare problemi di sincronizzazione in caso di utilizzo contemporaneo di più Application Server.

E qui entra in gioco anche l’aspetto degli stati macchina: sebbene abbiamo escluso problemi di sincronizzazione dei dati utilizzando esclusivamente il datastore comune e non il filesystem, ci possono essere alcuni aspetti del nostro applicativo che sfuggono da questa logica: bisogna prestare particolare attenzione agli aspetti legati “a quel particolare server”, tra cui, ad esempio, la gestione delle sessioni e di eventuali sistemi di cache.
Qui ovviamente è solo il programmatore che può farsi carico di questi aspetti, anche se l’utilizzo di framework di sviluppo esplicitamente studiati per realizzare applicativi Cloud-Oriented può facilitargli di molto la vita. Andando “oltre oceano” a vedere come si muovono i colossi vediamo che a fianco di framework già consolidati come Django e Rails, inizia a prendere piede Lift che è un framework basato sul linuguaggio Scala (che deriva da Java); questo framework, sebbene sia più giovane rispetto agli altri citati e quindi non disponga ancora di un ecosistema sviluppato, è stato realizzato avendo in mente proprio la scalabilità su più application server. Facendo un paragone con Ruby, Scala è molto più performante anche se è molto più esoso nell’utilizzo della RAM.

Foursquare, il social network geografico, è un big che utilizza esclusivamente Lift con database MongoDB.
Giusto per citare un altro caso, Twitter è una web application realizzata per lo più in Ruby on Rails, però recentemente ha riscritto la parte più interna del codice della timeline in Scala usando come datastore Redis, proprio per migliorarne la scalabiltà.

In Italia, Python/Django e Ruby on Rails stanno prendendo piede in questi anni e, purtroppo, non esiste ancora una offerta di soluzioni hosting dedicate a questi sistemi comparabile con i comuni stack LAMP. In qualsiasi caso, il futuro locale secondo me sarà su questi due framework. però, per un programmatore appena uscito dall’Università dove ha sbattuto la testa per anni su Java e che ha mire di lavoro anche oltre oceano, reputo che sia importante (e meno impegnativo) approfondire Scala/Lift prima di dedicarsi allo studio di Python/Django e Ruby on Rails che sarebbero per lui totalemte nuovi.