Una proposta olistica per le Internal Developer Platforms chiamata Platform Engineering ++

In questo articolo verrà esplorato il concetto di Platform Engineering, analizzandone le interpretazioni e implementazioni all’interno delle organizzazioni. L’obiettivo è rispondere alla domanda: “Le Internal Developer Platforms dovrebbero limitarsi alla fornitura self-service di infrastrutture e al deployment delle applicazioni?”

Le organizzazioni affrontano il Platform Engineering in modi differenti:

• Alcune sviluppano strumenti self-service per la gestione dell’infrastruttura, offrendo maggiore autonomia ai team di sviluppo.
• Altre si concentrano sull’esperienza degli sviluppatori, semplificando le fasi di coding e deployment.
• Alcune adottano un approccio centrato su marketplace, creando repository di componenti riutilizzabili come container, dati e API.

Sebbene le attuali pratiche di Platform Engineering affrontino con efficacia molti aspetti legati alla semplificazione delle attività, vi sono altre aree che richiedono maggiore attenzione. Ambiti come dati, machine learning, API, sicurezza e privacy risultano fondamentali per migliorare il ciclo di vita dei prodotti software. È necessario chiedersi se questi team possano trarre vantaggio dalle pratiche di Platform Engineering attualmente in uso.

Ampliando il focus oltre un singolo aspetto, si può garantire un’esperienza più completa e migliorata per tutti gli utenti.

Il Platform Engineering dovrebbe includere l’intera catena del valore end-to-end per offrire prodotti e applicazioni agli utenti finali in modo efficace. Spesso, viene associato esclusivamente alla semplificazione dell’infrastruttura e delle pratiche DevOps, con l’obiettivo primario di fornire una piattaforma self-service per gli sviluppatori. Tuttavia, mantenere questa visione limitata rischia di creare nuove barriere tra Platform Engineers e sviluppatori, simili a quelle che in passato dividevano i team IT Operations dagli sviluppatori. Inoltre, è indispensabile considerare anche ingegneri che si occupano di dati, ML, API e altre discipline.

L’espansione delle pratiche di Platform Engineering e dei relativi strumenti per abbracciare l’intero spettro delle applicazioni digitali può rappresentare un’evoluzione significativa, includendo aspetti non tradizionalmente associati a una piattaforma.

Ad esempio, possono essere considerati parte di una piattaforma:

• un Design System riutilizzabile da più team;
• un repository di librerie;
• un catalogo di metadati;
• accordi di lavoro tra team;
• un insieme di linee guida per garantire conformità legale e normativa;
• standard che le applicazioni devono rispettare.

Questa espansione potrebbe essere definita Platform Engineering ++. Gli elementi centrali includerebbero infrastruttura e DevOps, ai quali si aggiungerebbero Data/ML Engineering e la composabilità del software (API, eventi, micro frontend, librerie e tutti gli aspetti di un’applicazione software che possono essere riutilizzabili ed evoluti con un approccio Inner Source).

Questa proposta mira a offrire un approccio più completo ed efficace per lo sviluppo e la gestione delle applicazioni. Nei paragrafi successivi verranno fornite ulteriori motivazioni a supporto di questa visione.

Introduzione alle Piattaforme: una metafora

Come una biblioteca dove le persone portano libri da condividere e prendono in prestito libri da leggere, le piattaforme rappresentano uno spazio in cui condividere risorse. Nel mondo digitale, le piattaforme fungono da biblioteche virtuali, consentendo agli utenti di accedere e condividere una vasta gamma di risorse.

Una biblioteca può essere vista come una piattaforma in cui le risorse (Assets) vengono fornite sotto forma di libri, video, articoli e altro. La biblioteca offre funzionalità (Capabilities) come collezioni catalogate, sale lettura, caffetterie, e consente agli utenti di sfruttare queste funzionalità tramite un assistente di ricerca, un sito web o un servizio in abbonamento. I bibliotecari svolgono un ruolo fondamentale nel mantenere tutto organizzato e funzionante, offrendo un’esperienza self-service a un pubblico che può includere privati, scuole e altri gruppi.

Gli utenti della biblioteca non sono solo lettori, ma anche potenziali autori. Possono trarre ispirazione, raccogliere dati e formulare tesi basandosi sui materiali presenti in biblioteca, utilizzandoli per creare nuove opere.

Internal Developer Platforms

In questa analogia, i bibliotecari possono essere paragonati ai Platform Engineers. Il loro obiettivo principale è garantire che gli utenti della piattaforma ricevano servizi di alta qualità e vivano un’esperienza soddisfacente durante l’interazione con essa. Nella metafora, i libri rappresentano risorse e strumenti, come:

• Un cluster Kubernetes completo di software e configurazioni necessarie.
• Una CRD di Crossplane per creare una risorsa infrastrutturale.
• Un topic Kafka per lo streaming di dati.
• Un prodotto di dati disponibile per il consumo.
• Una libreria software per la registrazione dei log nel formato corretto, inclusa la traceId.
• Una libreria di componenti web per la composizione in un micro frontend.
• Un’API per avviare pagamenti tramite un provider di pagamento digitale.
• Un’applicazione completa accessibile agli utenti finali.

Le strutture di una biblioteca possono essere paragonate, ad esempio, a:

• Un catalogo di servizi che elenca tutte le risorse consumabili e componibili.
• Un’interfaccia self-service per creare nuovi elementi software (infrastruttura, applicazioni o altro).
• Un’interfaccia a riga di comando per visualizzare log in tempo reale in produzione.
• Un sistema di monitoraggio per visualizzare metriche di microservizi.
• Un insieme di scorecard per raccogliere informazioni sulle metriche dei team.

La biblioteca, che può essere definita come Internal Platform (o Internal Developer Platform, come verrà approfondito nel prossimo paragrafo), è il luogo virtuale in cui avviene tutta la magia tecnologica. I Platform Engineers gestiscono questa piattaforma, garantendo un’esperienza eccezionale agli utenti interni. La loro visione è orientata al prodotto, con un focus su un’esperienza utente fluida e intuitiva.

A seconda dei modelli di utilizzo degli utenti della piattaforma e delle specifiche esigenze organizzative, i Platform Engineers perfezionano la piattaforma per fornire i servizi necessari.

Una piattaforma può essere considerata un luogo virtuale in cui le risorse, che in questa analisi vengono anche definite Items, sono organizzate e distribuite in modo sistematico. Ottimizzando il tempo e le risorse, diventa possibile rendere accessibili un maggior numero di elementi.

Sfruttando efficacemente questi elementi (nella metafora, i libri), le organizzazioni possono creare soluzioni innovative, ottimizzare le operazioni e ottenere un vantaggio competitivo.

All’interno delle capacità offerte dalla Internal Platform, i fornitori di funzionalità (Capability Providers) mettono a disposizione una gamma di risorse fondamentali (Items), come infrastrutture, toolchain DevOps, servizi SaaS e strumenti. Questi elementi sono organizzati e costantemente gestiti dai Platform Engineers.

Ogni capacità rappresenta un Item della piattaforma e si caratterizza per:

• Definizione: descrive input, output, comportamenti configurabili, metriche e documentazione.
• Ciclo di vita: un Item attraversa un ciclo che include sviluppo, testing, deployment, operatività e dismissione.
• Consumo e composizione: gli Items possono essere consumati e composti per creare applicazioni più complesse, trasformandosi a loro volta in altri Items pronti per essere riutilizzati.

I Product Teams possono interagire con questi Items attraverso interfacce utente, linee di comando e API. Agenti basati sull’intelligenza artificiale possono supportare i team semplificando l’utilizzo degli Items, che sono organizzati in cataloghi corredati della relativa documentazione.

Grazie a questa collaborazione, vengono create nuove applicazioni. Queste applicazioni possono successivamente essere trasformate in Raw Assets, risorse grezze riutilizzabili da altri team. Questo processo migliora l’esperienza degli sviluppatori all’interno dell’organizzazione (DevX).

Questo ciclo può essere visto come una sorta di economia circolare nello sviluppo software, dove le risorse vengono continuamente riutilizzate e riconvertite. Ciò conduce a un processo di sviluppo più efficiente e sostenibile, massimizzando il valore delle risorse disponibili e riducendo gli sprechi.

Ciclo di Vita degli Items della Piattaforma

Gli Items della piattaforma si presentano in diverse forme, ma condividono alcune caratteristiche comuni:

• Sono descritti da un file di testo semplice (esistono diversi formati emergenti e, in futuro, si auspica l’adozione di uno standard).
• Possono essere messi in relazione tra loro.
• Seguono un ciclo di vita che comprende creazione, distribuzione, esecuzione, gestione operativa e catalogazione, per essere consumati dai team di prodotto e applicazioni.

Gli utenti possono interagire con il sistema tramite un’interfaccia utente (UI), una riga di comando (CLI), un software che automatizza alcune operazioni o un agente AI basato su modelli linguistici di grandi dimensioni (LLM).

Immaginando di avere accesso a una piattaforma interna completa, contenente tutte le descrizioni dei comportamenti e delle relazioni necessarie per eseguire un’applicazione, quanto sarebbe vantaggioso disporre di un compagno AI?

Un assistente AI potrebbe semplificare notevolmente le attività, come trovare gli Items, configurarli, distribuirli e gestirli in produzione, il tutto tramite conversazioni intuitive. Un tale strumento potrebbe ottimizzare il flusso di lavoro e aumentare significativamente la produttività complessiva.

Questa idea può essere definita Conversational DevX e sarà l’argomento principale del prossimo articolo.

Internal Developer Platform, Platform of Platforms o Internal Platform?

Non è chiaro se sia più corretto definire una Internal Developer Platform come un insieme di piattaforme diverse o come una singola piattaforma. Questo argomento rimane aperto e si invitano al confronto e alla condivisione di idee.

I nomi sono importanti, ma in questo articolo si vuole mettere l’accento sul contenuto. Si auspica che, con il contributo del gruppo tag-app-delivery (link), si possa arrivare a una nomenclatura standard.

Come menzionato nell’introduzione, la Platform Engineering va oltre l’infrastruttura e non rappresenta un’evoluzione del DevOps, bensì un metodo per ridurre il carico cognitivo delle persone che creano, distribuiscono e gestiscono elementi software come applicazioni, dati, API e modelli di machine learning.

La tendenza osservata suggerisce che ogni tipo di elemento software abbia la propria piattaforma. Tuttavia, le esperienze utente tra queste piattaforme stanno diventando sempre più simili, il che lascia intravedere una possibile convergenza verso una singola piattaforma o una “platform of platforms”.

Un Item nella Internal Platform può appartenere a diverse categorie:

• Risorse di Infrastruttura: includono i componenti hardware e software sottostanti che supportano applicazioni e servizi, come server fisici, macchine virtuali, container, piattaforme cloud, archivi dati, database e runtime per machine learning.
• Risorse della Piattaforma DevOps o per Sviluppatori: strumenti per definire ed eseguire toolchain, oltre a strumenti per gestire e osservare workload, dati, API, eventi e modelli AI durante il runtime.
• Risorse di Dati, Eventi e API: i dati rappresentano un asset fondamentale per molte organizzazioni. Possono essere strutturati, non strutturati o semi-strutturati, provenire da diverse fonti, essere statici o in movimento, aggiornarsi tramite policy ed emettere eventi.
• Risorse di ML e AI: modelli di machine learning che possono essere definiti, addestrati, distribuiti e migliorati per fare previsioni e analisi.
• Risorse Componibili: elementi orchestrati o coreografati. A seconda del tipo di risorsa, si possono usare pattern differenti, come Sagas o la composizione di Micro Frontend. Gli Items Componibili sono strumenti che consentono di creare nuove combinazioni di risorse.
• Risorse DevX: considerate come un prodotto (marketplace interno e catalogo software). Ogni elemento della piattaforma può essere un asset prezioso per altri. Fornire un marketplace per questi elementi e gestirne il ciclo di vita (creazione, pubblicazione, curatela, consumo, revisione) è fondamentale per creare un’economia circolare del software.
• Risorse per la Collaborazione tra Team: i team lavorano insieme all’interno delle piattaforme utilizzando vari Items per facilitare la comunicazione e organizzare i flussi di lavoro. Questi includono strumenti come backlog, issue tracker e documentazione. La comprensione della piattaforma stessa è essenziale per una collaborazione efficace.

Questo approccio olistico consente non solo di ottimizzare lo sviluppo, ma anche di garantire che ogni elemento della piattaforma contribuisca al miglioramento complessivo dell’organizzazione.

Ampliamo il diagramma con diverse Piattaforme all’interno della Piattaforma Interna.

La Piattaforma Interna acquisisce “asset grezzi” come macchine virtuali (VM), cluster Kubernetes come servizio, e strumenti Platform as a Service per il runtime.
Gli strumenti DevOps sono essenziali per la gestione delle risorse e del ciclo di vita del codice, rappresentando un pilastro fondamentale insieme ai servizi di osservabilità, sicurezza e gestione delle identità. I data store come database NoSQL e SQL, flussi di dati e storage di oggetti sono ampiamente utilizzati nello sviluppo delle applicazioni.

Inoltre, i modelli LLM (Large Language Models) sono frequentemente utilizzati come servizio tramite API o integrati nel runtime per migliorare le applicazioni sviluppate dai team. Le applicazioni SaaS, come Salesforce, Dynamics 365 e SAP, fungono da hub centrali per varie informazioni su clienti e prodotti, giocando un ruolo cruciale nello sviluppo di applicazioni cloud-native.

Tutte le capacità sono gestite con un approccio Infrastructure as Code (IaC) e i manifesti IaC sono gestiti con il ciclo di vita: code, ship, run, operate e organizzazione della collaborazione tra team.

Lo stesso ciclo di vita delle risorse è condiviso tra diversi tipi di piattaforme: sviluppatori, infrastruttura, orchestrazione delle applicazioni (API, Eventi, Flussi), machine learning e dati. Tutte queste sono Piattaforme all’interno della Piattaforma Interna, che sono interconnesse e possono condividere risorse come un cluster di database o una politica di sicurezza.

I descrittori di questi articoli sono manifesti che possono essere raccolti nel concetto di Application as Code (AaC): con lo stesso approccio che descrive lo stato desiderato dell’infrastruttura, si descrive lo stato desiderato degli articoli di tutte le piattaforme che compongono l’applicazione cloud-native.

All’interno del Marketplace Interno sono definiti: il blueprint riutilizzabile per tutti gli articoli della piattaforma, il catalogo software che può essere riutilizzato e tutti gli altri articoli provenienti da ciascun team che possono essere utilizzati da altri team come blocchi di costruzione. Grazie a questo Marketplace, è possibile abilitare una strategia di Platform Composability.

La Piattaforma Interna offre diverse interfacce, tra cui un’interfaccia utente (UI) e un’interfaccia a riga di comando (CLI). Inoltre, gli utenti possono interagire con la piattaforma tramite API. L’AI funge da compagno. I manifesti IaC e AaC sono forniti come contesto al modello LLM e l’AI semplifica i compiti per gli utenti della piattaforma. Questi compiti includono la scoperta delle risorse, la risoluzione dei problemi con i microservizi e le risorse, e la creazione di nuove risorse.

Platform Engineering++ è una disciplina di ingegneria del software che si concentra sulle Piattaforme Interne con un approccio olistico.

Conclusioni

Adottando il paradigma del Platform Engineering++, si ritiene che il ritorno sugli investimenti (ROI) dell’iniziativa Platform Engineering crescerà significativamente. Questo avverrà perché la piattaforma diventa la base per le applicazioni aziendali, eliminando gli ostacoli tra i vari team. Di conseguenza, tutti i team avranno una visione unificata delle applicazioni end-to-end costruite su di essa.

Riferimenti

In questo blog, quando si parla di “Piattaforma”, si intende specificamente “Internal Developer Platform” o “Internal Platform”, in quanto queste piattaforme non sono esclusive per gli sviluppatori, ma comprendono anche ingegneri dei dati, machine learning, cloud e altre discipline. È importante distinguere queste Internal Platforms dalle Business Platforms, come Uber, Airbnb o Netflix. Le Internal Platforms supportano le organizzazioni nella costruzione e nell’operatività delle loro Business Platforms. Ad esempio, Spotify ha creato Backstage come un Internal Developer Portal e ha integrato strumenti aggiuntivi per sviluppare la sua Internal Platform per gestire la piattaforma dei consumatori di Spotify.

Si segnala che esistono già documenti che definiscono alcuni aspetti trattati in questo post:

• il CNCF Platform White Paper (link)
• il Platform Glossary (link)
• il Platform Engineering Maturity Model (link)
• l’iniziativa Platform of Platform (link).

Articolo scritto da Giulio Roggero.