Procedure ottimali per la creazione di architetture distribuibili

Un' architettura distribuibile è un'unità modulare e autonoma di automazione cloud che combina una o più risorse cloud per fornire un pattern architetturale comune. Consente l'implementazione, la scalabilità e la modularità semplificate, consentendo agli utenti di eseguire facilmente il provisioning e gestire le risorse dell'infrastruttura.

Questa guida illustra le procedure ottimali per la creazione di architetture distribuibili ben progettate e manutenibili, scritte in Terraform. Concentrarsi su attributi chiave come ambito, componibilità, consumabilità e controlli di qualità aiuta a garantire soluzioni solide e affidabili. La sezione finale di questa guida fornisce riferimenti a strumenti e modelli che consentono di implementare queste pratiche.

Queste procedure ottimali si applicano alla creazione di architetture distribuibili con Terraform. Per ulteriori informazioni, vedi Creazione di un'architettura distribuibile.

Guarda e impara

Preferite vederlo in azione? Guardate il seguente video per saperne di più sulle architetture distribuibili.

Trascrizione video

Un'architettura distribuibile è un modello di architettura con automazione per la distribuzione di infrastrutture e software sul cloud. Consente alle organizzazioni di garantire la coerenza nel modo in cui l'infrastruttura e il software vengono distribuiti e configurati. L'architettura e la sicurezza sono garantite, riducendo il supporto complessivo e aumentando l'affidabilità nel lungo periodo.

Questo modello prende vita con l'automazione che istanzia l'architettura distribuibile. L'automazione di IBM Cloud è guidata da Terraform per l'automazione dell'Infrastruttura-as-a-service e da Ansible per la configurazione del software.

La comprensione dei costi è fondamentale: è possibile stimare i costi prima dell'implementazione e tenere traccia delle variazioni di spesa man mano che si aggiorna o si personalizza l'architettura. E ricordate: non vi viene addebitato nulla fino al momento dell'impiego.

I criteri di sicurezza e organizzativi sono fondamentali per le implementazioni aziendali. Ecco perché le architetture implementabili sono sottoposte a controlli e scansioni preliminari per aderire a una serie di requisiti di policy, che possono aiutare la vostra organizzazione a rimanere sicura. Le implementazioni standardizzate semplificano anche la raccolta di prove per gli audit.

Le architetture distribuibili forniscono informazioni su come ottenere assistenza e sui permessi necessari per distribuire l'architettura.

Infine, è possibile condividere le architetture distribuibili da un catalogo privato con altri account dell'organizzazione. Inoltre, il catalogo può limitare gli utenti a versioni specifiche di un'architettura distribuibile. Questo garantisce coerenza e standardizzazione per tutti.

I modelli di architettura sono creati da esperti del settore. Le architetture cross-domain sono costruite collegando tra loro le architetture per creare un'architettura distribuibile più complessa.

Potete creare le vostre architetture distribuibili o risparmiare tempo personalizzando le architetture già pronte di IBM Cloud dal catalogo di IBM Cloud o dal registro comunitario.

un'architettura distribuibile è definita da un manifesto come codice, che descrive l'architettura, la posizione del codice, i permessi e i costi, il supporto, la descrizione, l'icona e altri dettagli. È definito con JSON e si trova nella radice del repo.

È possibile inserire o modificare un'architettura distribuibile nella console ed esportare il manifest. È possibile creare un'architettura distribuibile per la prima volta da uno snapshot git di rilascio. Utilizzare l'url.tgz della release come sorgente.

Quindi, modificare i dettagli della voce di catalogo per l'architettura distribuibile, come l'icona e il nome. Si possono aggiungere dipendenze e architetture opzionali che funzionano bene con la propria, ma non sono necessarie.

È inoltre possibile gestire le richieste di conformità per l'architettura distribuibile. Queste affermazioni vengono verificate quando si convalida l'architettura distribuibile nel catalogo prima di pubblicarla.

Infine, dopo aver inserito una versione dell'architettura distribuibile, è possibile esportare il file manifest del catalogo e salvarlo nel repository di origine. L'uso della console è in genere l'approccio migliore per l'onboarding di una nuova architettura distribuibile, in quanto è possibile esportare facilmente il manifest del catalogo e modificarlo in seguito, se necessario. In questo modo, non è necessario creare il file manifest del catalogo da zero.

Nel catalogo IBM Cloud, aprire la scheda Architetture distribuibili per trovare le architetture supportate da IBM.

Le architetture distribuibili nel nostro registro comunitario possono cambiare frequentemente o essere interrotte con breve preavviso, ma sono comunque un buon punto di partenza da utilizzare e personalizzare.

Consideriamo l'architettura distribuibile VPC landing zone, disponibile nel catalogo IBM Cloud. Si tratta di un'architettura distribuibile generalmente utile, poiché è necessario un VPC se si intende eseguire un carico di lavoro nel cloud.

VPC landing zone è progettato per essere conforme al profilo IBM Cloud Framework for Financial Services. Separa i carichi di lavoro di gestione dai carichi di lavoro dei lavoratori, utilizza la gestione delle chiavi per crittografare l'archiviazione degli oggetti nel cloud e utilizza endpoint privati per le comunicazioni. È possibile utilizzarlo così com'è o personalizzarlo per soddisfare le esigenze della propria zona di atterraggio.

Per un'architettura distribuibile più complessa, considerare la fondazione Cloud per la sicurezza e l'osservabilità. L'architettura distribuibile è stata realizzata collegando insieme più architetture dal catalogo IBM Cloud. Con esso è possibile sfruttare l'intera gamma di servizi di sicurezza di IBM Cloud. È personalizzabile, quindi potete scegliere di includere solo i servizi di cui avete bisogno e di escludere quelli che non vi servono.

Ora che sapete dove trovare le architetture distribuibili, come potete distribuirle e mantenerle tra gli account? Utilizzate un progetto IBM Cloud.

Nel progetto, si configurano le variabili di input per l'architettura distribuibile. È possibile monitorare i costi, la deriva delle risorse, le scansioni di conformità e l'aggiornamento all'ultima versione di un'architettura distribuibile quando è disponibile nel catalogo. Un progetto si trova in genere in un account hub e distribuisce le risorse su vari account spoke, noti anche come account di destinazione.

Consultate i nostri documenti per saperne di più sull'esecuzione di carichi di lavoro sicuri in IBM Cloud. Oppure, consulta il catalogo dell' IBM Cloud per scoprire quali architetture implementabili potrebbero funzionare per la tua azienda.

Principi della progettazione

Ambito, componibilità e consumabilità sono i tre principi di progettazione principali che è necessario considerare quando si crea un'architettura distribuibile.

Nella fase di pianificazione e ricerca, è necessario valutare l'ecosistema corrente di offerte e valutare il caso di utilizzo e i requisiti di business. Utilizzare Well - Architected Framework e Architecture Design Framework per pianificare e progettare i componenti necessari per l'architettura.

Ambito

Un ambito ben definito per l'architettura distribuibile è fondamentale, poiché dovrebbe essere sufficientemente completo da includere tutte le risorse necessarie, ma sufficientemente mirato per evitare inutili complessità.

Una best practice consiste nell'includere risorse infrastrutturali che vengono tipicamente distribuite insieme come unità, richiedono accesso e autorizzazioni simili e hanno lo stesso ciclo di vita. Ad esempio, consideriamo l'VPC landing zone. Questa architettura distribuibile dispone di un ambito ben definito che comprende le seguenti risorse dell'infrastruttura:

Risorse nella zona VPC landingn DA
Risorsa Descrizione
VPC Crea una topologia VPC sicura
Infrastruttura di rete Include sottoreti, gateway pubblici, ACL, gateway di transito e gruppi di sicurezza
Rete edge Isola il traffico verso l'internet pubblico
Monitoraggio e registrazione Integra i Flow Log per l'osservabilità e il controllo del traffico VPC

Queste risorse vengono in genere distribuite insieme come un'unità, richiedono autorizzazioni amministrative di rete simili e hanno lo stesso ciclo di vita, il che significa che:

  • Vengono creati insieme, ad esempio quando viene eseguito il provisioning di un nuovo VPC con le relative sottoreti, gateway pubblici e gruppi di sicurezza associati.
  • Vengono aggiornati insieme, ad esempio quando viene effettuata una modifica alla configurazione di rete del VPC, che richiede aggiornamenti alle sottoreti, ai gateway pubblici e ai gruppi di sicurezza.
  • Vengono eliminati insieme, ad esempio quando un VPC viene disattivato e tutte le sue risorse associate, incluse le sottoreti, i gateway pubblici e i gruppi di sicurezza, vengono rimossi.

Componibilità

Un principio fondamentale di un'architettura implementabile è la componibilità, che consente di creare un'architettura implementabile più ampia sovrapponendo più architetture implementabili. Questo approccio modulare consente la massima flessibilità e riutilizzabilità delle risorse di automazione.

Per ottenere la componibilità, un'architettura distribuibile deve essere progettata per:

  • Massimizza la quantità di informazioni emerse attraverso i valori di output, mantenendo però semplici i tipi di output. Questa pratica consente all'automazione dell'architettura distribuibile di essere riutilizzata in una vasta gamma di scenari e la rende un elemento costitutivo versatile per varie soluzioni automatizzate.

  • Consenti riferimenti facoltativi alle risorse distribuite esistenti, come ad esempio i gruppi di risorse, le istanze IBM® Key Protect for IBM Cloud® o Hyper Protect Crypto Services e le istanze IBM Cloud Secrets Manager, tra le altre. Gli utenti possono quindi configurare le istanze esistenti o eseguire la distribuzione in gruppi di risorse esistenti, aumentando la versatilità dell'automazione. L' architettura distribuibileSecrets Manager è un ottimo esempio di questo principio in azione. Consentendo agli utenti di riutilizzare le istanze, i gruppi di risorse e la chiave di codifica KMS Secrets Manager esistenti, questa automazione fornisce un alto grado di flessibilità e adattabilità. Ad esempio, puoi:

    • Configura un'istanza Secrets Manager esistente passando il suo ID e crea gruppi di segreti nell'istanza esistente.
    • Integra con un sistema di gestione delle chiavi esistente come Key Protect o Hyper Protect Crypto Services.
    • Distribuire in un gruppo di risorse esistente o crearne uno nuovo con convenzioni di denominazione personalizzabili.

In alternativa, questa architettura distribuibile consente anche la creazione di una nuova istanza Secrets Manager, un nuovo gruppo di risorse e altre risorse da zero, fornendo una soluzione autonoma.

Grazie alla componibilità, un'architettura distribuibile può essere facilmente integrata in un'architettura di soluzione più complessa sovrapponendola ad altre architetture distribuibili. Ad esempio, il modello Retrieval Augmented Generation dimostra come più architetture implementabili, compresa l'architettura implementabile Secrets Manager, possano essere combinate per costruire una soluzione complessa. Le architetture distribuibili, progettate tenendo conto della componibilità, costituiscono la base per queste soluzioni complesse.

Quando le architetture distribuibili sono impilate insieme, ogni architettura distribuibile membro mantiene il proprio stato di configurazione indipendente, consentendo la distribuzione, l'aggiornamento o la disinstallazione individuale. Questo approccio modulare consente di ricavare garanzie di costo, conformità, supporto e qualità dalle architetture implementabili incluse, mentre la soluzione complessiva rimane una versione unica con le proprie descrizioni e architetture di riferimento. Per ulteriori informazioni, consultare Cosa significa impilare architetture distribuibili?

Possibilità di utilizzo

Un'architettura distribuibile deve essere progettata tenendo presente la consumabilità, rendendo più semplice per gli utenti comprendere e distribuire. A tale scopo, l'architettura distribuibile deve fornire una documentazione completa che includa quanto segue:

Prerequisiti
Dipendenze software e requisiti dell'infrastruttura necessari per la distribuzione.
Descrizioni dettagliate delle variabili di input e dei valori di output
Include lo scopo, il tipo di dati e i valori predefiniti.
Autorizzazioni minime necessarie
Autorizzazioni richieste per eseguire l'automazione dell'architettura distribuibile.
Diagrammi e mappe dell'architettura
Rappresentazioni visive dei componenti e delle relazioni dell'architettura distribuibile.
Configurazione semplificata
Facile da implementare e gestire.
Requisiti di risorse ridotti
Ottimizza l'architettura distribuibile per ridurre i requisiti hardware e di risorse, riducendo i requisiti di CPU e memoria, rendendoli più economici ed efficienti.
Distribuzione semplificata
Più veloce e più facile da iniziare.

Un altro aspetto per garantire che l'architettura distribuibile sia facilmente utilizzabile consiste nel fornire più varianti, inclusa una variazione di avvio rapido. È necessario fornire una versione di avvio rapido dell'architettura distribuibile, che è più economica e più veloce da eseguire. Ad esempio, la variazione QuickStart dell'architettura distribuibile Red Hat OpenShift Container Platform on VPC landing zone crea un ambiente VPC (Virtual Private Cloud) completamente personalizzabile in una singola regione, fornendo un singolo cluster Red Hat OpenShift in un VPC sicuro per i workload. Questa variazione di avvio rapido è progettata per scopi di dimostrazione e sviluppo e costa meno di $400 al mese per l'esecuzione.

Al contrario, la versione standard dell'architettura distribuibile Red Hat OpenShift Container Platform on VPC landing zone, basata sull'architettura di riferimento IBM Cloud Framework for Financial Services, crea un carico di lavoro sicuro e conforme Red Hat OpenShift Container Platform su una rete VPC (Virtual Private Cloud), ma costa più di $4.000 al mese per l'esecuzione. Inoltre, include funzioni avanzate quali il servizio VPC di gestione, il servizio VPC del carico di lavoro, l'isolamento del VPC di gestione e del VPC del carico di lavoro e le decisioni dell'architettura di sicurezza della rete avanzata.

Variabili di input

rendere più semplice per gli utenti configurare le variabili di input dell'architettura distribuibile utilizzando le seguenti procedure ottimali:

Esponi solo argomenti modificati comunemente
Esporre solo le variabili che la maggior parte degli utenti dovrà modificare, evitando architetture implementabili con un numero elevato di variabili di input che potrebbero sopraffare gli utenti. Per gli utenti avanzati, considerare la possibilità di fornire un singolo campo di input JSON per un'ulteriore personalizzazione. Come esempio, l'architettura distribuibile della zona di destinazione VPC presenta un singolo campo denominato override_json_string che fornisce il controllo completo agli utenti avanzati sulla topologia distribuita. Per ulteriori informazioni, vedi la guida alla distribuzione della zona di destinazione VPC.
Utilizza denominazione chiara e descrittiva per le risorse esistenti
Quando si fa riferimento a risorse esistenti, utilizzare nomi che indicano chiaramente a cosa si riferiscono, ad esempio existing_cluster_name invece di cluster_name, per evitare ambiguità.
Preferisci nomi a ID
Quando si fa riferimento a risorse esistenti, utilizzare i nomi invece degli ID per una migliore fruibilità da parte dell'utente.
Evita acronimi
Invece di utilizzare gli acronimi, utilizzare i nomi dei prodotti completi per rendere più semplice per le persone che non hanno familiarità con i prodotti o i servizi comprendere a cosa si riferiscono. Ad esempio, secrets_manager invece di sm o key_management invece di kms.
Utilizza funzionalità di digitazione avanzate
Per abilitare il servizio Progetti IBM Cloud a eseguire il rendering dei widget di input appropriati per le variabili, il che rende più semplice per gli utenti configurare i valori. Ad esempio:
  • Regione VPC: un elenco a discesa di tutte le regioni VPC disponibili su IBM Cloud.
  • Chiave SSH VPC: un campo di input sicuro per la gestione delle chiavi SSH.
  • Cluster: un elenco a discesa dei cluster disponibili su IBM Cloud.

Per ulteriori informazioni, vedi Modifica locale dei valori manifest del catalogo.

Seguendo queste linee guida, l'architettura distribuibile può essere resa più utilizzabile, consentendo agli utenti di comprenderla e distribuirla rapidamente.

Qualità

Per garantire che l'architettura distribuibile sia affidabile e coerente, è essenziale implementare e automatizzare i controlli di qualità. Questi controlli devono coprire vari aspetti dell'architettura distribuibile, inclusa la qualità del codice, la convalida della configurazione, il test e l'integrazione continua.

qualità codice

Sfrutta il linting e la formattazione del codice. Applica stili di codifica e formattazione coerenti per semplificare la lettura e la manutenzione del codice. Rileva errori e avvertenze nel codice per evitare problemi durante la distribuzione. Considerate di andare oltre il solo codice di Terraform, ma di incorporare tutti gli strumenti rilevanti per tutte le risorse della vostra architettura distribuibile, come script Bash, script Python, file YAML e JSON e Golang.

Esempi:

  • terraform_fmt per formattare il codice Terraform.
  • go-fmt per formattare il codice Go.
  • black per formattare il codice Python.
  • isort per ordinare le importazioni Python.
  • flake8 per verificare la presenza di errori e avvertenze nel codice Python.
  • shellcheck per verificare la presenza di errori e avvertenze negli script della shell.
  • golangci-lint per verificare la presenza di errori e avvertenze nel codice Go.

Convalida della configurazione

Utilizzare la convalida statica per verificare che la sintassi e la configurazione dell'architettura distribuibile siano corrette e congruenti. Convalidare la configurazione dell'architettura distribuibile per evitare errori durante la distribuzione. Anche in questo caso, si consideri la possibilità di andare oltre il codice di Terraform e di incorporare tutti gli strumenti rilevanti per tutte le risorse della propria architettura distribuibile, come gli script Bash, gli script Python, i file YAML e JSON e Golang.

Esempi:

  • terraform_validate per convalidare la configurazione Terraform.
  • checkov per controllare i problemi di sicurezza e conformità nel codice Terraform.
  • tflint per verificare la presenza di errori e avvertenze.
  • detect-secrets per rilevare i segreti nel codice.
  • hadolint per controllare i file Docker per errori e avvertenze.
  • helmlint per controllare i grafici Helm per errori e avvertenze.

Esecuzione di test

Quando si tratta di testare il codice dell'infrastruttura, non c'è un puro test di unità nel modo in cui potresti pensarlo per il codice dell'applicazione. Invece, la strategia di test implica la distribuzione dell'infrastruttura in un ambiente reale, la convalida del suo funzionamento e l'annullamento della sua distribuzione.

Suite di test di convalida automatizzata

Il consiglio è di avere una suite di test automatizzata di base che copra i seguenti fondamentali:

Test di distribuzione
Verificare che il codice dell'infrastruttura possa essere distribuito correttamente in un ambiente reale. Creare tutte le risorse necessarie, come macchine virtuali, database e reti. Questi test aiutano a garantire che il codice dell'infrastruttura sia corretto e che possa essere applicato correttamente a un ambiente reale. Si consiglia di variare i parametri di input dell'architettura distribuibile in questi test per assicurare un'ampia copertura allineata all'uso comune.
Prove di distruzione
Verificare che il codice dell'infrastruttura possa essere correttamente annullato o distrutto, rimuovendo tutte le risorse create. Questi test garantiscono che il codice dell'infrastruttura possa essere rimosso in modo sicuro da un ambiente reale, senza lasciare indietro le risorse orfane o causare conseguenze indesiderate.
Test di idempotenza
Verificare che il codice dell'infrastruttura possa essere riapplicato più volte senza causare modifiche o errori indesiderati. In altre parole, il codice dovrebbe produrre lo stesso risultato indipendentemente dal numero di volte in cui viene applicato. Questi test sono critici in ambienti come IBM Cloud, dove la piattaforma controlla periodicamente la presenza di modifiche per rilevare la deviazione tra l'infrastruttura distribuita e l'origine della verità, che è il codice di automazione. I test di idempotency aiutano a garantire che il codice dell'infrastruttura possa gestire distribuzioni o aggiornamenti ripetuti senza causare problemi. Questi test consentono inoltre di garantire che le funzioni di rilevamento della deviazione possano identificare e correggere in modo accurato eventuali discrepanze tra lo stato previsto e lo stato effettivo dell'infrastruttura. Per ulteriori informazioni, vedi Gestione della deviazione.
Test di aggiornamento versione
Verificare che il codice dell'infrastruttura possa essere aggiornato correttamente da una versione all'altra, senza causare errori o modifiche indesiderate. Questi test garantiscono che il codice dell'infrastruttura possa essere aggiornato in modo sicuro, senza interrompere o distruggere le risorse esistenti o causare conseguenze indesiderate.

Scenari di test avanzati

Gli scenari di test avanzati includono scenari quali:

Distribuzione dell'architettura distribuibile più volte nello stesso account
Verifica che il codice dell'infrastruttura possa gestire più distribuzioni nello stesso account, senza causare conflitti di nomi di risorse o altri problemi.
Distribuzione dell'architettura distribuibile con un profilo attendibile
Verifica che il codice dell'infrastruttura possa essere distribuito con un profilo attendibile Cloud Identity and Access Management. Per ulteriori informazioni, consultare Definizione di un metodo di autenticazione.

Includendo questi test nella tua suite di test automatizzata, puoi garantire che il codice della tua infrastruttura sia affidabile, solido e sicuro da distribuire alla produzione.

Integrazione continua

Per garantire l'affidabilità, la congruenza e la manutenibilità dell'architettura distribuibile, si consiglia un approccio shift - left, in cui i test e i controlli di qualità sono integrati all'inizio del ciclo di sviluppo. Questo approccio consente di individuare tempestivamente errori e difetti, riducendo la probabilità di problemi a valle e migliorando la qualità complessiva.

Nell'ambito di questo approccio, si raccomandano i seguenti controlli di qualità:

Controllo qualità lato client
Git commit hooks lato client deve essere utilizzato per eseguire i controlli sulla macchina sviluppatore prima di eseguire il commit del codice. Ciò include i controlli per gli standard di codifica, gli errori di sintassi e i dati sensibili. Strumenti come Pre - commit possono essere utilizzati per automatizzare questo processo.
Pratiche CI
Devono essere seguite le migliori pratiche per l'integrazione continua (IC). Le pratiche generali per qualsiasi prodotto di progettazione software si applicano allo sviluppo di architetture distribuibili, inclusi:
  • Lavorare con piccole richieste di pull (PR) mirate per facilitare revisioni tempestive e ridurre i conflitti di unione.
  • Integrazione delle modifiche al codice nel ramo principale su base regolare per prevenire i rami delle funzioni di lunga durata e ridurre la complessità di unione.
  • Implementazione di test automatizzati e revisioni del codice per garantire la coerenza e la qualità del codice.
  • Convalida continua della configurazione e sintassi dell'architettura distribuibile per garantire la correttezza e la coerenza.
Pipeline IC
È necessario configurare una pipeline CI per automatizzare queste pratiche, garantendo che ogni modifica del codice nell'architettura distribuibile venga sistematicamente verificata e convalidata. Questa pipeline garantisce che l'architettura distribuibile funzioni correttamente e in modo congruente e che eventuali errori o difetti vengano rilevati in anticipo.

Strumenti e risorse

Viene fornita una serie completa di strumenti e risorse per facilitare la creazione di architetture distribuibili di alta qualità. I moduli Terraform curati sono un elemento chiave, con oltre 60 + moduli riutilizzabili, sicuri e convalidati che coprono una vasta gamma di esigenze infrastrutturali. Questi moduli sono disponibili su GitHub e sono supportati e mantenuti aggiornati tramite un modello di contributo open source e supportati dai contributi dell'organizzazione di sviluppo IBM Cloud.

Oltre ai moduli Terraform curati, vengono forniti anche best practice e modelli per aiutare con l'architettura distribuibile e la creazione di moduli. Questo include la documentazione, un modello di repository di architettura distribuibileGitHub allineato con le procedure ottimali per la creazione e le linee guida per la creazione di moduli che si applicano sia ai moduli Terraform che alle architetture distribuibili basate su Terraform. Queste risorse possono essere utilizzate per iniziare rapidamente a utilizzare una nuova architettura distribuibile.

Viene inoltre fornito un framework di test automatizzato, basato sulla libreria Terratest, con test scritti in Go. Il framework copre i test di idempotenza, i test di aggiornamento e GitHub, e utilizza le funzioni di aiuto ai test della libreria https://github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper. Per ulteriori informazioni, vedi la nostra documentazione di test.

Per supportare lo sviluppo di pipeline CI, sono disponibili una gamma di strumenti e risorse, tra cui:

  • GitHub Azioniriutilizzabili.
  • Generazione automatizzata della documentazione.
  • Onboarding automatizzato per IBM Cloud.
  • Aggiornamenti delle dipendenze automatizzati utilizzando il rinnovo personalizzato.
  • Configurazione degli strumenti di configurazione dello sviluppo locale e degli hook di pre - commit, consulta la nostra Documentazione sull'impostazione dello sviluppo locale per ulteriori informazioni.

Questi strumenti e risorse sono progettati per accelerare e facilitare la creazione di architetture distribuibili di alta qualità.

Passi successivi

Ora che comprendi le procedure ottimali per la creazione di un'architettura distribuibile, puoi utilizzare gli strumenti e le risorse ed esaminare la seguente documentazione IBM Cloud prima di sviluppare il tuo codice di automazione. Questo ti aiuta a garantire di aver pianificato e progettato a fondo la tua soluzione da condividere in IBM Cloud: