Ingegneria della piattaforma e DevOps

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. 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.

Scopri Red Hat OpenShift per l'ingegneria della piattaforma

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.

In un 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.

L'importanza dell'ingegneria della piattaforma. 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.

DevOps e ingegneria della piattaforma sono due approcci distinti ma complementari all'ottimizzazione dello sviluppo e del deployment del software. Entrambi puntano a velocizzare i rilasci e a mantenere la stabilità del sistema, ma differiscono in modo significativo nella loro applicazione pratica. DevOps è collaborativo dal punto di vista culturale e metodologico. L'ingegneria della piattaforma opera invece come approccio orientato al prodotto, creando gli strumenti di base che favoriscono la scalabilità di tale cultura nell'intera organizzazione.

In questo ecosistema, un ingegnere DevOps si occupa di colmare il tradizionale divario che esiste tra i team di sviluppo e le operazioni IT. La sua principale responsabilità consiste nell'automazione dei processi di creazione, test e deployment attraverso la progettazione e la gestione delle pipeline CI/CD. Per garantire la coerenza tra i vari ambienti, fa ampio uso dell'Infrastructure as Code per automatizzare il provisioning dell'infrastruttura e delle piattaforme, evitando la configurazione manuale dei server. Questo ruolo richiede una mentalità orientata al miglioramento continuo, e l'analisi costante delle pipeline di deployment per individuare eventuali ostacoli. Inoltre, spesso gli ingegneri DevOps collaborano a stretto contatto con un ingegnere SRE per bilanciare il ritmo rapido del rilascio delle funzionalità con i rigorosi obiettivi di uptime e affidabilità del sistema.

Un ingegnere della piattaforma affronta l'infrastruttura con un'ottica orientata al prodotto e con l'obiettivo di ridurre il carico cognitivo che grava sugli sviluppatori di software e che va di pari passo con la sempre maggiore complessità degli ambienti cloud. Le principali responsabilità di un ingegnere della piattaforma sono la creazione e la manutenzione di una piattaforma di sviluppo interna (IDP), ovvero un portale self service in cui gli sviluppatori possono eseguire in autonomia il provisioning di ambienti, database e pipeline. In questo modo, standardizza i controlli di accesso al sistema e la conformità della sicurezza nei modelli della piattaforma. Gli ingegneri della piattaforma trasformano i modelli di alto livello in golden path riutilizzabili che astraggono le complessità delle reti cloud e dell'orchestrazione dei container, consentendo agli sviluppatori di concentrarsi esclusivamente sulla scrittura del codice applicativo.

Negli ambienti aziendali, la sicurezza e la conformità devono essere direttamente integrate nelle procedure di deployment quotidiane. Sebbene i modelli DevOps tradizionali diano grande rilievo alla filosofia dello "shift left", che affronta la gestione della sicurezza tramite test automatizzati e integrazione continua nella fase di sviluppo, questo approccio può aumentare notevolmente il carico cognitivo degli sviluppatori. Per alleviare tale carico, l'ingegneria della piattaforma è in grado di progettare piattaforme conformi e sicure fin dall'inizio. 

Integrando le policy di sicurezza e conformità negli strumenti di automazione e nelle pipeline CI/CD standardizzate, l'ingegneria della piattaforma riduce la complessità normativa. Questo approccio permette agli sviluppatori di operare su un'infrastruttura sicura e scalabile senza dover essere esperti di conformità.

L'integrazione di una solida gestione del rischio su tutte le piattaforme cloud richiede inoltre un approccio unificato all'IaC e alla containerizzazione. I team DevOps si avvalgono di queste metodologie per accelerare la distribuzione del software, mentre gli ingegneri della piattaforma gestiscono i sistemi alla base, supportati dalla governance. La collaborazione garantisce l'immediata individuazione di qualsiasi deviazione dai requisiti aziendali. Affidando la responsabilità della creazione di sistemi scalabili e sicuri a una strategia che preveda una piattaforma centralizzata, le organizzazioni possono accelerare la velocità di rilascio, mantenendo al contempo una postura ineccepibile contro i rischi normativi e operativi.

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.

Scopri le novità di Red Hat OpenShift