Metodologia 12 Factor App: Sviluppo Saas

I 12 fattori o principi:

1. Codebase – Una sola codebase sotto controllo di versione, tanti deploy

Il primo principio afferma che tutti gli asset legati ad un’applicazione, dal codice sorgente alle impostazioni di configurazione, devono essere depositati in una code repository che sia accessibile a chi sviluppa, a chi è dedicato al test e ai sistemisti. La code repository deve anche essere accessibile agli script di automazione dei processi di CI/CD (Continuous Integration/Continuous Delivery) che fanno parte del Software development lifecycle (SDLC)

> Leggi anche: “Secure SDLC: Integrazione della Sicurezza nel Ciclo di Sviluppo del Software”

2. Dipendenze – Dipendenze dichiarate e isolate

Il principio delle Dipendenze dichiara che solo il codice che è unico e rilevante allo scopo dello sviluppo dell’applicazione deve essere depositato. Packaging esterni come file .jar o DLL devono essere tutte dichiarate tramite un manifest dedicato. Viene contemplato anche l’uso di uno strumento di isolamento delle dipendenze durante l’esecuzione, in modo tale da assicurarsi che non ci siano delle “dipendenze implicite” che creino interferenze nel sistema di riferimento.

3. Configurazione – Memorizza le informazioni di configurazione nell’ambiente

Il terzo principio stabilisce che le informazioni di configurazione devono essere memorizzate in variabili d’ambiente (env vars o env). La configurazione di un’applicazione è tutto quello che può variare da un deployment all’altro: impostazioni come il numero di porta, le dipendenze sugli URLs e le impostazioni di stato, come il DEBUG, devono esistere separatamente ed essere applicate esclusivamente in fase di deployment. Il vantaggio di questo principio è proprio quello di poter utilizzare e gestire in modo indipendente le diverse impostazioni di configurazione rispetto al path di deployment: si potrebbe avere, ad esempio, un set di impostazioni di configurazione per l’ambiente di staging, uno per la produzione e uno per l’ambiente di sviluppo.

4. Backing Service – Tratta i backing service come risorse

Un backing service è un qualsiasi servizio a cui l’applicazione accede attraverso la rete durante la sua esecuzione, come ad esempio database, servizi SMTP per la posta, sistemi di cache ecc.

Il principio backing services incoraggia a trattare risorse esterne, siano esse locali o di terze parti, come risorsa connessa. Trattare le risorse come backing service promuove la flessibilità e l’efficienza nel ciclo di vita di sviluppo del software ed evidenzia la separazione dal deployment di riferimento.

5. Build, release, esecuzione – Separare in modo netto lo stato di build dall’esecuzione

Il principio build – release – esecuzione, divide il processo di deployment in 3 step replicabili che possono essere istanziati in ogni momento. La fase di Build converte il codice del repo in una build “eseguibile”. Le impostazioni vengono applicate nella fase di release. Poi, nella fase di esecuzione (o runtime) si vede l’applicazione in esecuzione nell’ambiente di destinazione, attraverso l’avvio di processi della release scelta. Il vantaggio di questo principio è proprio la separazione netta dei 3 stati: è impossibile, ad esempio, effettuare dei cambiamenti del codice in fase di esecuzione, dato che non c’è modo di propagare queste modifiche all’“indietro”, verso la fase di build.

6. Processi – Esegui l’applicazione come uno o più processi stateless

Il principio dei Processi afferma che ogni applicazione sviluppata con la metodologia 12 Factor App sarà eseguita come una serie di processi stateless. Questo significa che nessun processo singolo tiene traccia dello stato di un altro processo e che nessun processo tiene traccia di informazioni di sessione o stato del workflow. Tutti i dati che devono persistere saranno memorizzati in un backing service, come ad esempio un database. Un processo stateless rende la scalabilità più facilmente raggiungibile.

7. Binding delle Porte – esporta i servizi tramite binding delle porte

Questo principio dichiara che un servizio o applicazione è identificabile sulla rete dal numero di porta e non dal nome dominio. L’argomentazione a supporto è che il nome dominio e l’indirizzo IP ad esso associato, possono essere assegnati sul momento in modo manuale oppure in modo automatico: viene quindi considerato inaffidabile utilizzarli come punto di riferimento. Al contrario, l’esposizione di un servizio o di un’applicazione sulla rete tramite numero di porta è più affidabile e più facile da gestire.

L’idea principale che sta dietro al principio di binding delle porte è che uniformare l’utilizzo del numero di porta è il miglior modo di esporre un processo sulla rete: ad esempio la porta 80 è convenzionalmente legata all’HTTP, 443 è il numero di porta di default dei protocolli HTTPS, 22 per gli SSH, la porta 306 è quella di default per MySQL e così via.

8. Parallelismo – Scalare attraverso il modello di processo

Il principio di parallelismo si raccomanda l’organizzazione dei processi rispetto al loro scopo e la separazione di questo processo in modo che possano essere scalati in modo indipendente e al bisogno. Il modello di processo così come presentato rende il massimo quando arriva il momento di scalare. La natura orizzontalmente partizionabile (e non soggetta a condivisioni) di un processo twelve-factor permette di gestire il parallelismo in modo semplice e affidabile.

9. Disposability – Massimizzare la robustezza con avvii veloci e shutdown graduali

Il principio di disposability afferma che i processi di un’applicazione twelve-factor possono essere avviati o fermati senza problemi al momento del bisogno. Questo significa che tutto il setup necessario deve essere completato prima di rendere l’applicazione disponibile allo user finale. Questo principio facilita le procedure di scaling, deploy rapido della codebase o cambi dei file di configurazione e minimizza i tempi di avvio.

10. Parità tra Sviluppo e Produzione – Mantieni lo sviluppo, staging e produzione il più simili possibile

Un’applicazione twelve-factor è progettata per il rilascio continuo: in questo modo tiene le differenze di deployment al minimo. Il principio si assicura che sia implementato lo stesso processo di deployment sia per la produzione che per lo Sviluppo.

11. Log – Tratta i log come stream di eventi

Questo principio tratta dell’invio di dati di log in uno stream accessibile ad una serie di consumer interessati. Il processo di instradamento dei dati log deve essere separato dall’elaborazione dei dati di log stessi. Ad esempio: un consumer potrebbe solo essere interessato ai dati errore, mentre un altro solo ai log degli eventi di archiviazione.

12. Processi di Amministrazione – esegui i task di amministrazione come processi una tantum

Questo principio indica che i processi di amministrazione sono first-class citizens nel SDLC (Software Development Lifecycle) e devono essere trattai come tali. I processi di amministrazione dovrebbero essere avviati in un ambiente con le stesse caratteristiche di quello su cui lavorano gli altri processi e dovrebbero essere eseguiti su una specifica release.

I principi della metodologia 12 Factor app sono progettati per permettere a sviluppatori e DevOps di creare applicazioni eseguibili su web-scale. Inizialmente possono sembrare insormontabili e per tanti aspetti, lo sono: dover ripensare dal principio a come si progettano software, può essere scoraggiante. Fortunatamente, l’implementazione dei principi 12 Factor App non è una questione “tutto o niente”: la metodologia permette l’applicazione parziale o di singoli principi. Molte aziende hanno tratto benefici dalla metodologia twelve factor app: il trucco è impegnarsi a seguirli tutto e poi fare il primo passo.