Le aziende che utilizzano DevOps hanno un obiettivo concreto ed estremamente chiaro: aumentare la velocità con cui sono in grado di soddisfare le richieste di mercato, diminuendo costantemente il Time-to-Market.
Si tratta di un punto di vista completamente diverso dalle aziende che hanno un approccio tradizionale focalizzato sul raggiungimento di un nuovo stato: da A a B.
Fast vs A-to-B
La diminuzione del Time-to-Market è perseguibile con quanto ci stiamo raccontando nei vari post, e nei vari eventi pubblici, su DevOps, utilizzando approcci e tool in grado di accompagnarci nella nostra trasformazione Culturale.
Tutto questo però non può prescindere da un fattore fondamentale, di cui non abbiamo fatto ancora cenno: l’Architettura del nostro prodotto software.
Perché l’Architettura Software è così importante nell’applicazione concreta di DevOps? Molto più di quanto si pensi?
Ebbene, partiamo da alcune considerazioni fondamentali. La possibilità di rispondere adeguatamente ai cambiamenti, grazie alle pratiche di Continuous Integration, Continuous Delivery e Continuous Deployment, passa attraverso la capacità di poter modificare in modo puntale il nostro prodotto e attivare l’Agile Pipeline Deployment rapidamente per portare in produzione le modifiche e renderle così disponibili ai clienti.
Se la nostra applicazione è “monolitica” è facile rendersi conto che anche la più piccola delle modifiche rende il “last mile” estremamente corposo e lento da percorrere: test di integrazione, regressione, adattamento degli script, degli ambienti, delivery… tanta roba!
Se si riuscisse a scomporre il nostro prodotto in una serie di Servizi Atomici, indipendenti, che collaborano tra di loro tramite un set omogeneo di API e protocolli comuni, potremmo immaginare di utilizzare strumenti per pacchettizzate (containerize) le singole funzionalità e aggiornarle individualmente, abbattendo drasticamente il costo di attraversamento dell’ultimo miglio.
Ebbene, lo stile architetturale a Microservizi (microservices architecturale style) è, ad oggi, la soluzione più promettente in questo ambito:
Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services,which may be written in different programming languages and use different data storage technologies. [Fowler and Lewis]
A questo punto è doveroso fare una concisa overview sulla differenza tra SOA e Microservices che, comunque, dipende molto dalla propria interpretazione di SOA, tant’è che non è raro sentire esperti che affermano la sostanziale eguaglianza tra i due.
In realtà sarebbe corretto considerare SOA un (meta) pattern architetturale, essendo pensato per sostenere un'iniziativa strategica di cambiamento dell'IT, rendendo disponibili servizi cooperanti al fine di renderla più flessibile e dinamica. Si tratta di un’attività “invasiva” che coinvolge diverse (forse tutte le) applicazioni e diversi sistemi aziendali, unitamente a diverse strutture organizzative.
Tale iniziativa strategica è poi declinata tecnologicamente in stili architetturali specifici in cui incontriamo i Microservices che entrano nello specifico del design, prevedendo che i singoli moduli (Microservizi) siano utilizzabili in modo indipendente ed integrabili in modo efficiente per formare il quadro complessivo.
Il quadro si completa con i Nanoservices che, però, sono un evidente anti-pattern:
"A nanoservice is a service whose overhead, communications, maintenance and so on outweighs its utility." [Arnon Rotem-Gal-Oz, Author of SOA Patterns]
La strutturazione in Microservizi consente di sfruttare al massimo l’approccio DevOps perchè il focus è su singole unità funzionali, possibilmente pacchettizzate, che possono essere pubblicate sui vari stage di riferimento e raggiungere velocemente il deployment. Ricordiamo nuovamente che l’obiettivo di DevOps è quello di aumentare la velocità di deployment, andando a ridurre il gap tra il termine (presunto) delle attività di sviluppo e il momento in cui l’utente può utilizzare le nuove funzionalità.
Inoltre, questa granularità consente di scalare orizzontalmente, rendendo il processo annesso automatizzabile e testabile in modo relativamente agevole.
Monolithic vs Microservices scaling
Anche gli aspetti di governance sono agevolati: si pensi ai tool di Visual Management, come la Kanban Board. Ragionando in termini di singole “unità di lavoro” è possibile identificarli visivamente in singole card che aiutano a tenerne traccia lungo l’ultimo miglio ed intervenire per migliorare complessivamente l’intero processo.
Per approfondimenti sui microservices:
http://martinfowler.com/articles/microservices.html
