Ingegneria della piattaforma e DevOps

Sia l'ingegneria della piattaforma che DevOps sono pratiche IT basate su metodologie di sviluppo agile. Entrambe sono finalizzate alla riduzione dei tempi di rilascio e alla semplificazione delle attività di sviluppo, ma vengono adottate per rispondere a problematiche diverse. Analizzare le differenze tra i due approcci consente di scegliere quello più indicato a supportare gli obiettivi aziendali. DevOps è un approccio allo sviluppo software che le organizzazioni adottano per coniugare le funzioni di sviluppo con quelle legate alle operazioni IT all'interno di flussi di lavoro iterativi. L'ingegneria della piattaforma si concentra invece sulla creazione di piattaforme e strumenti interni a supporto di tali flussi di lavoro. 

DevOps è una metodologia che offre strumenti e processi pensati per favorire l'unione sinergica di sviluppo e operazioni, incrementando così la collaborazione fra team tradizionalmente isolati gli uni dagli altri all'interno delle organizzazioni. DevOps si basa sui principi cardine dell'approccio agile, come autogestione dei team e iterazione rapida. I requisiti essenziali per un'adozione efficace di DevOps sono stretta collaborazione fra i team, interfunzionalità, ambienti uniformi e cultura aperta al cambiamento. Non è sufficiente apportare solo delle modifiche a livello dei processi, ma occorre trasformare l'approccio culturale nell'intera organizzazione.

L'approccio DevOps e quello agile sono nati in risposta ai tradizionali metodi di sviluppo del software a cascata, largamente criticati perché rallentavano l'innovazione e creavano ostacoli a livello dell'organizzazione. Un sistema a cascata prevede che si testino funzionalità, efficienza, standardizzazione e documentazione del nuovo codice prima di poterlo integrare in un'applicazione. Testare tali requisiti a priori può comportare però una lunga coda di processo che rende difficile l'esecuzione dei progetti secondo gli obiettivi, i tempi e il budget previsti, soprattutto quando i progetti sono poco chiari o in continuo cambiamento.

DevOps si basa invece su automazione e processi ciclici. In questo modo i team di sviluppo possono passare rapidamente in produzione e continuare poi a perfezionare il software durante la produzione. DevOps richiede una stretta comunicazione e collaborazione fra i team e pratiche che promuovano la condivisione della conoscenza. Con questa metodologia non è più necessario eseguire le modifiche a priori con tempi di rilascio più lenti, ma è possibile integrare e migliorare i prodotti in modalità iterativa. Le organizzazioni che implementano DevOps sono in grado di migliorare i software in modo sistematico nel corso del tempo. A differenza dei modelli di sviluppo tradizionali, DevOps permette di ottenere maggiore adattabilità attraverso la sperimentazione di nuovi approcci.

L'ingegneria della piattaforma amplia i vantaggi ottenuti con DevOps fornendo ai team di sviluppo strumenti, servizi e flussi di lavoro standardizzati che ottimizzano la creazione di nuove soluzioni software. Ingegneria della piattaforma è un termine relativamente recente che indica la pratica di organizzare servizi e risorse interni affinché i team di sviluppo possano creare soluzioni senza dover gestire direttamente gli elementi alla base. Gli ingegneri della piattaforma selezionano e aggiornano gli strumenti, i servizi e la documentazione necessari ai team di sviluppo in modo che ognuno all'interno dell'organizzazione IT possa ottenere più efficienza e beneficiare del supporto di processi automatizzati noti come golden path. L'evoluzione dell'ingegneria della piattaforma è strettamente legata alla diffusione delle pratiche DevOps poiché questo approccio fornisce i componenti a supporto dei flussi di lavoro di DevOps e ne agevola la scalabilità in ambienti aziendali.

Nel suo intervento al DevOpsDays London, Abby Bangser è ricorsa a una metafora culinaria per spiegare il rapporto fra ingegneria della piattaforma e DevOps. Se stiamo "preparando" un software (la cena) e abbiamo bisogno di uno strumento (la pentola) o di un ingrediente (il prezzemolo), possiamo farne richiesta ma non è detto che riceveremo esattamente quello di cui abbiamo bisogno. Chi si occupa del provisioning potrebbe infatti non mandarci precisamente l'ingrediente che avevamo in mente o potrebbe addirittura non trovare ciò che gli abbiamo chiesto. Adottando un modello DevOps si evitano tutti i fraintendimenti e le problematiche legati al provisioning esterno, resta però l'inconveniente che sono i team a doversi creare gli ingredienti e gli strumenti da soli. Per continuare l'analogia di Bangser: con un modello DevOps prima di preparare la cena dovremmo fabbricare la pentola e coltivare il prezzemolo; ma questo sarebbe molto complicato oltre che poco efficiente.

In questo modello self service, i team di sviluppo faticano a gestire tutte le tecnologie utili per le loro attività quotidiane. Dover analizzare tutti i diversi set di strumenti rischia di ostacolare l'efficienza e aumenta il carico cognitivo sui team. Anche l'onboarding si complica perché i nuovi assunti devono imparare a utilizzare molti strumenti e sistemi diversi, e i membri senior, responsabili di assisterli in questo percorso, non riescono a dedicarsi interamente ai loro compiti principali. La produttività ne risente. Lo scopo dell'ingegneria della piattaforma è supportare i flussi di lavoro DevOps, alleggerire la mole di lavoro e centralizzare le procedure consigliate e le esperienze self service in modo che il resto dell'organizzazione IT possa dedicarsi all'innovazione. 

Backstage with platform engineering. Durata del video: 2:31

Scopri di più sull'ingegneria della piattaforma

L'ingegneria della piattaforma è al servizio di DevOps, nel senso che aiuta i team a soddisfare di volta in volta le diverse esigenze dell'azienda, grazie a una maggiore scalabilità. Questo approccio aiuta a definire un set di strumenti, conoscenze, servizi e processi standardizzati che tutti team di sviluppo dell'organizzazione potranno utilizzare. Con piattaforme appositamente selezionate e aggiornate, i team di sviluppo possono creare, distribuire ed essere responsabili dei propri strumenti e componenti, mentre è il team addetto alla piattaforma che crea, distribuisce e si occupa dei componenti della piattaforma. In questo modo ciascun team può dedicarsi alle sue iniziative ed essere più produttivo. In sostanza, i team addetti alla piattaforma forniscono i componenti in modalità "as-a-Service" e i team DevOps non devono più creare nulla da zero.

Se sono i team addetti alla piattaforma a fornire i componenti ai team di sviluppo, viene spontaneo chiedersi se l'ingegneria della piattaforma non rischi di ricreare gli stessi problemi e le stesse dipendenze interne che l'approccio DevOps aveva cercato di risolvere. Se il team delle applicazioni deve attendere che il team addetto alla piattaforma gli fornisca strumenti e componenti, è possibile che si verifichino gli stessi rallentamenti nei processi, questo a livello teorico.

Nella pratica, invece, l'intervento efficace dei team addetti alla piattaforma contribuisce a ridurre la ridondanza, a razionalizzare l'utilizzo delle risorse e ottimizzare i tempi nell'intera organizzazione. Con questo approccio i diversi team di sviluppo possono servirsi della stessa piattaforma self service, anziché creare ognuno la propria ex novo e con le stesse funzionalità. Con questo metodo si assicura la coerenza nel tempo, anche qualora fosse un altro team a occuparsi del progetto. Inoltre, con questo modello è come se i team di sviluppo fossero i clienti dei team addetti alla piattaforma. Questi ultimi sono quindi incentivati a rispondere tempestivamente alle esigenze dei loro clienti interni, prima che decidano di adottare infrastrutture o meccanismi di deployment alternativi. La presenza di una piattaforma comune, aggiornata con procedure consigliate e soluzioni consolidate, assicura la massima condivisione della conoscenza.

Chi ha dimestichezza con il site reliability engineering (SRE) avrà sicuramente già sentito parlare anche di ingegneria della piattaforma. Site reliability engineering è un termine coniato da Google per descrivere i sistemi che eseguono i prodotti in maniera automatizzata e si pongono come alternativa ai sistemi tradizionali dove questi sono eseguiti manualmente dagli amministratori di sistema. I team che si occupano del site reliability engineering sviluppano processi e contenuti di automazione volti a garantire l'integrità e l'operatività continua dell'infrastruttura alla base. I team SRE e gli ingegneri della piattaforma hanno quindi obiettivi comuni, ma mentre i primi si occupano principalmente di prestazioni, affidabilità e scalabilità dei software, gli ingegneri della piattaforma si dedicano ai sistemi e all'esperienza di sviluppo.

Scopri di più sull'approccio di Red Hat al site reliability engineering

In genere i team utilizzano l'ingegneria della piattaforma per realizzare piattaforme di sviluppo interne (IDP), strumenti, servizi e documentazione, accessibili da un portale self service. Gli ingegneri della piattaforma possono progettare e fornire IDP basate sulle esigenze degli utenti e sulle procedure consigliate per poi perfezionarle in maniera iterativa grazie alla ricerca e ai test degli utenti. Gli ingegneri della piattaforma possono inoltre sviluppare IDP con capacità self service per gli sviluppatori e ridurre il carico cognitivo sui team.

Le organizzazioni che puntano a introdurre pratiche di integrazione e distribuzione continue (CI/CD) nel ciclo di vita dello sviluppo software devono adottare un approccio DevOps. CI/CD permette di automatizzare le attività di creazione e test del codice e riduce l'impatto di bug ed errori nel codice perché il ciclo di sviluppo e aggiornamento del software viene integrato continuamente. L'integrazione e l'automazione delle pipeline CI/CD nell'intero ciclo di vita dello sviluppo software garantiscono alle organizzazioni la visibilità necessaria per creare piattaforme moderne e accelerare la distribuzione delle applicazioni.

I prodotti e i servizi Red Hat si complementano per supportare la produttività degli sviluppatori e garantire la flessibilità necessaria a ottenere cicli e processi più efficienti, favorire l'approccio self service, accelerare l'onboarding e ridurre l'onere delle attività ripetitive.

Red Hat Developer Hub è un portale interno per sviluppatori basato su Backstage, un progetto della Cloud Native Computing Foundation (CNCF). Accorpa le tecnologie disponibili permettendo di sfruttarne appieno la complementarietà, favorisce l'adozione di strumenti e servizi self service e snellisce l'onboarding, il tutto per una maggiore efficienza. Con Red Hat Developer Hub, le organizzazioni hanno a disposizione un portale interno condiviso dove consolidare gli elementi dei processi di sviluppo e semplificare i flussi di lavoro per promuovere la collaborazione.

Adotta Red Hat Developer Hub in combinazione con Red Hat OpenShift®. Con questa piattaforma gli sviluppatori potranno utilizzare gli strumenti che preferiscono per le applicazioni cloud native, tradizionali e modernizzate in qualunque ambiente siano distribuite: on premise, nel cloud o all'edge.