Perfezionare la piattaforma dell'applicazione per lo sviluppo semplificato di applicazioni e la gestione 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 di 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, suddividere i dettagli della piattaforma astratti suddividendo le scelte in convenzioni di denominazione configurabili, ad esempio:

• Categorie di tipi di risorse (calcolo elevato, memoria elevata)
• Categorie di dimensioni delle risorse (ridimensionamento della t-shirt, 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 saranno occasioni in cui i team devono modificare più opzioni sui modelli pubblicati rispetto a quelli disponibili o auspicabili. Ad esempio, una progettazione approvata potrebbe richiedere una configurazione specifica esterna alle impostazioni predefinite del modello supportate. In questa istanza le operazioni o i team di progettazione della piattaforma possono creare una configurazione una tantum e quindi decidere se il modello deve incorporare tali modifiche come predefinita.

È 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 (esempi, 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; è possibile monitorare le modifiche al di fuori del codice dell'infrastruttura e 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 SaaS, PaaS o IaaS. Per altre informazioni su SaaS, PaaS e IaaS, vedere il modulo di training Descrivere i concetti relativi al 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 in servizio Azure Kubernetes (servizio Azure Kubernetes) o tramite App Azure Container (ACA) 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 app Azure Servizio. ACA, Funzioni di Azure e servizio app ridurre la complessità, mentre il servizio Azure Kubernetes offre maggiore flessibilità e controllo. Modelli di app più sperimentali come il progetto di incubazione RADIUS OSS cercano di fornire 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 quando si prevede di valutare quale fine di questa scalabilità è adatta. 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 K8s, ma alcuni si applicano ad altri tipi di risorse:

• Organizzazione: la condivisione di risorse come i cluster all'interno, invece di attraversare, i limiti dell'organizzazione possono migliorare il modo in cui sono allineati alla direzione dell'organizzazione, ai requisiti e alla priorità.
• Tenancy dell'applicazione: le applicazioni possono avere requisiti di isolamento tenancy diversi. Se può coesistere con altre applicazioni, è necessario esaminare la conformità alle normative e la sicurezza delle singole 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 ogni utilizzo delle risorse dell'applicazione, capacità di riserva 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 eventi imprevisti del sito in tempo reale quando la capacità si esaurisce. 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 protezioni, ma l'applicazione di regole di conformità in un modo che non influisce sul tempo per il 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 supportano anche la conformità all'interno di risorse come K8s insieme ai sistemi operativi usati 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. Si consideri quindi l'evoluzione di un criterio come codice (PaC) quando si opera su larga scala. Come parte fondamentale dell'approccio iniziale e mantenere il giusto approccio, PaC offre:

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

Il PaC può contribuire 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.
• Implementazione graduale basata su anello di criteri e correzione sulle risorse esistenti aiutano a ridurre al minimo il raggio di esplosione di un criterio potenzialmente negativo.
• L'attività di correzione include sicurezza incorporata, con controlli come l'arresto dell'attività di correzione se più del 90% delle distribuzioni ha esito negativo.

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, il team di progettazione e operazioni della piattaforma richiede ai dashboard di 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 di questi ruoli potrebbe verificarsi è 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 tramite un framework di osservabilità OpenTelemetry.
• Autorizzazioni: fornire dashboard a livello di team o di applicazione usando qualcosa come Grafana per fornire i dati di cui è stato eseguito il 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.
• Conservazione: 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 iniziali.
• 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 K8s 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 la capacità chiave e le metriche di integrità: monitorare e avvisare il sistema operativo e le risorse condivise (esempi: CPU, memoria, archiviazione) per una raccolta di metriche con una raccolta di metriche simile a Prometheus o Azure Container Insights. È possibile monitorare socket/porte in uso, consumo della larghezza di banda di rete di app chatty e il numero di applicazioni con stato 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 per il cloud). Oltre alla sicurezza delle applicazioni, valutare:

• Gestione della superficie di attacco esterna usando qualcosa come Gestione della superficie di attacco esterna di Microsoft Defender (Defender EASM).
• Servizi di sicurezza di rete: applicazioni e protezione del carico di lavoro cloud da attacchi informatici basati sulla rete con qualcosa di simile a Sicurezza di rete di Azure.
• Analisi della sicurezza intelligente - Uso di 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 supply chain 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 automatica 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. Provider di identità per creare, gestire e gestire le informazioni sull'identità. Il piano deve includere servizi di autenticazione per applicazioni e servizi e che possono 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, ad esempio 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. Si vuole ottenere un inventario delle risorse mappate ai proprietari per un determinato set di metadati. Ad esempio, in Azure è possibile usare etichette del servizio Azure Kubernetes, tag di Azure Resource Manager, insieme a concetti come i progetti in ambienti di distribuzione di Azure per raggruppare le risorse a livelli diversi. Per il funzionamento, i metadati scelti devono includere proprietà obbligatorie (usando qualcosa come 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 i 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, 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 dispone di 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, in portale di Azure sono presenti avvisi sui costi e budget che possono tenere traccia del consumo di risorse in un gruppo e inviare notifiche quando si raggiungono le soglie predefinite.

Decidere quando e dove investire

Se si dispone di più piattaforme applicative, 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 dell'applicazione sono una destinazione mobile. Il sistema ideale cambia man mano che passa il tempo. Si vuole tenere conto di questo concetto e dei piani di migrazione correlati nella progettazione avanzata.
Se vuoi cambiare quello che stai facendo oggi, con quali prodotti, servizi o investimenti sei felice?	Come dice, "se non è rotto, non correggerlo". Non cambiare le cose senza un motivo per farlo. Tuttavia, se si dispone di soluzioni cresciute a casa, valutare se è il momento di passare a un prodotto esistente per risparmiare sulla manutenzione a lungo termine. Ad esempio, se si sta operando una soluzione di monitoraggio personalizzata, rimuovere tale carico dal team operativo ed eseguire la migrazione a un nuovo prodotto gestito?
Dove vengono visualizzati i cambiamenti più eseguiti nel tempo? Una di queste in aree comuni a tutti (o la maggior parte) dei tipi di app dell'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/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? Si ritiene fortemente che una funzionalità unica della piattaforma dell'infrastruttura di app faccia parte del vantaggio competitivo?	Se sono state identificate lacune, prima di eseguire un'operazione personalizzata, prendere in considerazione quali aree sono più probabili investire in e concentrare il pensiero personalizzato 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 dovrà essere mantenuto che nano costi iniziali a lungo termine. Se si sente la necessità urgente di creare una soluzione in un'area sospetta che saranno coperti da fornitori a lungo termine, pianificare il tramonto o il 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, provare a usare una soluzione off-the-shelf. 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.

Contenuto correlato

Progettare una base self-service per sviluppatori