DevOps and Outsourcing: OutOps [pt.3]

Terzo e ultimo appuntamento di DevOps e Outsourcing, in cui vedremo le rimanenti strategie e tireremo un po' le somme del discorso.

OutOps Strategy, Infrastructure Resilience

L’ Infrastructure Resilience (Resilienza ai cambiamenti Infrastrutturali) è la capacità del software di adattarsi ai cambiamenti evolutivi e alle condizioni inattese dell’infrastruttura a supporto, composta dall’hardware e dal software di base.

resili

In generale, una soluzione robusta deve essere tollerante ai cambiamenti dell’hardware e del software di base: si pensi, ad esempio, all’utilizzo di container per il suo dispiegamento.

In questo ambito è fondamentale avere strumenti automatizzati di verifica che consentono al committente di validare il corretto utilizzo dell’infrastrutture da parte della soluzione realizzata.

Questo approccio conferisce al delivery/deploy automatizzato una maggiore robustezza: si pensi ad esempio ad una nuova release del software che si scontra con il fatto che l’RDBMS è stato aggiornato. Se le verifiche vanno a buon fine è possibile essere confidenti che l’evoluzione infrastrutturale non ha prodotto side effect sull’applicazione e procedere con il relativo delivery. L’alternativa sarebbe un approccio “deploy & pray”, ovvero “io speriamo che me la cavo”.

Compito del Committente: Definire e gestire gli end-point di supporto alle soluzioni unitamente al provisioning automatizzato delle risorse annesse. Inoltre, è di primaria importanza l’individuazione o la realizzazione di tool che consentano di verificare lo stato di erogazione del servizio e rispondere autonomamente alle situazioni inattese più comuni.

Benefici Evidenti: garantire una buona resilienza consente di supportare adeguatamente l’evoluzione dell’infrastruttura a supporto, riducendo il rischio di blocco dei servizi e quindi un’operatività dell’azione di business.

OutOps Strategy, Intentional Architecture

Ogni software ha un’Architettura, sia essa specificamente definita o de-facto.

intentional architect

Quello che però deve essere evidente è il fatto che, a livello di “piattaforma” (formata dalle diverse soluzioni, realizzate eventualmente in outsourcing da uno o più fornitori) delle soluzioni erogate, non è possibile immaginare che ognuna di essa abbia una struttura che non tenga conto delle scelte d’insieme e, in particolare, non sposi architetture software moderne, andando a minare l’efficienza complessiva di una pipeline di Continuous Delivery.

Come esempio, si immagini lo scenario in cui la soluzione è monolitica e si debbano eseguire i test di regressione: per testare le modifiche relative ad una singola feature è necessario ricompilare tutto il sorgente e rieseguire tutti i test, perdendo ore e rendendo impossibile, nel concreto, attuare la pratica di Continuous delivery/deploy. Un’architettura in chiave “servizi” (nelle diverse declinazioni tecnologiche), consente di rendere il tutto estremamente più efficiente, concentrando le azioni di verifica e misurazione esclusivamente sul nuovo componente o su quello che è stato modificato.

Una soluzione efficace al problema è quella che vede il committente impegnato a definire una “Intentional Architecture” (Architettura Intenzionale), ovvero una architettura di riferimento che guidi le azioni progettuali del fornitore senza imbrigliarlo in scelte eccessivamente di dettaglio: ad esempio, si impone che l’architettura sia a Microservizi, ma al contempo al fornitore non viene imposto di utilizzare uno specifico design pattern perché si tratta di una scelta a livello di codifica (design applicativo), ininfluente a livello architetturale.

Compito del Committente: Definire l’Intentional Architecture e condividerla in modo chiaro con tutti i fornitori. Settare una serie di metriche che consentano, qualitativamente, di validare l’aderenza ad essa.

Benefici Evidenti: Con una Intentional Architecture si riduce fortemente il rischio di frammentazione della “piattaforma”, consentendo una gestione quanto più possibile omogena di essa. Inoltre, le architetture moderne abilitano all’utilizzo di molte delle pratiche alla base di DevOps.

OutOps Strategy, Security Validation

La Sicurezza (con la “S” maiuscola ad indicare la generalità e la necessità di declinarla rispetto allo specifico contesto) è un aspetto imprescindibile che deve essere alla base della realizzazione di ogni soluzione.

security 

Fondamentale è che le diverse applicazioni siano allineate alle necessità e ai vincoli individuati a livello enterprise al fine di non compromettere la sicurezza della “piattaforma” complessiva dei servizi in erogazione.

Questo tipo di azione richiede la creazione di una serie di servizi che i fornitori debbono utilizzare per validare quanto realizzato già durante lo sviluppo: si pensi ai penetration test, così come agli strumenti di analisi statica della qualità del codice che si concentrano sulla ricerca di pattern potenzialmente attaccabili.

Finché tutte le verifiche non sono superate positivamente, la soluzione non può essere accettata e sarà onere del fornitore risolvere i diversi problemi riscontrati.

Compito del Committente: Definire in modo chiaro il concetto di “Sicurezza” e le relative policy a cui attenersi, rendendo disponibili una serie di strumenti che il fornitore può utilizzare per validare oggettivamente la relativa conformità.

Benefici Evidenti: La “piattaforma” dei servizi ha un livello di Sicurezza minimo garantito. Il committente è sicuro che, solo quando una soluzione supera le verifiche automatiche di sicurezza stabilite nella pipeline di delivery, potrà raggiungere effettivamente la produzione.

 

Conclusioni

Quanto descritto fin ora vuole essere un contributo, sulla base dell’esperienza personale e dell’osservazione diretta di diverse realtà aziendali, nel capire come poter applicare i principi DevOps in contesti fortemente caratterizzati da azioni di outsourcing.

Si tratta di casi numericamente consistenti, in cui diventa difficile trovare il modo di sposare le pratiche che stanno gradualmente trasformando lo sviluppo, di soluzioni IT, da un’azione artigianale ad una sempre più ingegneristica.

Bisogna però fare attenzione a non cadere nell’illusione che OutOps possa richiedere un impegno minore, dal punto di vista della trasformazione aziendale, di quello che possa richiede DevOps: questo perché l’onere di guidare il processo di trasformazione in relazione agli obiettivi di business non può essere esternalizzato, ma resta di competenza esclusiva dell’IT aziendale, essendo l’unico responsabile dell’allineamento con la vision strategica.

Fondamentale diventa, inoltre, il coinvolgimento di funzioni non tipicamente IT, come Legal o Provisioning, che devono formalizzare e gestire le relazioni con i fornitori esterni. Tematica particolarmente calda in questo ambito è quello dei Contratti Agili, pensati per instaurare una collaborazione win-win tra committente e fornitore che non si basi esclusivamente sugli elementi costo-tempo-funzionalità.

Infine, è utile ribadire che, quanto descritto, è un’indicazione di cosa ad oggi funziona nelle realtà che si sono impegnate in OutOps, e non va preso come una “ricetta” ma come un punto di partenza per capire come potersi muovere nel proprio contesto.

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme