Build vs Buy: Guida per Platform Engineers

Questo articolo è stato pubblicato in origine su The New Stack.

Domandarsi se acquistare (Buy) o costruire da zero (Build) una Internal Developer Platform (IDP) è comune per tutte le aziende che iniziano il loro percorso verso il platform engineering. Tuttavia, non esiste una soluzione valida per tutti. In questo articolo verranno analizzati i pro e i contro dei due approcci e verranno fornite indicazioni su come prendere la decisione migliore per la tua organizzazione.

Internal Developer Platform o Platform as a Service?

Prima di entrare nel merito di questa discussione, spieghiamo che cosa intendiamo per costruire (Build) o acquistare (Buy) una IDP. Il Platforms White Paper del CNCF si basa sulla definizione di Internal Developer Platform (o di digital platform) fornita da Martin Fowler ed Evan Bottcher:

“Una digital platform è una infrastruttura di API self-service, strumenti, servizi, conoscenze e supporto… organizzata come un prodotto interno convincente. I team di delivery autonomi possono utilizzare la piattaforma per fornire funzionalità di prodotto a un ritmo più elevato, riducendo le tempistiche dedicate al coordinamento.”

Alcuni sostengono che questa definizione implichi che le Internal Developer Platform (IDP) debbano essere costruite e non possano essere acquistate. Tuttavia, questa distinzione può essere poco chiara poiché alcuni fornitori pubblicizzano i loro prodotti come IDP. È più utile comprendere quali caratteristiche distinguono le piattaforme costruite da quelle acquistate.

Una Internal Developer Platform che può essere acquistata è spesso chiamata Platform as a Service (PaaS). Mentre una IDP è una raccolta di diverse tecnologie e strumenti collegati tra loro, una PaaS è un unico strumento che copre alcune (ma non necessariamente tutte) delle stesse funzionalità.

Un’altra distinzione chiave è chi decide come lavorano gli sviluppatori. Con una PaaS, il fornitore definisce la user experience e i limiti della piattaforma. Con una IDP su misura, è l’azienda a definire la user experience e i confini della piattaforma; le limitazioni derivano dalle competenze del platform team, dal budget e dal contesto aziendale.

È importante comprendere che la realizzazione di una IDP internamente (e da zero) o l’acquisto di una PaaS sono due soluzioni che si escludono a vicenda. Costruire o acquistare non è una scelta binaria.

Data la natura restrittiva delle offerte PaaS, non vedrai molte aziende acquistare una PaaS e costruire il resto della piattaforma attorno a essa. Tuttavia, alcune aziende potrebbero acquistare una Internal Developer Portal, un platform builder, un control plane, una DevOps platform, una application delivery platform o un altro tipo di strumento per piattaforme da un fornitore, costruendo internamente solo ciò che è necessario. La maggior parte delle organizzazioni utilizza una combinazione di strumenti costruiti, acquistati e open source per la propria piattaforma.

Tenendo presente queste due soluzioni Build e Buy, esaminiamone i vantaggi e gli svantaggi.

Costruirsi internamente una Internal Developer Platform: Pro e Contro

Pro di una soluzione Build

Una platform engineering è difficile da realizzare correttamente, ma sta comunque guadagnando sempre più terreno. Anche per buone ragioni. Costruire una IDP consente alle organizzazioni, in particolare alle imprese, di creare qualcosa perfettamente adatto alle loro esigenze. Molte organizzazioni costruiscono la propria IDP per una maggiore:

• Personalizzazione: Costruire una IDP offre il controllo completo sulle sue specifiche e sulla roadmap delle funzionalità. Questa autonomia consente ai platform team di adattare la IDP alle esigenze e ai flussi di lavoro specifici dei loro sviluppatori senza dover attendere un fornitore. La personalizzazione è particolarmente preziosa per le organizzazioni in settori altamente regolamentati con requisiti di conformità stretti.
• Scalabilità: Le organizzazioni in rapida crescita notano che le opzioni fornite dai vendor non riescono a tenere il loro passo. I platform team interni sono meglio attrezzati per scalare la piattaforma insieme all’azienda.
• Estensibilità: I platform team possono progettare la loro IDP in modo che i suoi componenti siano facili da sostituire quando necessario. Questa flessibilità può essere estremamente importante man mano che la piattaforma matura.
• Integrazione con sistemi legacy: La maggior parte delle imprese deve costruire almeno una parte della propria IDP per garantire una piena integrazione con le tecnologie esistenti sviluppate internamente. Come spiega Jim Beyers, VP of engineering enablement in CVS Health: “…una volta che raggiungi un certo livello, non so se esistano soluzioni adatte… probabilmente dovremo costruirle noi stessi.”

In sintesi, costruire su misura una IDP offre un controllo e una compatibilità senza pari con i sistemi esistenti per le organizzazioni con esigenze specifiche, requisiti di conformità rigorosi o una crescita esponenziale. L’esperienza di CVS Health sottolinea che le soluzioni PaaS diventano poco efficaci oltre una certa dimensione aziendale.

Contro di una soluzione Build

Il processo di costruzione di una IDP non è esente da sfide. Se hai seguito il dibattito sul platform engineering, probabilmente hai sentito storie di organizzazioni che si sono trovate rapidamente in difficoltà nel costruire la propria piattaforma. Le organizzazioni che seguono questo approccio dovrebbero considerare:

• Costi iniziali: Costruire una IDP internamente richiede tempo e molto denaro. I platform team dovrebbero seguire un approccio platform-as-a-product per assicurarsi che gli stakeholder interessati comprendano l’investimento necessario. Senza un sostegno costante, le iniziative relative alla piattaforma possono essere interrotte prima di giungere a compimento.
• Manutenzione: Man mano che la piattaforma si espande, aumenta anche la responsabilità del platform team di rimanere al passo con i nuovi standard, aggiornamenti tecnologici e strumenti. Gregor Hohpe, autore di Cloud Strategy, nel suo intervento alla PlatformCon 2022 spiega come i platform team possono comprendere e comunicare quanta parte della piattaforma intendono mantenere:
  “Cosa farai con la tua piattaforma quando la piattaforma base crescerà? … Puoi lasciare la tua piattaforma così com’è perché hai investito tutto questo denaro, potremmo chiamarla una piattaforma che affonda mentre il livello dell’acqua sale, giusto? Potrebbe essere giustificato dall’investimento, ma stai duplicando funzioni che ora sono disponibili nella piattaforma base. … Oppure costruisci una ‘piattaforma galleggiante’, dove, quando la piattaforma base acquisisce le capacità che hai costruito, dici: ‘Perfetto! Non ho più bisogno di quella parte. Posso lasciare che la piattaforma base gestisca quella funzione e continuare a innovare al di sopra di essa.”

Fonte: “The Magic of Platforms” di Gregor Hohpe presentato alla PlatformCon 2022

• Pericoli nel copiare altre IDP: Copiare le IDP di Google, Netflix o Amazon è una ricetta per il fallimento. Esistono molti esempi e risorse sul platform engineering, ma i platform team devono comunque comprendere le esigenze specifiche della propria organizzazione.

Il modo migliore per mitigare queste sfide è seguire un approccio platform-as-a-product: condurre ricerche sugli utenti, creare una roadmap del prodotto, raccogliere feedback dagli utenti, iterare e migliorare continuamente e ottenere il sostegno interno da tutte le parti interessate. Questo approccio non solo aiuterà il tuo platform team a evitare insidie comuni, ma ti aiuterà anche a garantire che si realizzi una piattaforma che gli sviluppatori vogliano effettivamente utilizzare.

Acquistare una Platform as a Service: Pro e Contro

Pro di una soluzione Buy

Alcune organizzazioni non dispongono del personale, dei sistemi legacy o della crescita rapida che giustificherebbero la necessità di una IDP personalizzata. Per queste aziende, una PaaS può rappresentare un investimento più saggio. I vantaggi di una PaaS per queste organizzazioni includono:

• Riduzione del carico di lavoro sulle persone: Acquistare una PaaS solleva i tuoi team interni dal pesante lavoro di sviluppo e manutenzione. L’acquisto libera preziose risorse interne, permettendo loro di concentrarsi su problemi specifici dell’organizzazione.
• Supporto del fornitore: I fornitori di PaaS hanno un interesse diretto a mantenere la loro piattaforma competitiva. I fornitori possono dedicare più risorse a miglioramenti continui, aggiunte di funzionalità, aggiornamenti di sicurezza e supporto.
• Time to value più rapido: Il tempo necessario per implementare una PaaS è molto più breve rispetto alla costruzione di una IDP da zero. Con una PaaS, puoi sviluppare e mettere in produzione nuove applicazioni molto più rapidamente.
• Sicurezza di base: La maggior parte delle soluzioni PaaS offre alcune funzionalità di sicurezza integrate e aggiornate. Anche se queste potrebbero essere insufficienti per settori con requisiti di conformità specifici, possono alleggerire il carico sui team interni in ambiti meno regolamentati.
• Costo iniziale ridotto: Acquistare una PaaS comporta un costo iniziale più prevedibile e spesso inferiore, rendendola un’opzione più economica per le organizzazioni più piccole.

In sintesi, PaaS consente alle organizzazioni più piccole e in fase di avviamento di sbloccare la potenza di una IDP senza l’impegno e le spese monumentali di una sua realizzazione da zero. Per coloro che non hanno esigenze specifiche o sistemi legacy estesi che richiedano una piattaforma personalizzata, una soluzione PaaS offre un modo conveniente e supportato per migliorare l’esperienza degli sviluppatori.

Contro di una soluzione Buy

Aeris Ransom ha identificato diversi fattori chiave da considerare quando si decide se costruire o acquistare la propria IDP, tra i quali:

• Flessibilità limitata: Una PaaS può essere troppo rigida o predefinita per configurazioni mature. Come ha spiegato Camille Fournier: “Tende a diventare evidente quando è necessario costruire la propria piattaforma. Se stai usando Heroku, raggiungerai i limiti di scalabilità e vedrai i team separarsi e fare le proprie cose.”
• Potenziale vendor lock-in: I clienti di una soluzione PaaS dovrebbero acquistarla tenendo presente una strategia di uscita. Altrimenti, rischiano di rimanere bloccati negli approcci e nei flussi di lavoro del loro fornitore.
• Incompatibilità con i sistemi legacy: Una PaaS è improbabile che sia completamente compatibile con sistemi legacy estesi. Le incompatibilità causano seri problemi di integrazione e sicurezza per le aziende con una infrastruttura tecnologica già consolidata.

Date queste limitazioni, le organizzazioni che prevedono di superare la loro PaaS nel breve periodo dovrebbero considerare di costruire una IDP invece. Altrimenti, costringerai i tuoi sviluppatori ad adattarsi ai processi di un fornitore per poi farli cambiare nuovamente a breve. Cambiamenti frequenti e significativi nella piattaforma possono aumentare il carico cognitivo e peggiorare l’esperienza degli sviluppatori.

Build vs Buy?

La maggior parte delle organizzazioni costruisce alcune parti della propria IDP e ne acquista altre, sfruttando una combinazione di strumenti open source, commerciali e sviluppati internamente nella loro piattaforma. Questo approccio build-and-buy consente loro di ottenere più benefici mentre si mitigano gli svantaggi.

Tuttavia, questo approccio comporta delle sfide. Il CNCF Landscape, mostrato qui sotto, è vasto e confuso. I platform team spesso hanno bisogno di aiuto per capire come scegliere gli strumenti giusti e come integrarli al meglio. Tuttavia, la Platform Engineering Community ha svolto un ottimo lavoro creando una nuova versione e migliorando quindi il panorama degli strumenti di piattaforma.

Fonte: CNCF

In generale, gli esperti di platform engineering raccomandano di evitare di reinventare la ruota ove possibile. Abby Bangser, di Syntasso, scrive:

“In generale, man mano che i componenti della piattaforma diventano una commodity nel settore, diventa più probabile acquistare una soluzione per beneficiare degli investimenti che le altre organizzazioni fanno per mantenere il loro prodotto in un panorama competitivo.”

Questo consiglio si applica sia all’inizio che alla fine del percorso di progettazione della piattaforma. Pertanto, nel momento in cui decidete di acquistare o costruire, è importante capire come potrebbe evolvere la vostra piattaforma e quali strumenti la vostra organizzazione può sfruttare lungo il percorso.

Si noti inoltre che con l’approccio build-and-buy si corre ancora il rischio di vendor lock-in e di costi di abbonamento elevati. In teoria, le IDP costruite e acquistate sono più estensibili, ma devono essere ben architettate per esserlo nella pratica. Il costo dei componenti della piattaforma di terze parti può aumentare rapidamente e diventare ingestibile se i platform team non sono attenti. Le organizzazioni devono fare le dovute verifiche, sia che acquistino una PaaS completa che un componente della piattaforma.

Build vs Buy: Considerazioni finali

Non esiste una risposta univoca alla scelta di costruire o acquistare una IDP. Considerando attentamente i pro e i contro di ciascun approccio e ottenendo il feedback degli utenti e degli altri stakeholder, potrete prendere la decisione migliore per la vostra organizzazione.

I fattori chiave da considerare quando si decide se costruire o acquistare la propria IDP includono:

• Configurazione esistente: Hai un setup greenfield (da realizzare da zero) o brownfield (che aggiorna uno esistente)? Quali sono le esigenze di integrazione di cui il tuo platform team deve tenere conto?
• Dimensione: Quanti sviluppatori ci sono nella vostra organizzazione? Si prevede che questo numero cresca rapidamente?
• Obiettivi a lungo termine: Qual è la vostra roadmap di prodotto? Quali soluzioni di terze parti possono supportare l’evoluzione della piattaforma?

La considerazione più importante è che nessuna delle due soluzioni (Build, Buy o entrambe) può garantire il successo della piattaforma. C’è molto di più nella platform engineering.

Nel frattempo, consulta questa guida gratuita su come evolvere in una platform company.