Internal Developer Platform: Quando Ha Senso e Quando No
Internal developer platform: cos'è, quando costruirne uno è giustificato e quando crea più complessità di quanta ne risolva per il tuo team di ingegneria.
In questo articolo:
- Cosa è davvero una internal developer platform
- Il problema che risolve e per chi
- Quando costruire un IDP è la decisione sbagliata
- Il platform engineering come disciplina
- La developer experience e il costo reale del carico cognitivo
- Conclusione
L’internal developer platform (IDP) è diventato uno dei concetti più discussi nel platform engineering negli ultimi anni. Alcune organizzazioni lo trattano come la soluzione a una scarsa developer experience, deployment lenti e infrastruttura inconsistente. Altre ne costruiscono uno e lo trovano diventare un altro sistema da mantenere, un’altra fonte di debito tecnico e un’altra ragione per cui i developer sono frustrati. La differenza è raramente nella piattaforma stessa. Sta nel fatto che l’organizzazione avesse un problema che un IDP risolve effettivamente. Questa guida spiega cosa è una internal developer platform, quando crea valore reale e quando è una soluzione in cerca di un problema.
Cosa è Davvero una Internal Developer Platform
Una internal developer platform è uno strato self-service che astrae le operazioni di infrastruttura in modo che i team di sviluppo possano fare provisioning di ambienti, effettuare deployment di applicazioni e gestire i servizi senza attendere i team di operations o di piattaforma.
In pratica, un IDP fornisce tipicamente: un catalogo di servizi che elenca i building block di infrastruttura disponibili, un’interfaccia di deployment dove i developer possono rilasciare codice senza scrivere YAML Kubernetes o Terraform, il provisioning degli ambienti che crea ambienti di test on demand e integrazioni di osservabilità che mostrano log e metriche in un unico posto.
Gli IDP sono una risposta a un problema reale. Man mano che le organizzazioni adottano Kubernetes, infrastruttura cloud-native e microservizi, la complessità operativa aumenta più velocemente di quanto molti team di sviluppo possano assorbire. Gli sviluppatori trascorrono quantità crescenti di tempo su attività infrastrutturali che non sono la loro competenza principale e i team di operations diventano un collo di bottiglia.
Il Problema che Risolve e per Chi
Un IDP risolve il problema del carico cognitivo su scala. Quando un team ha quindici microservizi, ciascuno con la propria configurazione di deployment, gestione degli ambienti e runbook operativo, l’overhead della gestione di questa complessità ricade su ogni sviluppatore di ogni team. Moltiplicalo per dieci team e hai un significativo ostacolo all’efficienza del team di sviluppo.
Le organizzazioni che traggono valore reale da un IDP condividono certe caratteristiche. Hanno più team di sviluppo che condividono preoccupazioni infrastrutturali. Hanno raggiunto una scala in cui il team di operations è un collo di bottiglia ricorrente per i task di routine. Hanno una complessità infrastrutturale sufficiente che la standardizzazione produrrebbe risparmi di tempo significativi. E hanno ingegneri con la capacità di costruire e mantenere la piattaforma.
Per queste organizzazioni, un IDP può ridurre il tempo che gli sviluppatori trascorrono sull’infrastruttura da ore a settimana a minuti. Standardizza i pattern di deployment, riducendo la superficie per le misconfigurazioni. Accelera l’onboarding perché i nuovi ingegneri hanno un unico posto dove andare per tutti i task operativi.
Quando Costruire un IDP è la Decisione Sbagliata
Costruire una internal developer platform è un investimento significativo. La piattaforma stessa deve essere costruita, documentata e mantenuta. I platform engineer diventano un prerequisito per aggiungere nuove capacità. La piattaforma ha i propri bug, i propri requisiti di sicurezza e il proprio onere operativo.
Per i team al di sotto di una certa scala, questo investimento non ripaga. Un’organizzazione con tre team di sviluppo e un’infrastruttura cloud semplice non dovrebbe costruire un IDP personalizzato. L’overhead della manutenzione della piattaforma supera i risparmi derivanti dal self-service.
C’è anche un problema di sequenziamento. Le organizzazioni che costruiscono un IDP su una superficie infrastrutturale inconsistente e poco compresa stanno codificando i loro problemi attuali nella piattaforma. Se la pipeline di deployment è inaffidabile, l’IDP esporrà quella inaffidabilità a più persone più velocemente. Se l’infrastruttura non è documentata, l’IDP darà agli sviluppatori un pulsante da premere senza capire cosa fa.
Un IDP dovrebbe essere costruito dopo che l’infrastruttura sottostante è stabile, documentata e coerente. Se il tuo team sta lottando con sistemi legacy, deployment fragili o debito tecnico non affrontato, un IDP non è il punto di partenza.
Il Platform Engineering come Disciplina
Il platform engineering è la pratica di trattare la piattaforma per sviluppatori come un prodotto. Il team di piattaforma ha clienti interni: i team di sviluppo. Conduce ricerca sugli utenti, priorizza le funzionalità in base ai pain point degli sviluppatori e misura il successo tramite metriche di produttività degli sviluppatori piuttosto che tramite l’uptime della piattaforma.
Questo mindset da prodotto è ciò che distingue le iniziative di platform engineering di successo da quelle fallite. Le piattaforme costruite da team di infrastruttura senza input degli sviluppatori tendono a riflettere le preoccupazioni dell’infrastruttura piuttosto che le esigenze degli sviluppatori.
Una formulazione utile è: la piattaforma dovrebbe ridurre il carico cognitivo richiesto agli sviluppatori per passare dal codice alla produzione. Ogni punto di attrito in quel percorso è una potenziale funzionalità della piattaforma. Il compito del team di piattaforma è identificare i punti di attrito di maggior valore e affrontarli in ordine di impatto.
Il progetto open-source Backstage di Spotify è il punto di partenza più adottato per i portali IDP. Fornisce un’architettura a plugin che consente alle organizzazioni di costruire cataloghi di servizi, hub di documentazione e interfacce di deployment senza partire da zero.
La Developer Experience e il Costo Reale del Carico Cognitivo
La developer experience (DX) è diventata una disciplina riconosciuta nelle organizzazioni ingegneristiche. Il carico cognitivo imposto agli sviluppatori da tooling complesso, processi inconsistenti e infrastruttura opaca riduce direttamente il tempo disponibile per il lavoro sul prodotto.
La ricerca in questo campo mostra costantemente che i cambi di contesto, l’attesa degli strumenti e la navigazione di processi poco chiari sono tra i contributori più significativi alla riduzione dell’efficienza del team di ingegneria. Uno sviluppatore che trascorre due ore al giorno su overhead operativo perde il 25 percento della sua capacità produttiva.
Un IDP affronta la DX standardizzando e automatizzando i workflow ad attrito più elevato. Ma i problemi di DX non sono sempre problemi infrastrutturali. A volte sono problemi di processo: proprietà poco chiara, carico eccessivo di riunioni o documentazione scarsa. A volte sono problemi del codebase: un codebase complesso e mal strutturato che richiede un contesto esteso per lavorarci.
Prima di investire nel platform engineering, vale la pena diagnosticare dove si rompe la developer experience.
Conclusione
Una internal developer platform può produrre miglioramenti reali nella developer experience e nell’efficienza del team di ingegneria, ma solo nelle condizioni giuste. Richiede una scala sufficiente a giustificare l’onere di manutenzione, un’infrastruttura sottostante stabile su cui costruire e un team di piattaforma con un mindset da prodotto.
Per i team che non sono ancora lì, l’investimento nel miglioramento del codebase sottostante e dei processi di deployment produrrà risultati più rapidi rispetto alla costruzione di uno strato di piattaforma sopra i problemi esistenti.
Hai un codebase con questi problemi? Parliamo del tuo sistema