Coding & Programming Archives

Il Saas (Software-as-a-service) ha visto, negli ultimi vent’anni, una crescita esponenziale, grazie soprattutto alle caratteristiche vantaggiose che presenta, come ad esempio le condizioni di flessibilità, scalabilità e facilità di implementazione e configurazione rapida. Questo scenario di sviluppo sempre più frequente ha però sollevato in particolare una domanda. Quale metodologia usiamo per lo sviluppo? Abbiamo illustrato in precedenza framework di sviluppo del software Agili, quali ad esempio Scrum, ma in questo articolo ci dedichiamo ad una metodologia pensata soprattutto per sviluppatori e DevOps che si chiama “12 Factor App”. Iniziamo con una definizione del contesto di sviluppo: il Saas è un modello di distribuzione del software nel quale l’hosting delle applicazioni è eseguito da un rivenditore o fornitore di servizi e reso disponibile per i clienti sulla rete. La metodologia Twelve Factor App si orienta in modo specifico a questa tipologia di applicazioni, con l’obiettivo di ridurre tempi e costi di sviluppo, garantire la piena compatibilità esternamente su varie piattaforme e internamente con le versioni precedenti, creare sistemi leggeri e scalabili con un utilizzo ridotto di risorse. 12 factor App: introduzione Presentata per la prima volta nel 2011 da Adam Wiggins, la metodologia Twelve Factor App è stata progettata dagli sviluppatori per gli sviluppatori. Si tratta infatti di una serie di best practices che hanno come obiettivo finale la progettazione di Saas che: Minimizzano tempi e costi di ingresso per ogni sviluppatore che si aggiunge al progetto; Offrono la massima portabilità sui vari ambienti di esecuzione; Sono adatte allo sviluppo sulle più recenti piattaforme cloud; Permettono il continuous deployment; Scalano in modo significativo. I 12 fattori o principi: 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) 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Fonti: Reselman, B., 2021. An illustrated guide to 12 Factor Apps. redhat.com. Disponibile su: https://www.redhat.com/architect/12-factor-app . Wiggins, A., 2021. The Twelve-Factor App. 12factor.net. Disponibile su: https://12factor.net/ .

Metodologia 12 Factor App: Sviluppo Saas

Come diventare Full Stack Developer

Coding: skill e strumenti per imparare

KINETIKON s.r.l.

Dove trovarci

Iscriviti alla newsletter

Informative

Compila il form per guardare il webinar

Introduzione alla Blockchain

Compila il form per guardare il webinar

Collaboration Tools

Compila il form per guardare il webinar

Social Network: l’analisi dei rischi per le aziende

Social Network: l’analisi dei rischi per le aziende – Parte I

Compila il form per guardare il webinar

The True Power of the SEP Sesam Datastore

Compila il form per guardare il webinar

Cyber Security nell’Automazione Industriale

Compila il form per guardare il webinar

Applicazioni pratiche della ISO 27000

Compila il form per guardare il webinar!

Qlik Sense: un’introduzione

Compila il form per guardare il webinar

Aggregare, analizzare, visualizzare dati con Elasticsearch

Compila il form per guardare il webinar

Power BI Essential

Compila il form per guardare il webinar

Oracle Advanced Analytics

Compila il form per guardare il webinar

Principi e Pratiche DevOps

Compila il form per guardare il webinar

ITIL® Made Simple

Compila il form per guardare il webinar

Agile & Scrum: le origini

Compila il form per guardare il webinar

Prince2 Agile: compromesso o complemento?

Archivio per categoria: Coding & Programming

KINETIKON s.r.l.

Dove trovarci

Iscriviti alla newsletter

Informative