Sono quattro i principi chiave dello sviluppo software, in un’infrastruttura agile e integration-based, che possono essere applicati anche alla strategia di integrazione

Il ciclo di vita di un’infrastruttura è molto diverso dal ciclo di vita dello sviluppo software o delle operations. Il ciclo di sviluppo prevede il completamento di un progetto per poi passare a quello successivo – ed incrementarne l’efficienza significa accelerare il tempo di rilascio di un prodotto o aumentare il numero di caratteristiche che possono essere create in un determinato tempo. Anche dal punto di vista delle operations, per loro natura più legate alla manutenzione e alla stabilità, rappresenta comunque un vantaggio il fatto di poter applicare aggiornamenti e patch di sicurezza, implementare nuovi servizi o effettuare il rollback delle modifiche in modo più rapido ed efficiente.

L’infrastruttura però ha un approccio molto differente. Su di essa si tende a operare con tempi più lunghi e da parte di team più differenziati e altamente specializzati, cosa ben differente dai team cross-funzionali che operano su uno specifico progetto di ingegnerizzazione software. I progetti di infrastruttura sono tipicamente molto più estesi rispetto ai progetti software, il che significa che cicli di rilascio più brevi possono impedire il raggiungimento completo degli obiettivi. L’infrastruttura è per sua natura permanente. Ma è possibile riconciliare tra loro le metodologie con le prestazioni di un’infrastruttura, seguendo alcuni principi comuni all’Agile Manifesto dello sviluppo software

Questi quattro principi chiave dello sviluppo software, in un’infrastruttura agile e integration-based, possono essere applicati anche alla strategia di integrazione:

  1. Individui e interazioni, piuttosto che processi e strumenti

Con l’infrastruttura, il dibattito si concentra sulle interazioni che avvengono tra i team, interazioni che comprendono la comunicazione diretta, governata dalle API, la messaggistica e gli schemi di traffico, le interdipendenze a livello di sistema, e i processi di test and release, come le pipeline CI/CD.

  1. Software funzionale, piuttosto che documentazione estesa

Per sua natura, l’infrastruttura deve essere funzionale 24/7/365, con una capacità graduale di adattamento piuttosto che di cambiamento drastico. In questo senso, un’infrastruttura operativa e funzionale è sempre un requisito implicito. Dal punto di vista della strategia infrastrutturale, “operativa e funzionale” significa che le differenti componenti dell’infrastruttura offrono il comportamento atteso dall’utente finale in uno scenario prestazionale prevedibile e consueto.

  1. Collaborazione col cliente, piuttosto che negoziazione di contratti

Assieme ai sistemi infrastrutturali, i contratti rappresentano il modo in cui i team responsabili dell’infrastruttura gestiscono le dipendenze tra i sistemi, come ad esempio le policy di sicurezza, i service-level agreement e persino le API pubblicate. I clienti comprendono gli utenti di questi sistemi, interni ed esterni. L’agilità offre a questi clienti una voce relativamente ai potenziali cambiamenti delle policy e delle interfacce associate ai sistemi e permette loro di vedere questi cambiamenti eseguiti in modo più veloce. Utilizzare integrazioni distribuite estende questa collaborazione, dando direttamente ai team la possibilità di sviluppare e implementare le integrazioni.

  1. Rispondere al cambiamento, piuttosto che seguire un piano

In questo principio, la tecnologia supporta un processo. In ottica di infrastruttura, i sistemi dovrebbero rimanere stabili, ma le tecnologie più moderne come i container, offrono una piattaforma elastica. Sulla base della richiesta, è possibile aggiungere e rimuovere istanze in modo dinamico, per automatizzare implementazioni e aggiornamenti, e per orchestrare modifiche tra più istanze differenti. Le definizioni di API pubblicate offrono strumenti riutilizzabili per aiutare lo sviluppo ad essere più consistente. Questo approccio permette di avere una piattaforma stabile, pensata per adattarsi al cambiamento.

Una vera agile integration utilizza la tecnologia a supporto dei cambiamenti culturali all’interno dei team che seguono l’infrastruttura. Rappresenta la base per una strategia infrastrutturale, e permette di allineare in modo più stretto le tecnologie di integrazione, e i relativi team, con le strategie di business e sviluppo.

La metodologia agile identifica alcune parti fondamentali di un progetto software, quali individui, versioni e dipendenze. Può successivamente definire le relazioni tra questi elementi. Se si approccia l’infrastruttura di integrazione allo stesso modo, ci sono elementi e relazioni simili che possono essere identificati, in parallelo con quanto fatto per lo sviluppo – come team, immagini di container, API e integrazione.

Vittorio Colabella, Middleware Sales Leader Italy, Red Hat