Aspetti fondamentali dell'implementazione della piattaforma
L'engineering della piattaforma è un approccio multidisciplinare che combina engineering del software, progettazione del sistema ed eccellenza operativa per creare un'infrastruttura affidabile e scalabile per la creazione e la distribuzione di applicazioni. Nel suo nucleo, implica non solo la creazione di piattaforme solide, ma la creazione di un ambiente self-service che consenta ai team di sviluppo di garantire l'allineamento con gli obiettivi aziendali. Un'iniziativa di engineering della piattaforma di successo inizia con il team giusto e una chiara comprensione dello spazio dei problemi. Questa base consente lo sviluppo di sistemi che semplificano le operazioni, riducono l'attrito e consentono agli sviluppatori di concentrarsi sulla creazione di applicazioni anziché sulla gestione dell'infrastruttura.
Una volta che il team è attivo, l'attenzione si sposta verso l'automazione delle aree che richiedono un duro lavoro, identificando attività manuali e ripetitive che possono essere automatizzate per risparmiare tempo e ridurre gli errori. A questo scopo, un inventario delle risorse esistenti è essenziale, consentendo ai team di centralizzare strumenti e servizi, semplificando la gestione e la scalabilità. Il passaggio successivo viene definito percorsi lastricati sfavillanti, che implicano la creazione di flussi di lavoro e ambienti standard che garantiscono la coerenza tra i progetti. Successivamente, la distribuzione di ambienti come servizio consente di semplificare ulteriormente i processi, consentendo ai team di creare rapidamente ambienti su richiesta. A questo punto, l'obiettivo primario diventa l'ottimizzazione delle esperienze di sviluppo self-service, consentendo agli sviluppatori di gestire i flussi di lavoro in modo indipendente, assicurando al tempo stesso gli strumenti e il supporto necessari per il successo. Questo approccio trasforma il modo in cui i team di sviluppo interagiscono con l'infrastruttura, creando un ambiente agile e ad alte prestazioni per la compilazione e la distribuzione di applicazioni.
Oltre ad avere un piano di implementazione chiaramente definito, invece di approcciarsi all'engineering della piattaforma come singolo concetto generale, può essere utile suddividerlo in quattro aree principali per facilitare il processo di implementazione:
- Sistemi di engineering, che include strumenti e servizi che consentono lo sviluppo, ad esempio CI/CD, gestione dei pacchetti, ambienti di codifica basati sul cloud, scanner di codice e linter, nonché assistenti di intelligenza artificiale (IA) come GitHub Copilot.
- Piattaforma applicativa, costituita da una selezione curata di servizi usati come blocchi predefiniti di stack di app di uso comune, ad esempio Criteri di Azure, Azure Key Vault, App contenitore di Azure o Cosmos DB.
- Modelli di applicazione, che forniscono modelli ben definiti e specifici dell'organizzazione per facilitare il provisioning dei carichi di lavoro e allinearsi alle procedure consigliate.
- Funzionalità self-service per sviluppatori, che consentono agli sviluppatori di gestire autonomamente i flussi di lavoro garantendo al tempo stesso governance e conformità agli standard dell'organizzazione.
Incorporando queste aree nella strategia di implementazione, si riduce la mole di lavoro degli sviluppatori, si promuove l'innovazione e si crea un'esperienza di sviluppo senza problemi.
Creare un team
Nell'organizzazione dell'engineering della piattaforma, promuovere la cultura giusta è essenziale per il successo a lungo termine. La transizione da una cultura reattiva a una cultura proattiva è fondamentale, dove i team della piattaforma si occupano della creazione e della gestione degli strumenti per supportare l'organizzazione. Questo passaggio è fondamentale per ridurre i silo di conoscenze e le interruzioni operative. Il successo degli sforzi dell'engineering della piattaforma si allinea alla capacità di investimento descritta nel modello di capacità di engineering della piattaforma, che sottolinea il passaggio attraverso fasi di maturità organizzativa, dalla fase provvisoria all'ottimizzazione. Nella fase provvisoria, le aziende riconoscono la necessità dell'engineering della piattaforma, ma potrebbero non essere allineate completamente tra i team di leadership e di sviluppo. Man mano che le organizzazioni maturano, il buy-in esecutivo e i cambiamenti culturali incoraggiano un ambiente più collaborativo e innovativo in cui i team della piattaforma sono capaci di promuovere un cambiamento significativo, consentendo alle organizzazioni di ridimensionarsi in modo efficace.
Un team di engineering della piattaforma richiede un set diversificato di competenze tecniche e una mentalità incentrata sul prodotto per creare e ridimensionare piattaforme di sviluppo interne affidabili, efficienti e sicure. I progettisti della piattaforma devono essere esperti in diverse aree chiave, tra cui orchestrazione dei contenitori (ad esempio Kubernetes), pipeline CI/CD (ad esempio GitHub Actions, Azure Pipelines) e strumenti di monitoraggio (ad esempio, Monitoraggio di Azure, Prometheus, Grafana). La competenza negli strumenti IaC (Infrastructure as Code) come Terraform e Bicep è fondamentale per automatizzare il provisioning dell'infrastruttura. Inoltre, i tecnici della piattaforma devono avere familiarità con la scrittura di codice in linguaggi di scripting come Python, PowerShell o Bash per abilitare l'automazione e l'integrazione tra sistemi. Anche se il pool di talenti per i progettisti della piattaforma può essere difficile da sfruttare, un team di successo deve combinare competenze provenienti da diversi background, ad esempio sviluppo software, Site Reliability Engineering (SRE) e operazioni IT.
Automatizzare che richiedono un duro lavoro
L'automazione delle aree che richiedono un duro lavoro rappresenta comunemente il primo percorso lastricato sulla strada per abilitare le funzionalità self-service dello sviluppatore. Per implementarla, iniziare identificando processi frequenti, soggetti a errori o a elevato utilizzo di manodopera, in particolare quelli legati alle operazioni manuali o di service desk. Valutare, quindi, fattori come la frequenza dei processi, la complessità e la verificabilità per classificare in ordine di priorità gli obiettivi dell'automazione. L'implementazione IaC (Infrastructure as Code) nelle pipeline di recapito continuo (CD) non solo semplifica la distribuzione delle applicazioni, ma consente anche il provisioning dinamico di strumenti e infrastrutture condivise. Usare piattaforme CI/CD flessibili come GitHub Actions e Azure DevOps o soluzioni GitOps come Flux e Argo CD per ridurre i colli di bottiglia e supportare i team.
Col tempo, l'adozione del modello EaC (Everything as Code) crea un framework di automazione sicuro e ripetibile, usando repository Git centralizzati per modelli e configurazioni IaC (inclusi, ad esempio, modelli Bicep e Azure Resource Manager, file manifesto Terraform e grafici Helm). Questi repository, gestiti da un team operativo, consentono agli sviluppatori di inviare richieste pull che vengono esaminate e controllate in modo sicuro prima dell'unione. Gli stessi strumenti CI/CD possono quindi effettuare il provisioning e configurare qualsiasi infrastruttura, strumenti o servizi, sia specifici dell'applicazione che condivisi. Questo approccio supporta scalabilità, self-service per sviluppatori e integrazione senza problemi con i processi di governance, garantendo che l'engineering della piattaforma sia allineato agli obiettivi dell'organizzazione, promuovendo al tempo stesso l'agilità operativa.
L'approccio Everything as Code ruota intorno alla rappresentazione di quasi tutte le risorse o processi come file in un repository Git sicuro. Le solide funzionalità di sicurezza di Git, ad esempio la cronologia dei commit, i controlli di accesso, le richieste pull e le protezioni dei rami, garantiscono trasparenza, abilitano revisioni collaborative e applicano controlli automatizzati prima dell'integrazione delle modifiche. In combinazione con i sistemi CI/CD, ciò crea un framework versatile, verificabile e sicuro per la gestione dell'infrastruttura, degli strumenti e dei processi.
Inventario e centralizzazione
Con la crescita delle organizzazioni, il volume e la complessità dei loro asset tecnici si espandono, spesso comportando la duplicazione di sforzi, progetti orfani e risorse sprecate. La centralizzazione dell'inventario e del rilevamento degli asset è un passaggio fondamentale nell'engineering della piattaforma per gestire queste sfide. Un sistema di inventario consente ai team di tenere traccia e gestire asset come codice, API, contenitori, macchine virtuali (VM), autorizzazioni e altro ancora. Questo processo non solo migliora la governance, ma promuove anche il riutilizzo e migliora l'individuabilità, consentendo ai team di operare in modo più efficiente ed efficace.
Gli inventari centralizzati svolgono un ruolo vitale per migliorare la governance contrassegnando e organizzando gli asset. L'assegnazione corretta di tag garantisce che le risorse siano associate ai rispettivi proprietari o team, semplificando la gestione dei cicli di vita e la comprensione del potenziale impatto delle modifiche. L'individuabilità avanzata è un altro vantaggio chiave, poiché riduce il disordine tecnico aiutando i team a trovare e riutilizzare le risorse esistenti, impedendo l'inutile duplicazione del lavoro. Inoltre, la centralizzazione degli inventari consente alle organizzazioni di ottimizzare le risorse identificando e ripulendo asset obsoleti o non necessari, riducendo i rifiuti e aumentando i risparmi sui costi.
Vari strumenti supportano l'inventario e il monitoraggio degli asset, ognuno dei quali provvede a diversi aspetti dell'ecosistema tecnico. Ad esempio, gli ambienti di distribuzione di Azure (ADE) forniscono un mezzo per tenere traccia di un'infrastruttura complessa creata tramite IaC (Infrastructure as Code). Analogamente, il Centro API di Azure consente agli sviluppatori di individuare e gestire le API in modo efficiente. I registri in pacchetti, ad esempio GitHub Packages o Azure Artifacts, offrono un valore aggiuntivo migliorando la sicurezza della catena di approvvigionamento e gestendo pacchetti e SDK approvati.
Per migliorare ulteriormente i vantaggi dei sistemi di inventario, le organizzazioni possono stabilire collegamenti relazionali tra asset per creare una visione più completa del loro ecosistema. Ad esempio, il mapping delle relazioni tra una definizione API, il relativo repository di codice, gli ambienti associati e i criteri di governance consentono ai team di gestire le risorse con maggiore precisione.
Percorsi lastricati sfavillanti
Nell'engineering della piattaforma, l'analogia del "percorso lastricato" trasmette l'equilibrio tra la promozione dell'innovazione e la fornitura di indicazioni standardizzate. Inizialmente, i team possono intraprendere percorsi diversi e informali per raggiungere i propri obiettivi, sperimentando diversi strumenti e flussi di lavoro. Col tempo, i team della piattaforma osservano gli approcci più efficaci e ampiamente adottati e li convertono in "percorsi lastricati", flussi di lavoro ottimizzati, efficienti, intuitivi e accattivanti da adottare per i team.
Questo processo, spesso descritto come "percorsi lastricati sfavillanti", implica l'identificazione di modelli comuni nei flussi di lavoro del team e la loro trasformazione in soluzioni standardizzate e scalabili. Questi percorsi integrano perfettamente la sicurezza, le procedure consigliate per l'architettura e i requisiti di conformità, offrendo un'esperienza uniforme e affidabile. Gli sviluppatori traggono vantaggio da un carico cognitivo ridotto, API coerenti per l'integrazione, funzionalità modulari che possono essere combinate in base alle esigenze e prestazioni prevedibili in linea con gli obiettivi operativi.
Il modello di funzionalità dell'engineering della piattaforma svolge un ruolo fondamentale in questo processo, aiutando le organizzazioni a determinare quando passare da percorsi informali a percorsi lastricati. Identifica le aree che richiedono la standardizzazione e fornisce informazioni dettagliate su come ridimensionare queste procedure in modo efficace. Questo approccio strutturato garantisce che l'innovazione non sia repressa, mantenendo al contempo l'attenzione su qualità, conformità e prestazioni.
L'approccio percorsi lastricati sfavillanti incoraggia le buone pratiche senza essere eccessivamente prescrittivo. Supporta i contributi della community, consentendo ai team di collaborare e modellare la piattaforma, mantenendo al tempo stesso la flessibilità per casi d'uso univoci. Bilanciando l'innovazione e la standardizzazione, questa metodologia promuove un ambiente in cui i team possono eccellere assicurando al tempo stesso che i requisiti dell'organizzazione vengano soddisfatti in modo coerente.
Distribuire ambienti come servizio
La distribuzione di ambienti come servizio mira a fornire un provisioning dell'infrastruttura sicuro, standardizzato e automatizzato. Un principio chiave in questo approccio è un provisioning persistente di segreti e identità in modo da impedire agli sviluppatori di accedervi direttamente. Ciò impone la governance garantendo al tempo stesso che gli aggiornamenti dell'infrastruttura rimangano sicuri. Ad esempio, gli ambienti di distribuzione di Azure (ADE) esemplificano questo modello supportando la separazione dei ruoli e centralizzando la gestione dei modelli IaC.
Con ADE, i tecnici della piattaforma e i team operativi creano e mantengono in modo collaborativo un catalogo di modelli per tipi di ambiente specifici. Questi modelli, arricchiti con impostazioni preconfigurate, integrano identità gestite e controllano l'accesso in base ai ruoli. Gli sviluppatori possono quindi usare pipeline CI/CD per effettuare il provisioning dell'infrastruttura tramite strumenti come l'interfaccia della riga di comando di Azure o Azure Develiper CLI senza dover accedere direttamente a credenziali sensibili o alla sottoscrizione sottostante. Questa separazione garantisce la conformità e la sicurezza preservando al tempo stesso la produttività degli sviluppatori.
Anche se ADE non è in uso, gli stessi principi possono essere applicati in modo più ampio, con il contenuto IaC (Infrastructure as Code) originato da posizioni sicure, non modificabili e la gestione dei segreti automatizzata e isolata. Abilitando queste procedure, l'engineering della piattaforma consente ai team di distribuire ambienti coerenti mantenendo al contempo la governance dell'organizzazione e l'efficienza operativa.
Ottimizzare l'esperienza di sviluppo self-service
Un'esperienza di sviluppo self-service perfetta è fondamentale per il successo dell'engineering della piattaforma, ma ciò spesso richiede di riunire gli utenti dove si trovano. Ogni ruolo, sviluppatori, operazioni e altri, gravitano verso strumenti e ambienti specifici che definiscono i flussi di lavoro. Per nuove esperienze per ottenere l'adozione, è importante allinearsi a questi "centri di gravità esistenti". Un approccio pragmatico prevede la pianificazione di più interfacce utente personalizzate per gli strumenti già in uso, consentendo ai team di iniziare con semplici miglioramenti, dimostrare il loro valore e di evolversi verso soluzioni più sofisticate in base alle esigenze.
Invece di creare esperienze completamente nuove, è consigliabile migliorare e integrare gli strumenti esistenti. Piattaforme come editor, ambienti di sviluppo integrato (IDE), suite DevOps, strumenti dell'interfaccia della riga di comando e ambienti con poco codice spesso hanno modelli di estendibilità che consentono la personalizzazione e l'espansione con un sovraccarico minimo. Questo approccio riduce la manutenzione, applica esperienze utente familiari e accelera l'adozione. Ad esempio, le estensioni IDE basate sul Web, come quelle create per VS Code o vscode.dev, forniscono un punto di partenza flessibile e compatibile con il Web che può essere ridimensionato in ambienti di sviluppo locali. Analogamente, interfacce ChatOps in strumenti come Microsoft Teams o Slack offrono modi intuitivi per attivare flussi di lavoro di automazione e integrarsi con le piattaforme CI/CD.
Per le organizzazioni che necessitano di un'interfaccia centralizzata, investire in un portale per sviluppatori personalizzato può offrire vantaggi a lungo termine, ma richiede risorse e un'attenta pianificazione. Soluzioni come Backstage.io, un toolkit sviluppato inizialmente da Spotify, offre portali altamente personalizzabili che possono integrare plug-in e strumenti di terzi, creando un hub dinamico incentrato sugli sviluppatori. Indipendentemente dal fatto che si inizi con soluzioni leggere come Power Pages o si crei un portale completo, l'obiettivo è offrire esperienze scalabili e intuitive che consentano agli sviluppatori di allinearsi alle esigenze dell'organizzazione.