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.

 

Cos’è un Internal Developer Portal

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:

  • Un API catalog ben documentato;
  • Un Service Catalog, ossia un marketplace di servizi (o microservizi) già testati e riutilizzabili che espletino le funzionalità più comuni. Il Service Catalog deve essere sempre arricchito e mantenuto nel tempo per rispondere alle esigenze in evoluzione dei developer;
  • Un accesso diretto a tutti gli strumenti di sviluppo e gestione DevOps utilizzati e utilizzabili all’interno dell’azienda;
  • La documentazione completa dell’infrastruttura IT aziendale;
  • Linee guida e best practices per lo sviluppo di nuovi componenti;
  • Strumenti di monitoraggio.

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.

 

Come un Internal Developer Portal può aiutare la tua organizzazione

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. 

 

1. Infrastruttura: gestione trasparente dei cluster

È 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:

  • La scalabilità dell’infrastruttura, sia orizzontale che verticale; 
  • I sistemi di backup;
  • I sistemi di monitoraggio;
  • I sistemi di alert. 

Un Internal Developer Portal permette di ottenere anche un notevole risparmio di risorse e costi attraverso: 

  • il monitoraggio di tutti gli aspetti del ciclo di vita del software, in quanto è possibile sapere se ci sono risorse inutilizzate che possono essere spente o reimpiegate per altri sistemi;
  • la condivisione dell’infrastruttura secondo l’approccio multi‑tenancy, che permette di distribuire anche i costi infrastrutturali.

 

2. Design e riuso: controllo totale del software rilasciato

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:

  • Gli aspetti di sicurezza;
  • Il versionamento dei servizi;
  • L’aggregazione dei servizi e il versionamento del prodotto.

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.

 

3. Deploy: nessun collo di bottiglia

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:

  • taggare i deploy;
  • eseguire dry run deployment per avere un’anteprima del nuovo sviluppo prima del deploy effettivo;
  • eseguire rollback in caso di problemi;
  • lanciare test automatici.

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. 

 

4. Monitoraggio: controllo dello stato di salute delle tue applicazioni

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. 

 

5. Documentazione: condivisione della conoscenza

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.

 

Conclusioni

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.


Torna all'inizio

White Paper - Digital Integration Hub: portare i dati al centro per accelerare lo sviluppo di nuovi servizi digitali

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

© MIA s.r.l. Tutti i diritti riservati