Per Iniziare
Comincia dalle basi e scopri come utilizzare Mia-Platform a piccoli passi.
Comincia dalle basi e scopri come utilizzare Mia-Platform a piccoli passi.
Inizia ora
Diventa Partner certificato e scopri tutti i benefici del Partner Program.
Scopri il nostro programma
Sempre più aziende stanno adottando l’approccio Agile e il paradigma DevOps per accelerare e migliorare lo sviluppo dei propri software. Se, però, alcuni processi del ciclo di vita del software vengono semplificati e velocizzati, dall’altro sono necessari nuovi strumenti e tecnologie per poter mettere in pratica le metodologie DevOps come, ad esempio, task manager, pipeline automatizzate e sistemi di test. Tuttavia, all’aumentare del numero di tecnologie e strumenti utilizzati, nasce il rischio che gli sviluppatori, soprattutto quelli con meno conoscenza dello stack tecnologico aziendale e dei prodotti sviluppati, perdano molto tempo nella ricerca delle diverse risorse, oppure a sviluppare da zero artefatti già disponibili nel patrimonio software dell’azienda perché già creati da altri developer, o ad adattarsi ai limiti di flessibilità dell’infrastruttura e degli strumenti.
Il pericolo, quindi, è che strumenti che dovrebbero velocizzare il lavoro dei team di sviluppo, finiscano invece per rallentarlo. Per evitare questa eventualità è necessario operare un radicale cambio di prospettiva: bisogna abbandonare la visione che si concentra solo sull’infrastruttura, e mettere al centro di tutto il processo di sviluppo software l’esperienza degli sviluppatori, la cosiddetta Developer Experience (o DevX). Per rispondere a questa esigenza nasce il concetto di Internal Developer Portal (IDP, o Internal Developer Platform), ossia un portale unico che raccoglie tutti gli strumenti e le tecnologie disponibili e utilizzati all’interno dell’azienda; in questo modo, i team di sviluppo possono focalizzarsi sullo sviluppo di funzionalità legate al core‑business dell’azienda, invece di disperdere energie sviluppando da zero funzionalità già pronte o ricavabili da template e librerie già disponibili.
Prima di approfondire le caratteristiche di un Internal Developer Portal, evidenziamo ciò che lo distingue da un External Developer Portal (EDP). L’EDP è un portale che ha l’obiettivo di mettere a disposizione di persone esterne all’azienda tutto il materiale necessario (come, ad esempio, API e documentazione) affinché possano integrare correttamente i sistemi esterni con quelli dell’organizzazione. Solitamente, questo avviene attraverso l’esposizione delle API; per questo motivo, in diversi casi l’EDP coincide di fatto con un API Portal. Un IDP, invece, oltre ad avere una sezione dedicata alle API interne, ha anche l’obiettivo di semplificare lo sviluppo e favorire la condivisione e il riuso di componenti all’interno dell’azienda.
Una volta che tutti i componenti saranno standardizzati dal team responsabile dell’Internal Developer Portal, saranno a disposizione dei team di sviluppo, che dovranno solo integrarli nei loro progetti e configurarli secondo le loro necessità.
Un Internal Developer Portal migliora la visibilità, la tracciabilità e l’osservabilità dell’intero ciclo DevOps: dall’infrastruttura al monitoraggio, dal design alla documentazione, ogni fase beneficia di questo strumento. Per fornire il massimo supporto ai team di sviluppo un Internal Developer Portal dovrebbe contenere:
Grazie a questi elementi, l’Internal Developer Portal permette ai team di sviluppo di attingere in autonomia alla tecnologia a disposizione, migliora la governance IT perché i componenti riutilizzabili sono già stati testati e validati e favorisce la condivisione della conoscenza.
Un Internal Developer Portal permette di migliorare la produttività di tutti i team di sviluppo presenti all’interno dell’azienda, indipendentemente da come è organizzata. Se la tua azienda ha già adottato un approccio Agile, una metodologia di sviluppo DevOps, è organizzata in Feature Teams e mira a creare un proprio Digital Integration Hub, l’IDP è lo strumento che ti garantisce di sfruttarne al meglio tutte le potenzialità, oltre a migliorare la governance IT.
Premettendo che per garantire i massimi benefici un Internal Developer Portal deve evolvere continuamente insieme all’azienda, di seguito riportiamo i nostri suggerimenti per implementare un Internal Developer Portal che aiuti la tua organizzazione in ogni fase del ciclo di vita del software.
È risaputo che i team Ops e i team di sviluppo hanno aree di competenza ben separate e, ad eccezione di eventuali figure di DevOps che svolgono attività di entrambe le aree, ciascuno preferisce rimanere nel suo campo di appartenenza. Ne è la prova il fatto che solitamente nel momento in cui deve essere implementata una nuova infrastruttura è facile che la fase di creazione e gestione dei componenti, che richiede la collaborazione dei due team, faccia da collo di bottiglia e rallenti l’intero processo.
Un Internal Developer Portal fornisce ai team di sviluppo componenti già pronti e standardizzati: in questo modo, gli sviluppatori possono installare i cluster, gestire le variabili di ambiente e aggiornare l’infrastruttura in completa autonomia. Per quanto riguarda la sicurezza, gli audit dei log vanno centralizzati per tutta l’infrastruttura, e si dovrà avere un unico sistema di autenticazione e autorizzazione. Inoltre, è consigliabile anche automatizzare alcuni aspetti, tra cui:
Un Internal Developer Portal permette di ottenere anche un notevole risparmio di risorse e costi attraverso:
Nella fase di design dell’infrastruttura di un’applicazione cloud‑native è importante stabilire quali sono i componenti che si vogliono rendere riutilizzabili. Per favorire questa operazione, un Internal Developer Portal deve rendere autonomi i team di sviluppo sia in fase di configurazione, sia in fase di test, sia in fase di esposizione delle API e degli eventi. Inoltre, dopo che saranno stati definiti gli standard aziendali, gli sviluppatori potranno definire in piena autonomia:
Tutto questo può essere facilitato attraverso la costruzione di un Service Catalog interno che mette a disposizione servizi, API e codice sorgente già testati e pronti per essere riutilizzati.
In fase di deploy, i developer devono poter accedere agli ambienti di runtime in totale autonomia. L’idea è rendere i team di sviluppo quanto più indipendenti e liberarli dalla preoccupazione di dover gestire i cluster e l’infrastruttura, così che siano in grado di accedere all’ambiente di produzione e deployare senza aspettare la configurazione manuale da parte del reparto Ops. In questo modo i developer possono:
Tutto questo mantenendo la massima autonomia da altri team e garantendo la totale tracciabilità del contenuto di ogni deploy, da chi è stato eseguito e quando.
Centralizzando tutti gli strumenti e gli artefatti nell’Internal Developer Portal, è possibile creare una dashboard unica per avere sotto controllo lo stato di tutti i servizi. Inoltre, è possibile implementare automazioni che portano alla creazione di altre dashboard e allarmi, che sono cruciali soprattutto per garantire il perfetto funzionamento di applicazioni disponibili 24/7. I log sono aggregati, centralizzati e subito disponibili, rendendo così il team di sviluppo più efficente e veloce nel rispondere tempestivamente in caso di problemi o malfunzionamenti. Anche le metriche di business sono facilmente visibili e disponibili, così come tutti gli alert legati alla sicurezza, che sono radunati in un unico posto e permettono un monitoraggio dello stato degli applicativi più semplice ed efficace.
Un Internal Developer Portal deve prevedere anche uno spazio per la documentazione, per far sì che la conoscenza venga conservata e condivisa. La documentazione è così radunata in un unico posto e resa disponibile dall’Internal Developer Portal, senza che gli sviluppatori debbano accedere a tanti diversi strumenti – come ad esempio Wiki, cartelle condivise, piattaforme dedicate – per poterla reperire e consultare.
Inoltre, siccome la documentazione è fatta dai developer per i developer, il miglior modo per incentivarne la scrittura e la fruizione è l’adozione di un approccio Docs as Code. Questo approccio considera la documentazione come parte integrante del codice, che quindi deve essere redatta e mantenuta utilizzando gli strumenti e le metodologie che gli sviluppatori usano per le loro attività quotidiane sul codice. In generale, la documentazione deve quindi essere basata su Git, per favorire la collaborazione e gestire il versionamento, e deve essere redatta con un linguaggio di markup testuale come, ad esempio, il Markdown.
Altre funzionalità chiave di un Internal Developer Portal sono legate all’automazione: è possibile, infatti, creare la documentazione partendo direttamente dalle specificazioni API e dagli schemi degli eventi, così come raccogliere in un unico posto i file README di ciascun microservizio, per avere una panoramica completa che si aggiorna in automatico ogni volta che viene modificato un file. Inoltre, è utile creare guide, esempi, best‑practice per accelerare l’onboarding di nuovi membri del team e uniformare le pratiche di sviluppo all’interno dell’azienda. Infine, inserire diagrammi architetturali sempre aggiornati permette agli sviluppatori di essere sempre allineati.
Ricapitolando, grazie all’adozione della metodologia Agile e del paradigma DevOps, associati a un’organizzazione in Feature Teams, le aziende possono migliorare notevolmente lo sviluppo di software cloud native. Per evitare, però, che la diffusione massiccia di nuovi strumenti e tecnologie di sviluppo ostacoli l’attività dei team di sviluppo invece che accelerarla, è necessario mettere al centro i developer e la loro esperienza di sviluppo (Developer Experience o DevX), abbandonando il vecchio approccio secondo cui sono i developer che devono adeguarsi all’infrastruttura. Per migliorare la DevX, uno degli strumenti più efficaci è l’Internal Developer Portal (IDP), cioè un portale unico che raccoglie tutti i servizi e gli strumenti disponibili in un unico posto, semplificando il processo di sviluppo in ogni sua fase, dal design alla scrittura della documentazione.
La creazione da zero di un IDP, però, può essere un processo lungo e costoso, in quanto per massimizzarne l’efficacia è necessario sviluppare molte funzionalità diverse e interconnesse tra di loro. C’è il rischio di investire tutto il tempo risparmiato grazie all’adozione delle nuove tecnologie e metodologie di sviluppo DevOps nella creazione e manutenzione dell’IDP stesso, invece che reimpiegarlo per aumentare la produttività. La soluzione è quindi adottare un Internal Developer Portal già pronto come quello fornito da Mia‑Platform* per evitare le preoccupazioni legate all’infrastruttura, e concentrarsi sulla personalizzazione in base alle necessità del business.
*Mia‑Platform è uno dei 10 fornitori a livello globale menzionati nel report Gartner “Innovation Insight for Internal Developer Portals”, redatto da Manjunath Bhat, Mark O’Neill e Oleksandr Matvitskyy, 1 Febbraio 2022
GARTNER is registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s Research & Advisory organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.