Odoo e microservizi: separare i domini per costruire sistemi che durano

Se hai già lavorato con Odoo in contesti di crescita, riconosci il pattern: l'ERP nasce come strumento di gestione, poi accumula personalizzazioni, poi diventa il punto di ingresso per portali esterni, poi assorbe logiche di integrazione con sistemi di terze parti. A un certo punto aggiornare la versione richiede mesi di test, e ogni nuova funzionalità rischia di rompere qualcosa di non correlato.

Il problema non è Odoo. È l'architettura.

In Unitiva progettiamo sistemi Odoo da anni, e una delle scelte più impattanti che facciamo insieme ai clienti è quella di definire con precisione dove finisce Odoo e dove inizia il resto. Questo articolo descrive come affrontiamo quel confine quando il contesto richiede un'architettura a microservizi.

Il principio: Odoo fa ciò per cui è stato progettato

Odoo è un ERP. Gestisce contabilità, magazzino, ordini, HR, vendite. Lo fa bene, con un modello dati coerente e un ORM su PostgreSQL che garantisce integrità transazionale.

Non è, strutturalmente, un sistema pensato per gestire migliaia di richieste HTTP al secondo generate direttamente da un portale B2C, né per processare stream continui da sensori industriali, né per esporre interfacce utente con requisiti di latenza sub-secondo. Non perché sia limitato, ma perché non è il suo dominio.

L'errore architetturale più comune che osserviamo è trattare Odoo come un monolite estensibile all'infinito: aggiungere moduli custom che gestiscono logiche esterne, costruire portali direttamente sopra l'ORM, fare polling continuo verso sistemi di terze parti dall'interno del gestionale. Il risultato è un ERP appesantito, difficile da migrare e che porta con sé ogni complessità verticale accumulata nel tempo.

L'approccio che privilegiamo è opposto: mantenere il core di Odoo pulito, delegare le complessità specifiche a servizi dedicati, collegare tutto tramite API.

Il modello in tre componenti

Quando progettiamo un'architettura a microservizi con Odoo al centro, il ragionamento si articola sempre su tre elementi distinti.

Odoo come sistema di record. 

L'ERP è la fonte autoritativa dei dati aziendali: anagrafiche clienti e fornitori, stato degli ordini, giacenze di magazzino, registrazioni contabili. Non è il layer che serve quelle informazioni verso il mondo esterno, ma il sistema che le possiede e le mantiene coerenti.

Microservizi per i domini specifici. 

Un portale B2B con requisiti di traffico elevato, un'app mobile per la forza vendita, un sistema di ricezione dati da macchinari industriali: ognuno di questi è un dominio con i propri requisiti di performance, resilienza e scalabilità. Costruirli come servizi indipendenti significa che possono scalare, fallire e aggiornarsi senza toccare il gestionale.

API come interfaccia contrattuale. 

I microservizi dialogano con Odoo tramite le sue API. Fino alla 18 chi voleva un'interfaccia comoda per i servizi esterni se la costruiva sopra JSON-RPC e XML-RPC. La 19 porta un endpoint nativo, una POST su /json/2/<modello>/<metodo> autenticata con API key, e una documentazione generata dal database su /doc. Per la maggior parte delle integrazioni il layer intermedio non serve più. È comunque un traffico di servizio, interno all'architettura, non il traffico diretto e imprevedibile generato dagli utenti finali. I microservizi non accedono direttamente al database e non condividono logica applicativa. Il contratto è definito, versionabile, sostituibile.

La conseguenza pratica più rilevante: se il portale B2B subisce un picco di traffico o va in errore, Odoo continua a operare normalmente. La separazione è il punto, non un effetto collaterale.

Tre scelte tecniche che fanno la differenza

Alcune decisioni di progettazione tornano sistematicamente quando implementiamo questa architettura. Non sono l'unico modo di procedere, ma sono quelle che, nella nostra esperienza, producono i risultati più stabili nel tempo.

La prima è trattare Odoo come headless ERP. Per i portali esterni, il pattern che preferiamo è disaccoppiare completamente il frontend dall'ERP. I dati vivono in Odoo, ma l'interfaccia utente è costruita con tecnologie adatte a quel contesto (React, Next.js o altri stack moderni) e comunica con Odoo esclusivamente via API.

La seconda è preferire un'architettura event-driven al polling. Nelle integrazioni fatte in fretta il microservizio interroga Odoo a intervalli regolari per sapere se è cambiato qualcosa: carico inutile quasi sempre, e latenza proprio quando qualcosa cambia davvero. L'alternativa è far partire la notifica da Odoo. Quando succede qualcosa di rilevante, un ordine confermato o un pagamento registrato, un'azione automatizzata chiama l'endpoint dei servizi interessati. Sono loro a essere avvisati, invece di chiedere.

La terza è la containerizzazione con Docker e l'orchestrazione con Kubernetes. Non è una scelta estetica. Permette di allocare risorse in modo dinamico, di scalare i singoli servizi in base al carico effettivo e di gestire i rilasci senza downtime. In un sistema dove ogni componente ha un ciclo di vita separato, l'orchestrazione è ciò che mantiene tutto coerente.

Un caso concreto: la piattaforma GAIA per la Croce Rossa Italiana

La descrizione astratta ha un limite: non rende evidente il motivo per cui queste scelte contano. Il progetto GAIA, sviluppato per la Croce Rossa Italiana, illustra bene i vincoli reali.

Il contesto: un sistema per la gestione di operatori, turni, anagrafiche e logistica operativa, usato in situazioni dove i picchi di accesso sono imprevedibili e spesso coincidono con momenti di emergenza. I requisiti di disponibilità e sicurezza dei dati non ammettevano margini.

Un'architettura monolitica avrebbe significato dimensionare l'intera infrastruttura per il caso peggiore, con tutto ciò che ne consegue in termini di costi e rigidità. L'alternativa che abbiamo implementato mantiene Odoo come back-office solido (gestione delle anagrafiche, dei turni, delle logiche operative) e affianca un layer a microservizi orchestrato con Kubernetes che gestisce i componenti esposti a traffico variabile.

Il risultato: i componenti sotto stress durante i picchi scalano senza impattare la stabilità del gestionale. I rilasci di nuove funzionalità sui portali esterni avvengono in modo separato. Il database centrale di Odoo rimane il punto di coerenza dei dati, protetto da tutto il carico applicativo.

La questione della migrazione

C'è un argomento spesso sottovalutato nelle conversazioni sull'architettura Odoo: le migrazioni tra versioni major.

Un ERP con anni di personalizzazioni cablate a mano, con logiche esterne innestate nell'ORM e moduli custom che toccano il core si migra male. Non è impossibile, è lento e costoso. Ogni nuova versione di Odoo richiede di riscrivere o adattare tutto ciò che si è accumulato nel tempo.

Mantenere il core pulito e delegare le complessità verticali a microservizi esterni ha un effetto diretto su questo: la migrazione riguarda Odoo, non l'intero ecosistema. I microservizi continuano a funzionare mentre l'ERP viene aggiornato. Il contratto API viene verificato e adattato dove necessario, ma non si ricostruisce l'intera architettura.

È uno degli argomenti pratici più forti a favore di questa separazione, spesso più persuasivo delle considerazioni teoriche sulla scalabilità.

 

Quando ha senso, quando non ce l'ha

Un'architettura a microservizi porta complessità operativa reale: più componenti da monitorare, più contratti API da mantenere, più infrastruttura da gestire. Non è la risposta giusta per tutti, e sarebbe disonesto presentarla come tale.

Ha senso quando ci sono domini con requisiti di scalabilità o disponibilità disomogenei rispetto al core ERP. Ha senso quando team diversi lavorano su componenti diversi con cicli di rilascio separati, o quando l'ERP deve integrarsi con sistemi eterogenei che evolvono nel tempo.

Non ha senso quando l'azienda ha un perimetro applicativo limitato e stabile. Non ha senso quando il team è piccolo e la complessità operativa supera i benefici, o quando le integrazioni sono puntuali e non richiedono scalabilità indipendente.

Il nostro compito, come partner, è proporre il livello architetturale proporzionato al fabbisogno reale, non la soluzione più sofisticata in assoluto.

Dove finisce Odoo e dove inizia il resto

Non è una domanda sul numero di servizi da costruire. È la domanda che decide i costi di sviluppo, quanto costerà la prossima migrazione e quanto potrai far evolvere un pezzo senza mettere le mani sul gestionale. Chi la rimanda, di solito la paga più avanti, con gli interessi.

Stai valutando come strutturare l'infrastruttura Odoo per supportare la crescita della tua azienda? 


Prenota una call.
Parlerai con un nostro consulente per capire quali sono le tue esigenze specifiche.