Consentire agli sviluppatori di usare self-service con protezioni
Self-service con protezioni è il principio di consentire ai team di sviluppo di prendere le proprie decisioni all'interno di un set di parametri ben definiti o guardrail. Le guardrail vengono stabilite e concordate da parte degli stakeholder chiave. Gli stakeholder possono includere i team di sicurezza, operazioni, architettura nell'intera organizzazione.
Con il self-service con protezioni, i team di sviluppo mantengono l'autonomia per prendere decisioni di sviluppo in modo indipendente. Automazione e criteri aiutano gli stakeholder a garantire che la sicurezza, la conformità, le operazioni, gli standard e i costi siano gestiti correttamente. L'abilitazione di questa automazione richiede la collaborazione tra le linee del team in modo che sviluppatori, operatori e specialisti possano fare di più, senza sacrificare la governance necessaria. Gli sviluppatori possono quindi concentrarsi sulla distribuzione del valore aziendale il più rapidamente possibile.
[Diciamo agli sviluppatori,] non preoccuparti di come funziona tutto, basta attivarli o disattivarli, compilarlo, inserire una stringa in tutto ciò che è necessario fare ed è fondamentalmente self-service in questo senso dove hanno un file leggimi e hanno input, output e possono inserire qualsiasi cosa vogliano. - Daniel, Cloud Engineer, Fortune 500 Media Company
L'obiettivo di offrire un'esperienza self-service per i percorsi pavimentati è ridurre la fatica dello sviluppatore, offrendo anche visibilità ai team di sviluppo, alle operazioni e alla gestione. L'idea è che si crea un'esperienza per una determinata attività con una curva di apprendimento minima, grazie in parte alle funzionalità di automazione e aggregazione dei dati sottostanti. Oltre alle attività come il provisioning dell'infrastruttura, queste esperienze possono fornire l'accesso alle funzionalità critiche per l'osservabilità, i criteri, la gestione degli eventi imprevisti e altro ancora. L'idea si estende all'individuazione e alla condivisione di API interne, SDK, oltre a strumenti e servizi condivisi. Queste esperienze riducono il sovraccarico, in modo che i team di sviluppo possano concentrarsi sulle operazioni eseguite.
Le piattaforme per sviluppatori interne consentono agli sviluppatori di agire come i clienti della vetrina digitale
Le piattaforme per sviluppatori interne offrono funzionalità simili alle vetrine digitali business-to-business. I negozi digitali sono intrinsecamente progettati per aiutare i clienti a self-service. Possono gestire una velocità effettiva maggiore rispetto ai fronti dei negozi tradizionali perché forniscono modi per individuare e soddisfare gli elementi interessanti senza dover parlare con nessuno. Usando questa analogia, gli sviluppatori sono il cliente e la piattaforma per sviluppatori interna offre esperienze self-service simili. Analogamente a un rivenditore, operatori, tecnici della piattaforma e altri ruoli, quindi configurare un catalogo di elementi che gli sviluppatori possono richiedere che siano progettati per supportare protezioni organizzative.
Ad esempio, è possibile pensare a uno sviluppatore che richiede l'accesso a un nuovo strumento come se stesse effettuando un ordine di vetrina digitale. Analogamente a un ordine, una volta inviata la richiesta, lo sviluppatore vuole essere in grado di tenere traccia dello stato di avanzamento e sapere quando è completato. Dietro le quinte, la richiesta deve essere indirizzata automaticamente al provider di evasione corretto per soddisfare la necessità. È possibile considerare uno dei sistemi di integrazione e distribuzione continua (CI/CD) come un provider di evasione, uno strumento GitOps o una piattaforma di applicazioni prescrittiva come secondo e uno strumento di automazione del flusso di lavoro per i processi manuali come terzo. In tutti i casi, lo sviluppatore può self-service elementi da un catalogo ben definito nello stesso modo.
Usare tutto come modello di codice
L'uso dell'infrastruttura come codice (IaC) tramite pipeline di recapito continuo e strumenti GitOps è una parte importante dell'abilitazione self-service. IaC con CD consente di usare Bicep, Terraform, grafici Helm e altri strumenti per creare ed eliminare risorse cloud su richiesta. Poiché la configurazione dell'infrastruttura cloud viene gestita esattamente come il codice in un repository di codice sorgente, è possibile applicare tutti i vantaggi di un repository Git, ad esempio sicurezza e controllabilità.
Il provisioning di strumenti e infrastrutture comuni non è l'unico vantaggio di un approccio IaC. È possibile adattare come modello di codice per altri scenari, tra cui la sicurezza come codice e criteri come codice (tramite strumenti come Criteri di Azure e Open Policy Agent). Seguendo questa tecnica, un file di configurazione, in genere YAML o JSON, viene eseguito il push nel repository, a quel punto, viene attivato un flusso di lavoro che elabora il file. Questi file possono essere un repository di app come dependabot.yml o CODEOWNERS oppure possono essere mantenuti in un repository centrale separato. È anche possibile estenderlo in scenari personalizzati per rendere veramente tutto come codice (EaC) una realtà.
Gli sviluppatori possono fare riferimento a ognuno di questi modelli EaC con un catalogo centrale che supporta le esperienze self-service e incoraggia le procedure consigliate per impostazione predefinita.
Creare modelli corretti e stabilire una governance corretta
Nello sviluppo di software si intende incapsulare, modularità e componibilità durante la progettazione di applicazioni. È consigliabile applicare questa stessa linea di pensiero alla progettazione della piattaforma tramite la creazione di modelli. Ad esempio, è possibile creare e usare un set di modelli IaC riutilizzabili e protetti centralmente come blocchi predefiniti per l'infrastruttura.
Verranno compilati moduli per i nostri [sviluppatori]... quindi, invece di dover scrivere o preoccuparsi di uno dei back-end stessi, tutto ciò che devono fare è preoccuparsi del codice dell'applicazione. - Daniel, Cloud Engineer, Fortune 500 Media Company
Combinare modelli di applicazione, IaC e IaC in una soluzione personalizzata come codice (EaC) che si estende ad altre attività, ad esempio la creazione di un repository di codice sorgente, il seeding del codice di esempio o la configurazione e il codice di esempio per gli strumenti di osservabilità consigliati. Questi modelli di applicazione, EaC e IaC possono quindi essere archiviati o a cui si fa riferimento da una posizione centralizzata protetta, ad esempio un repository, il catalogo in ambienti di distribuzione di Azure (ADE) o Registro Azure Container (ACR) per il cloud nativo.
Quando si iniziano a destra i modelli vengono combinati con la governance automatizzata, l'analisi e la configurazione dei criteri, gli sviluppatori rimangono immediatamente al primo giorno.
I modelli semplificano lo sviluppo con procedure automatizzate e sicure
Usare i modelli di applicazione per eseguire il bootstrap dei percorsi aperti definiti per diverse decisioni e azioni chiave che gli sviluppatori prendono nel corso di un progetto. Avviare i modelli corretti per stabilire procedure di sviluppo sicure, regolate e consentire agli sviluppatori di iniziare rapidamente abilitando l'automazione che fornisce l'accesso agli strumenti necessari, configura pipeline CI/CD, effettua il provisioning dell'infrastruttura e dello stack di applicazioni e configura un repository completo con codice sorgente della lastra caldaia che include gli SDK o i riferimenti necessari alle API.
Se questi modelli di applicazione fanno riferimento ad altri modelli centralizzati (ad esempio, modelli IaC), ognuno di questi singoli blocchi predefiniti diventa modelli appropriati. Questi modelli sono fondamentali per abilitare le esperienze self-service, poiché non solo definiscono gli output, ma anche gli sviluppatori di opzioni disponibili scelgono.
I modelli garantiscono la governance, la sicurezza e l'ottimizzazione dei costi
Tuttavia, i modelli devono eseguire più di un semplice bootstrap di uno sforzo di sviluppo. Devono inoltre stabilire il controllo e la governance tramite criteri e analisi della sicurezza necessari per rimanere corretti nel corso del ciclo di vita del progetto. Come un altro esempio, i modelli possono configurare regole di protezione dei rami che impediscono merge non autorizzati nell'ambiente di produzione. Poiché i modelli acquisiscono procedure consigliate e configurazioni comuni, sono una delle tecniche chiave per ottimizzare i costi tra strumenti, fornitori e team.
Eseguire campagne appropriate per creare comunicazioni bidirezionali
Infine, man mano che aumenta la fiducia nei percorsi pavimentati, è possibile usare i singoli blocchi predefiniti sottostanti assemblati nei modelli di applicazione per spostare le applicazioni esistenti in un percorso pavimentato. Poiché i clienti interni vedranno già il valore dei percorsi pavimentati pilotati, è possibile eseguire una campagna interna get right per creare un dialogo bidirezionale con altri team dell'applicazione. Gli sviluppatori possono imparare a eseguire la migrazione dell'applicazione mentre il team di progettazione della piattaforma apprende contemporaneamente come migliorare la piattaforma.
Creare un grafico personalizzato
Data l'ampiezza delle esperienze che le funzionalità self-service potrebbero coprire, è importante concentrarsi sugli sforzi di investimento e pianificare e definire le priorità in modo che la piattaforma per sviluppatori interna offra valore in modo incrementale. Il percorso di ogni organizzazione nella creazione della piattaforma per sviluppatori interna è diverso e, seguendo una mentalità orientata ai prodotti, è possibile scegliere prima di tutto i luoghi più critici che necessitano di esperienze self-service.