Perfezionare la piattaforma dell'applicazione per semplificare la gestione dello sviluppo e dell'infrastruttura

Una parte importante del miglioramento delle procedure di progettazione della piattaforma dell'organizzazione consiste nel valutare la piattaforma dell'applicazione. Una piattaforma applicativa include tutti gli strumenti e i servizi usati per supportare lo sviluppo, la distribuzione e la gestione delle applicazioni nell'organizzazione.

Semplificare e standardizzare

Gli strumenti di infrastruttura come codice (IaC) e automazione possono essere combinati con i modelli per standardizzare la distribuzione dell'infrastruttura e dell'applicazione. Per ridurre il carico di specifiche della piattaforma per l'utente finale, è possibile astrarre i dettagli della piattaforma suddividendo le scelte in convenzioni di denominazione configurabili, ad esempio:

• Categorie di tipi di risorse (calcolo elevato, memoria elevata)
• Categorie di dimensioni delle risorse (ad esempio, ridimensionamento della t-shirt in piccole, medie e grandi)

I modelli devono rappresentare requisiti generali testati con configurazioni predefinite, in modo che i team di sviluppo possano iniziare immediatamente a fornire parametri minimi e senza dover esaminare le opzioni. Tuttavia, ci sono occasioni in cui i team devono modificare più opzioni sui modelli pubblicati rispetto a quelli disponibili o desiderabili. Ad esempio, una progettazione approvata potrebbe richiedere una configurazione specifica esterna alle impostazioni predefinite del modello supportate. In questo caso, i team di progettazione delle operazioni o della piattaforma possono creare una configurazione una tantum e quindi decidere se il modello deve incorporare tali modifiche come predefinito.

È possibile tenere traccia delle modifiche usando gli strumenti IaC con funzionalità di rilevamento della deriva che possono correggere automaticamente la deriva (GitOps). Esempi di questi strumenti sono Terraform e strumenti IaC nativi del cloud( ad esempio, API cluster, crossplane, operatore del servizio di Azure v2). Al di fuori del rilevamento della deriva dello strumento IaC, sono disponibili strumenti di configurazione cloud in grado di eseguire query per le configurazioni delle risorse, ad esempio Azure Resource Graph. Questi possono servire come due vantaggi; per monitorare le modifiche al di fuori del codice dell'infrastruttura e per verificare la disponibilità di configurazioni predefinite modificate. Per evitare di essere troppo rigidi, è possibile implementare le tolleranze anche nelle distribuzioni con limiti predefiniti. Ad esempio, è possibile usare Criteri di Azure per limitare il numero di nodi Kubernetes che una distribuzione può avere.

Autogestito o gestito?

Nei cloud pubblici è possibile scegliere di usare software come servizio (Saas), piattaforma distribuita come servizio (PaaS) o infrastruttura distribuita come servizio (IaaS). Per altre informazioni su SaaS, PaaS e IaaS, vedere il modulo di training Descrivere i tipi di servizio cloud. I servizi PaaS offrono esperienze di sviluppo semplificate, ma sono più prescrittivi con i modelli di app. In definitiva, c'è un compromesso tra facilità d'uso e controllo che è necessario valutare.

Durante la progettazione della piattaforma, valutare e classificare in ordine di priorità le esigenze del servizio dell'organizzazione. Ad esempio, se si creano app direttamente nel servizio Azure Kubernetes o tramite app contenitore di Azure dipende dai requisiti per il servizio e dalla capacità interna e dal set di competenze. Lo stesso vale per i servizi in stile funzione come Funzioni di Azure o Servizio app di Azure. Le App di contenitori, le Funzioni e il Servizio App riducono la complessità, mentre AKS offre maggiore flessibilità e controllo. Modelli di app più sperimentali come il progetto di incubazione RADIUS OSS cercano di offrire un equilibrio tra i due, ma sono in genere nelle fasi precedenti della maturità rispetto ai servizi cloud con supporto completo e una presenza in formati IaC stabiliti.

I problemi identificati durante la pianificazione dovrebbero aiutarti a valutare quale estremità di questa scala è più adatta a te. Assicurarsi di considerare il proprio set di competenze esistente interno durante la decisione.

Risorse condivise e dedicate

All'interno dell'organizzazione sono disponibili risorse che possono essere condivise da più applicazioni per aumentare l'utilizzo e l'efficacia dei costi. Ogni risorsa condivisa ha un proprio set di considerazioni. Ad esempio, si tratta di considerazioni per la condivisione di cluster Kubernetes, ma alcuni si applicano ad altri tipi di risorse:

• Organizzazione: La condivisione di risorse come i cluster all'interno, anziché oltre i limiti dell'organizzazione, può migliorare il modo in cui si allineano alla direzione dell'organizzazione, ai requisiti e alla priorità.
• Tenancy dell'applicazione: Le applicazioni possono avere requisiti di isolamento tenancy diversi; è necessario esaminare la sicurezza delle singole applicazioni e la conformità alle normative, se può coesistere con altre applicazioni. Ad esempio, in Kubernetes le applicazioni possono usare l'isolamento dello spazio dei nomi. È tuttavia consigliabile prendere in considerazione anche la tenancy dell'applicazione per tipi di ambiente diversi. Ad esempio, è spesso consigliabile evitare di combinare applicazioni di test con applicazioni di produzione negli stessi cluster per evitare impatti imprevisti a causa di errori di configurazione o problemi di sicurezza. In alternativa, è possibile scegliere di testare e ottimizzare i cluster Kubernetes dedicati per tenere traccia di questi problemi prima della distribuzione in un cluster condiviso. Indipendentemente dal fatto che la coerenza nell'approccio sia fondamentale per evitare confusione ed errori.
• Consumo di risorse: Comprendere l'utilizzo delle risorse e la capacità di riserva di ogni applicazione ed eseguire una proiezione per stimare se la condivisione è valida. È anche necessario tenere presente i limiti delle risorse utilizzate (limiti di capacità o sottoscrizione del data center). L'obiettivo è evitare di spostare l'applicazione e le dipendenze a causa di vincoli di risorse in un ambiente condiviso o di avere eventi imprevisti del sito live quando si esaurisce la capacità. Usare limiti delle risorse, test rappresentativi, avvisi di monitoraggio e creazione di report per identificare l'utilizzo delle risorse e proteggersi dalle applicazioni che consumano troppe risorse.
• Ottimizzare le configurazioni condivise: Le risorse condivise, ad esempio i cluster condivisi, richiedono considerazioni e configurazioni aggiuntive. Queste considerazioni includono l'addebito incrociato, l'allocazione delle risorse, la gestione delle autorizzazioni, la proprietà del carico di lavoro, la condivisione dei dati, il coordinamento dell'aggiornamento, il posizionamento del carico di lavoro, la definizione, la gestione e l'iterazione di una configurazione di base, la gestione della capacità e il posizionamento del carico di lavoro. Le risorse condivise offrono vantaggi, ma se le configurazioni standard sono troppo restrittive e non si evolvono, diventano obsolete.

Implementare strategie di governance

La governance è una parte fondamentale dell'abilitazione self-service con linee guida, ma l'applicazione di regole di conformità senza influire sul tempo per generare valore aziendale per le applicazioni è una sfida comune. Esistono due parti della governance:

• Conformità iniziale della distribuzione (a destra): Questa operazione può essere ottenuta con modelli IaC standardizzati resi disponibili tramite cataloghi, con gestione delle autorizzazioni e criteri per garantire la distribuzione solo delle risorse e delle configurazioni consentite.
• Mantenere la conformità (rimanere corretti): Gli strumenti basati su criteri possono impedire o avvisare l'utente quando sono presenti modifiche alle risorse. Oltre all'infrastruttura principale, prendere in considerazione gli strumenti che supportano anche la conformità delle risorse come Kubernetes insieme ai sistemi operativi utilizzati nei contenitori o nelle macchine virtuali. Ad esempio, è possibile applicare una configurazione del sistema operativo bloccata o installare strumenti software di sicurezza come Criteri di gruppo di Windows, SELinux, AppArmor, Criteri di Azure o Kyverno. Se gli sviluppatori hanno accesso solo ai repository IaC, è possibile aggiungere flussi di lavoro di approvazione per esaminare le modifiche proposte e impedire l'accesso diretto ai piani di controllo delle risorse, ad esempio Azure.

La gestione della conformità richiede strumenti per accedere, segnalare e intervenire sui problemi. Ad esempio, Criteri di Azure può essere usato con molti servizi di Azure per il controllo, la creazione di report e la correzione. Include anche diverse modalità, ad esempio Audit, Deny e DeployIfNotExists , a seconda delle esigenze.

Anche se i criteri possono applicare la conformità, possono anche interrompere le applicazioni in modo imprevisto. Pertanto, considerare di evolvere verso una pratica di 'policy as code' (PaC) quando si opera su larga scala. Come parte fondamentale del tuo approccio iniziare bene e proseguire bene, PaC offre:

• Standard gestiti centralmente
• Controllo della versione per le politiche
• Test e convalida automatizzati
• Riduzione del tempo di implementazione
• Distribuzione continua

Il PaC può aiutare a ridurre al minimo il raggio di esplosione di un criterio potenzialmente non valido con funzionalità come:

• Definizioni di criteri archiviate come codice in un repository che viene esaminato e approvato
• Automazione per fornire test e convalida
• Gestione graduale basata su gruppi di criteri e correzione delle risorse esistenti aiuta a ridurre al minimo l'impatto di un criterio potenzialmente non valido.
• L'attività di correzione integra misure di sicurezza, utilizzando controlli come fermare l'attività di correzione se oltre il 90% delle distribuzioni fallisce

Implementare l'osservabilità e la registrazione specifiche del ruolo

Per supportare le applicazioni e l'infrastruttura, è necessario osservare e registrare l'intero stack.

I requisiti variano in base al ruolo. Ad esempio, i team di progettazione e operazioni della piattaforma richiedono dashboard per esaminare l'integrità e la capacità dell'infrastruttura con avvisi appropriati. Gli sviluppatori richiedono metriche, log e tracce dell'applicazione per risolvere i problemi e personalizzare i dashboard che mostrano l'integrità dell'applicazione e dell'infrastruttura. Un problema che uno di questi ruoli potrebbe incontrare è l'overload cognitivo da troppe informazioni o lacune di conoscenza a causa di una mancanza di informazioni utili.

Per risolvere questi problemi, considerare quanto segue:

• Standard: Applicare gli standard di registrazione per semplificare la creazione e il riutilizzo di dashboard standardizzati e semplificare l'elaborazione dell'inserimento attraverso qualcosa come il framework di osservabilità OpenTelemetry.
• Autorizzazioni: Fornire dashboard a livello di team o di applicazione usando qualcosa come Grafana per fornire i dati di rollup per chiunque sia interessato, insieme a una funzionalità per i membri attendibili dei team delle applicazioni per ottenere in modo sicuro l'accesso ai log quando necessario.
• Detenzione: La conservazione dei log e delle metriche può essere costosa e può creare rischi imprevisti o violazioni della conformità. Stabilire le impostazioni predefinite di conservazione e pubblicarle come parte delle linee guida per un avvio corretto.
• Monitorare i limiti delle risorse: I team operativi devono essere in grado di identificare e tenere traccia di eventuali limitazioni per un determinato tipo di risorsa. Queste limitazioni devono essere inserite in modelli O criteri IaC usando strumenti come Criteri di Azure. Le operazioni devono quindi monitorare in modo proattivo usando dashboard in qualcosa come Grafana ed espandere le risorse condivise in cui il ridimensionamento automatizzato non è possibile o abilitato. Ad esempio, monitorare il numero di nodi del cluster Kubernetes per la capacità durante l'onboarding e la modifica delle app nel tempo. È necessario inviare avvisi e queste definizioni devono essere archiviate come codice in modo che possano essere aggiunte a livello di codice alle risorse.
• Identificare le metriche chiave di capacità e integrità: Monitorare e avvisare il sistema operativo e le risorse condivise (ad esempio, CPU, memoria e archiviazione) in caso di scarsità di risorse, raccogliendo le metriche con sistemi come Prometheus o il monitoraggio di Kubernetes in Azure Monitor. È possibile monitorare le porte in uso, il consumo di larghezza di banda di rete delle applicazioni che generano molto traffico e il numero di applicazioni stateful ospitate nel cluster.

Creare una sicurezza con il principio dei privilegi minimi, la gestione unificata della sicurezza e il rilevamento delle minacce

La sicurezza è necessaria a ogni livello, dal codice, dal contenitore, dal cluster e dall'infrastruttura/cloud. Questi sono i passaggi minimi di sicurezza consigliati:

• Seguire il principio dei privilegi minimi.
• Unificare la gestione della sicurezza devOps tra più pipeline.
• Assicurarsi che le informazioni contestuali per identificare e correggere il rischio più critico siano visibili.
• Abilitare il rilevamento e la risposta alle minacce moderne nei carichi di lavoro cloud in fase di esecuzione.

Per risolvere i problemi in questa area, sono necessari strumenti per valutare gli strumenti che funzionano nei sistemi di progettazione e applicazioni, nelle risorse e nei servizi tra cloud e ibridi , ad esempio Microsoft Defender for Cloud. Oltre alla sicurezza delle applicazioni, valutare:

• Gestione della superficie di attacco esterna usando una soluzione simile a Microsoft Defender External Attack Surface Management (Defender EASM).
• Servizi di sicurezza di rete: proteggere le applicazioni e i carichi di lavoro cloud da attacchi informatici basati sulla rete usando qualcosa come Sicurezza di rete di Azure.
• Analisi della sicurezza intelligente usando una soluzione SIEM (Security Information and Event Management) come Microsoft Sentinel.
• Modi per gestire, proteggere, visualizzare e gestire in modo sicuro il patrimonio di dati, ad esempio Microsoft Purview.
• Modi per analizzare il codice per individuare potenziali vulnerabilità di sicurezza, rilevare segreti, esaminare le dipendenze come GitHub Advanced Security e GitHub Advanced Security per Azure DevOps.
• Gestione della catena di approvvigionamento software, in particolare per i contenitori. Ad esempio, applicare il Framework della Catena di Fornitura Sicura dei Contenitori.

I requisiti delle autorizzazioni possono variare in base all'ambiente. Ad esempio, in alcune organizzazioni, i singoli team non sono autorizzati ad accedere alle risorse di produzione e le nuove applicazioni non possono essere distribuite automaticamente fino al completamento delle revisioni. Tuttavia, la distribuzione automatizzata di risorse e app e l'accesso ai cluster per la risoluzione dei problemi potrebbero essere consentiti negli ambienti di sviluppo e test.

La gestione dell'accesso alle identità ai servizi, alle applicazioni, all'infrastruttura su larga scala può risultare complessa. I fornitori di identità creano, mantengono e gestiscono le informazioni sull'identità. Il piano deve includere servizi di autenticazione per applicazioni e servizi e tali servizi devono essere integrati con sistemi di autorizzazione di controllo degli accessi in base al ruolo su larga scala. Ad esempio, è possibile usare Microsoft Entra ID per fornire l'autenticazione e l'autorizzazione su larga scala per i servizi di Azure come il servizio Azure Kubernetes senza dover configurare le autorizzazioni direttamente in ogni singolo cluster.

Le applicazioni potrebbero dover accedere a un'identità per accedere alle risorse cloud, ad esempio l'archiviazione. È necessario esaminare i requisiti e valutare il modo in cui il provider di identità può supportarlo nel modo più sicuro possibile. Ad esempio, all'interno del servizio Azure Kubernetes, le app native del cloud possono usare un'identità del carico di lavoro federata con Microsoft Entra ID per consentire l'autenticazione dei carichi di lavoro in contenitori. Questo approccio consente alle applicazioni di accedere alle risorse cloud senza scambi segreti all'interno del codice dell'applicazione.

Ridurre i costi identificando i proprietari del carico di lavoro e monitorando le risorse

La gestione dei costi è un'altra parte della progettazione della piattaforma. Per gestire correttamente la piattaforma dell'applicazione, è necessario un modo per identificare i proprietari del carico di lavoro. Vuoi ottenere un inventario delle risorse associato ai proprietari per un determinato set di metadati. Ad esempio, all'interno di Azure, è possibile utilizzare le etichette AKS, i tag di Azure Resource Manager insieme a concetti come i progetti negli ambienti di distribuzione di Azure per raggruppare le risorse a diversi livelli. Affinché questo funzioni, i metadati scelti devono includere proprietà obbligatorie (usando qualcosa come i criteri di Azure) durante la distribuzione di carichi di lavoro e risorse. Ciò consente l'allocazione dei costi, il mapping delle risorse della soluzione e l'assegnazione dei proprietari. Prendere in considerazione l'esecuzione di report regolari per tenere traccia delle risorse orfane.

Oltre al rilevamento, potrebbe essere necessario assegnare costi a singoli team delle applicazioni per l'utilizzo delle risorse usando questi stessi metadati con sistemi di gestione dei costi come Microsoft Cost Management. Anche se questo metodo tiene traccia delle risorse di cui è stato effettuato il provisioning dai team dell'applicazione, non copre il costo delle risorse condivise, ad esempio il provider di identità, la registrazione e l'archiviazione delle metriche e l'utilizzo della larghezza di banda di rete. Per le risorse condivise, è possibile dividere equamente i costi operativi per i singoli team o fornire sistemi dedicati (ad esempio, l'archiviazione di registrazione) in cui è presente un consumo non uniforme. Alcuni tipi di risorse condivise potrebbero essere in grado di fornire informazioni dettagliate sull'utilizzo delle risorse. Ad esempio, Kubernetes include strumenti come OpenCost o Kubecost e possono essere utili.

È anche consigliabile cercare gli strumenti di analisi dei costi in cui è possibile esaminare la spesa corrente. Ad esempio, nel portale di Azure sono presenti avvisi sui costi e budget che possono tenere traccia dell'utilizzo delle risorse in un gruppo e inviare notifiche quando si raggiungono le soglie predefinite.

Decidere quando e dove investire

Se si dispone di più di una piattaforma applicativa, può essere difficile decidere quando e dove investire in miglioramenti che risolvono problemi come costi elevati o scarsa osservabilità. Se si inizia da zero, il Centro architetture di Azure offre diversi modelli potenziali da valutare. Ma oltre a questo, ecco alcune domande da considerare quando si inizia a pianificare ciò che si vuole fare:

Domanda	Suggerimenti
Si vuole adattare la piattaforma applicativa esistente, iniziare subito o usare una combinazione di questi approcci?	Anche se sei soddisfatto di ciò che hai ora o stai iniziando fresco, vuoi pensare a come adattarsi al cambiamento nel tempo. Modifiche immediate raramente funzionano. Le piattaforme della tua applicazione sono un bersaglio mobile. Il sistema ideale cambia man mano che passa il tempo. Si vuole includere questo concetto e i piani di migrazione correlati nella progettazione futura.
Se vuoi cambiare quello che stai facendo oggi, con quali prodotti, servizi o investimenti sei felice?	Come si suol dire, "se non è rotto, non aggiustarlo". Non cambiare le cose senza motivo. Tuttavia, se si dispone di soluzioni sviluppate internamente, valuta se è arrivato il momento di passare a un prodotto esistente per risparmiare sui costi di manutenzione a lungo termine. Ad esempio, se stai gestendo una soluzione di monitoraggio interna, vuoi togliere questo peso dal team operativo e passare a un nuovo prodotto gestito?
Dove vedi accadere i maggiori cambiamenti nel tempo? Vi sono alcune di queste in aree comuni a tutti (o alla maggior parte) dei tipi di app della vostra organizzazione?	Le aree con cui l'utente o i clienti interni non sono soddisfatti e non sono probabilmente in grado di cambiare frequentemente sono ottimi punti di partenza. Questi hanno il maggiore ritorno sugli investimenti a lungo termine. Questo può anche aiutare a definire come facilitare la migrazione a una nuova soluzione. Ad esempio, i modelli di app tendono a essere fluidi, ma gli strumenti di analisi dei log tendono ad avere una durata più lunga. È anche possibile concentrarsi sui nuovi progetti e sulle applicazioni da avviare mentre si conferma che la modifica della direzione ha i ritorni desiderati.
Si sta investendo in soluzioni personalizzate in aree con il valore aggiunto più alto? Credi fortemente che una piattaforma infrastrutturale per app con capacità unica faccia parte del tuo vantaggio competitivo?	Se sono state identificate lacune, prima di eseguire un'operazione personalizzata, prendere in considerazione quali aree i fornitori sono più propensi a investire e concentrare le idee personalizzate altrove. Iniziare pensando a se stessi come integratore anziché a un'infrastruttura di app personalizzata o a un provider di modelli di app. Tutto ciò che si costruisce deve essere mantenuto, il che supera di gran lunga i costi iniziali nel lungo termine. Se si avverte l'urgenza di sviluppare una soluzione su misura in un settore che si ritiene sarà coperto a lungo termine dai fornitori, è opportuno pianificare per un'eventuale dismissione o un supporto a lungo termine. I clienti interni saranno in genere felici (se non più) con un prodotto off-the-shelf come uno personalizzato.

Adattare gli investimenti esistenti della piattaforma applicativa può essere un buon modo per iniziare. Quando si apportano aggiornamenti, è consigliabile iniziare con le nuove applicazioni per semplificare le idee pilota prima di qualsiasi tipo di implementazione. Tenere conto di questa modifica tramite i modelli di applicazione e IaC. Investire in soluzioni personalizzate per esigenze specifiche in aree ad alto impatto e di valore elevato. In caso contrario, prova a utilizzare una soluzione pronta all'uso. Come per i sistemi di progettazione, concentrarsi sull'automazione del provisioning, del rilevamento e della distribuzione invece di presupporre un percorso rigido per gestire il cambiamento nel tempo.

Contenuti correlati

• Progettare una base self-service per sviluppatori