Cosa sono i moduli e le architetture distribuibili?

La creazione di un'infrastruttura di applicazioni sicura, conforme e scalabile può essere difficile da configurare e costosa da gestire. Invece di capire come assemblare da soli un'architettura di infrastruttura conforme, è possibile sfruttare i moduli e le architetture distribuibili. I moduli e le architetture distribuibili possono aiutarti a creare un framework su come vengono distribuite le risorse negli account della tua organizzazione. Utilizzando queste configurazioni riutilizzabili, è possibile definire lo standard per la distribuzione una volta e garantire che sia facilmente ripetibile per ogni membro dell'organizzazione.

Ad esempio, pensa a un architetto che sta costruendo un complesso di appartamenti. Questi progetti sono tipicamente eseguiti in modo modulare. Ci sono modelli per appartamenti standard con una camera da letto, due o tre camere da letto. Il costruttore può combinare gli appartamenti standard, ognuno funzionale a modo proprio, in una sistemazione abitativa più grande, più complessa, ma funzionale. IBM ha applicato questa stessa analogia alla distribuzione delle soluzioni sul cloud. Invece di spendere mesi per capire come far lavorare insieme servizi e software, puoi utilizzare i pattern ben strutturati di IBM Cloud. Ogni modello è confezionato in blocchi componibili e automatizzati, noti come moduli e architetture distribuibili.

Cosa è un modulo?

Un modulo è un'unità autonoma di codice di automazione che può essere riutilizzata dagli sviluppatori e condivisa come parte di un sistema più grande. Simile ai pacchetti Node.js o Python, i moduli sono una comodità per gli sviluppatori che stanno gestendo le risorse correlate. Sebbene sia possibile utilizzare i moduli da soli, sono più potenti quando li combini per creare un'architettura distribuibile. I moduli creati da IBM Cloud sono resi disponibili in IBM Terraform modules public GitHub org. Ad esempio, il moduloRed Hat® OpenShift® VPC su IBM Cloud installa e configura un cluster Red Hat OpenShift su IBM Cloud.

Cos' è un'architettura distribuibile?

Un'architettura distribuibile è l'automazione cloud per la distribuzione di un pattern architetturale comune che combina una o più risorse cloud. È progettato per fornire una distribuzione semplificata da parte degli utenti, scalabilità e modularità. Un'architettura distribuibile incorpora uno o più moduli. Le architetture distribuibili sono codificate in Terraform, che configuri con variabili di input per ottenere il comportamento desiderato. Per creare un'architettura distribuibile più complessa, è possibile impilare le architetture distribuibili tra loro senza modificare il codice di Terraform.

Un'architettura distribuibile, che contiene — distribuibile che contiene

Un esempio di architettura distribuibile è la Cloud automation per Secrets Manager. Questa architettura distribuibile prevede un'istanza di IBM Cloud Secrets Manager come soluzione modulare. È possibile utilizzare questa architettura per gestire in modo sicuro i segreti con il proprio account IBM Cloud. L'automazione del cloud per Secrets Manager ha un ambito di applicazione limitato. Viene distribuita solo un'istanza di Secrets Manager, anche se l'architettura distribuibile può creare facoltativamente un anello di chiavi e una chiave IBM Key Protect per crittografare i dati, se non ne esiste una.

Le architetture distribuibili possono avere una portata più ampia, come ad es VPC landing zone. VPC landing zone dispone di diversi cloud privati virtuali in uno schema di rete hub-and-spoke collegato da un gateway di transito. Include un certo numero di servizi di supporto utilizzati per il monitoraggio e la sicurezza dei carichi di lavoro in esecuzione sui VPC.

Le architetture distribuibili create e gestite dagli esperti in IBM Cloud sono rese disponibili nel catalogoIBM Cloud. Se scegli di creare la tua propria versione di tali architetture distribuibili o di crearne una da zero, puoi eseguire l'onboarding della tua architettura distribuibile in un catalogo privato e condividere la tua soluzione pronta per la distribuzione con la tua organizzazione tramite il catalogo.

Cosa significa impilare architetture distribuibili?

Per un caso d'uso più complesso, è possibile impilare le architetture per formare una soluzione completa, end-to-end, per l'implementazione di un'applicazione o di un'infrastruttura complessa. A differenza dei singoli moduli o architetture implementabili, che forniscono funzionalità specifiche, lo stacking combina più architetture implementabili per formare una soluzione completa che può essere facilmente implementata e gestita. Così come i moduli possono essere combinati per creare un'architettura implementabile, le architetture implementabili possono essere impilate per creare una soluzione più ampia. L'impilamento prevede il collegamento delle architetture tra loro per creare un'architettura complessa e distribuibile. Questo collegamento si ottiene specificando i riferimenti negli input di ciascuna architettura implementabile, utilizzando una notazione di riferimento. Non è necessario essere esperti di Terraform o avere competenze di codifica di Terraform per impilare le architetture e distribuirle.

A titolo di esempio, si consideri l'automazione del cloud per Secrets Manager. Questa architettura distribuibile include il modulo Secrets Manager, che crea un'istanza Secrets Manager. Se si ha bisogno solo di un'istanza di Secrets Manager, l'architettura distribuibile è una scelta adeguata. Tuttavia, la gestione sicura dei segreti è solo una parte del mantenimento della sicurezza nel cloud. Che ne dite di eseguire scansioni di conformità in modo da conoscere sempre la postura delle vostre risorse? O di ricevere notifiche per eventi critici nel vostro account IBM Cloud? La fondazione Cloud per la sicurezza e l'osservabilità sfrutta l'intera gamma di servizi di sicurezza di IBM Cloud. È stato creato combinando l'automazione cloud per Secrets Manager con architetture implementabili che forniscono altri IBM Cloud servizi, Event Notifications. Tale architettura implementabile fornisce una soluzione di sicurezza più completa che Secrets Manager non può fornire da sola.

Impilare le architetture implementabili per costruire una soluzione end-to-end

È possibile impilare architetture distribuibili in un progetto IBM Cloud e pubblicarle insieme in un catalogo senza molti passaggi di convalida aggiuntivi. Oppure, è possibile impilare le architetture man mano che si inserisce una soluzione in un catalogo privato. Da lì, è possibile condividerlo con altri per risparmiare loro il tempo di ricostruirlo da soli.

Questa complessa soluzione trae gran parte delle sue garanzie di costo, conformità, supporto e qualità dalle architetture implementabili incluse. Tuttavia, questa soluzione complessa ha una versione, una descrizione e un diagramma di architettura unici. Se viene effettuato un aggiornamento a un'architettura distribuibile che è impilata con altre in un catalogo, l'intera soluzione deve essere aggiornata dall'onboarder per utilizzare l'ultima versione dell'architettura distribuibile di quel componente. L'aggiornamento dell'intera soluzione a una nuova versione consente di garantire che l'ultimo aggiornamento di una singola architettura funzioni correttamente all'interno della soluzione più ampia.

Tuttavia, ogni architettura distribuibile ha stati di configurazione indipendenti, che consentono di distribuire, aggiornare o disinstallare ciascuna architettura in modo indipendente. Ad esempio, sapete già che le la fondazione Cloud per la sicurezza e l'osservabilità comprendono, tra le altre, l'automazione del Cloud per l'architettura distribuibile Secrets Manager. Se l'automazione Cloud per Secrets Manager viene aggiornata, è necessario aggiornare La fondazione Cloud per la sicurezza e l'osservabilità per utilizzare l'ultima versione di Secrets Manager. Tuttavia, ogni architettura inclusa nelle la fondazione Cloud per la sicurezza e l'osservabilità non ha bisogno di essere reimpiegata dall'utente che consuma quella soluzione. Quando l'utente aggiorna il proprio progetto per utilizzare l'ultima versione, solo Secrets Manager deve essere distribuito nuovamente.

Aggiornamento di un'architettura distribuibile all'interno di una soluzione più ampia

Cosa comprende un'architettura distribuibile?

Un'architettura distribuibile potrebbe includere variazioni, avere dipendenze o essere impilata insieme per creare soluzioni più complesse.

Varianti

Una variazione è un tipo di architettura distribuibile che applica diverse funzionalità o complessità a un'architettura distribuibile esistente. Ad esempio, potrebbe esserci una variazione di avvio rapido per la tua architettura distribuibile che ha funzionalità di base per una distribuzione semplice e a basso costo da testare internamente. E, si potrebbe avere una variazione standard che è un po 'più complesso che è pronto per l'uso in produzione.

Architetture richieste

Un'architettura distribuibile può contenere input che richiedono gli output di altre architetture distribuibili per essere distribuiti con successo. Questa relazione tra un'architettura distribuibile e un'altra architettura che richiede è comunemente chiamata dipendenza. È possibile soddisfare le dipendenze in due modi: impilando le architetture distribuibili o inserendo un'architettura distribuibile in un catalogo privato ed estendendola per includere altre architetture.

distribuibile*

Architetture opzionali

Le architetture distribuibili sono progettate per essere flessibili, in modo da poter facilmente impilare le architetture per creare una soluzione più completa. Tuttavia, un'architettura distribuibile generalmente utile potrebbe non includere le opzioni specifiche necessarie per soddisfare un caso d'uso complesso. Ad esempio, quale database va bene per la vostra applicazione Java? Si ha bisogno di notifiche di eventi, di una coda di messaggi o di qualche altro servizio opzionale non incluso di default? Le architetture implementabili opzionali possono essere impilate insieme alle architetture implementabili necessarie per risolvere questo problema di personalizzazione per gli utenti.

Architetture intercambiabili

Sia che un'architettura sia necessaria per soddisfare una dipendenza, sia che sia inclusa come estensione opzionale di un'architettura, gli utenti potrebbero richiedere maggiore flessibilità. Potreste sapere che la vostra applicazione Java funziona con un database opzionale, ma quale database richiedono i vostri utenti? Specificando le architetture intercambiabili, gli utenti possono personalizzare la soluzione end-to-end per soddisfare le loro esigenze specifiche. Dopo aver impilato insieme le architetture opzionali o necessarie, è possibile raggruppare le architetture come scambiabili tra loro. L'utente che consuma può quindi selezionare l'architettura richiesta che desidera utilizzare per soddisfare una dipendenza, oppure selezionare un'architettura opzionale se desidera estendere il proprio caso d'uso.

Le architetture opzionali e sostituibili possono essere aggiunte man mano che si inserisce un'architettura distribuibile in un catalogo privato. Attualmente, l'impilamento delle architetture distribuibili in un progetto non supporta le architetture opzionali o intercambiabili.

Cosa sono i progetti e come funzionano con le architetture distribuibili?

Un progetto IBM Cloud è uno strumento di gestione progettato per organizzare e fornire visibilità in un progetto reale presente nella tua organizzazione. Un progetto gestisce tutte le istanze configurate di un'architettura distribuibile e le risorse correlate ai motivi del mondo reale per cui vengono distribuite. I progetti archiviano le istanze dell'architettura distribuibili con versione e organizzano le istanze e risorse in ambienti per migliorare la visibilità del ciclo di vita di sviluppo. Un ambiente è un gruppo di istanze di architettura distribuibili correlate che condividono valori per distribuzioni più semplici. Ad esempio, sviluppo, test o prod.

I progetti sono responsabili di garantire che solo le architetture distribuibili approvate possano essere distribuite. Inoltre, possono essere utili per garantire che le architetture e le risorse create siano aggiornate, conformi e che la deviazione non si verifichi nel tempo. Ad esempio, è possibile che si disponga di un progetto dell'applicazione di gestione account. Questo progetto è progettato per gestire tutte le risorse che l'applicazione di gestione account deve distribuire in un ambiente di sviluppo, test o produzione. Ogni ambiente ha le stesse variabili, ad esempio una regione o un prefisso, ma ha valori differenti. Quando un'architettura distribuibile viene assegnata a un ambiente tramite un progetto, i relativi valori di input possono automaticamente fare riferimento a qualsiasi delle proprietà dell'ambiente che hanno lo stesso nome. Mentre i IBM Cloud progetti sono facili da creare e aggiornare, non sono templatizzati o ottimizzati per la replica o la condivisione.

Come faccio a sapere quale soluzione creare?

Se si pianifica di creare la propria soluzione, è necessario prendere in considerazione l'ambito, l'accoppiamento, se è distribuibile e lo scopo della propria soluzione. Per una guida e i casi di utilizzo che ti aiutano a decidere cosa intendi creare, vedi Pianificazione e ricerca per la progettazione di un'architettura e Come decido quale tipo di componente creare.

La seguente tabella fornisce una panoramica di alto livello del motivo per cui si desidera creare i diversi componenti.

Comprensione dei casi d'uso delle distribuzioni automatizzate
Scopo	Metodo consigliato	Perché?
Creazione di una libreria di componenti di automazione condivisibili	Creare un modulo	I moduli forniscono un'automazione curata e riutilizzabile per velocizzare il processo per coloro che stanno creando e configurando le architetture distribuibili.
Garantire che l'ambiente cloud della vostra azienda sia sicuro e conforme	Creare un'architettura distribuibile	Le architetture distribuibili vengono impacchettate in modo da poter definire una distribuzione sicura e conforme una sola volta e garantire che tutti i membri della propria organizzazione stiano ripetendo la distribuzione nello stesso modo.
Progettare le proprie soluzioni	Impilare insieme le architetture distribuibili	Combinando le architetture, è possibile creare una soluzione end-to-end più complessa per la propria azienda.