Questa architettura illustra un'implementazione di un ambiente Sterling Order Management Software (OMS) in Azure. Questo articolo non illustra in dettaglio come installare Sterling OMS. Per altre informazioni sul processo di installazione, vedere Installazione di Sterling Order Management Software.
I logo Red Hat sono marchi di Red Hat, Inc. Nessuna approvazione è implicita nell'uso di questi marchi. Apache® e Apache ActiveMQ sono marchi o marchi registrati di Apache Software Foundation negli Stati Uniti e/o in altri Paesi. L'uso di questi marchi non implica alcuna approvazione da parte di Apache Software Foundation.
Architettura
Scaricare un file di Visio di questa architettura.
È possibile distribuire un carico di lavoro in modo che si trovi internamente o esternamente. Usare la configurazione più adatta alle proprie esigenze.
Workflow
L'architettura soddisfa i requisiti dell'infrastruttura nei modi seguenti:
- Una piattaforma di hosting di contenitori per distribuire carichi di lavoro a disponibilità elevata tra zone di disponibilità. Documentazione di Azure Red Hat OpenShift
- Un servizio di database completamente gestito funziona come database back-end per il sistema OMS. Sterling OMS supporta attualmente IBM Db2, Oracle Database e PostgreSQL. È consigliabile Database di Azure per PostgreSQL con l'opzione server flessibile.
- Una configurazione scalabile e a disponibilità elevata offre un ambiente per l'esecuzione di un broker di messaggi come IBM MQ conforme all'API Java Message Service (JMS). Il diagramma non include questa configurazione. A seconda dei requisiti, potrebbe trovarsi all'interno del cluster o all'esterno del cluster.
- Gli endpoint privati isolano e aiutano a proteggere il traffico di rete a tutti i servizi connessi.
- Le macchine virtuali (VM) di Azure aggiuntive e facoltative vengono usate per scopi di gestione e sviluppo.
- Le condivisioni di File di Azure Premium e standard forniscono spazio di archiviazione per i file di log e altri dati di configurazione dell'applicazione.
Componenti
Azure Red Hat OpenShift offre cluster OpenShift completamente gestiti e a disponibilità elevata su richiesta. Questi cluster vengono monitorati e gestiti congiuntamente da Microsoft e Red Hat.
Rete virtuale di Azure rappresenta il blocco costitutivo delle reti private in Azure. Rete virtuale per la comunicazione tra nodi, servizi di Azure e esigenze di connettività ibrida.
File di Azure offre condivisioni file completamente gestite nel cloud accessibili tramite i protocolli SMB e NFS. In questa soluzione, File di Azure ospita i dati con stato per i database e i sistemi che si trovano all'interno del cluster.
Azure Bastion è un servizio completamente gestito che offre accesso SSH e RDP semplice e affidabile alle VM senza esposizione tramite indirizzi IP pubblici. Azure Bastion è facoltativo in questa soluzione. È possibile usare Azure Bastion e una subnet per fornire l'accesso con sicurezza avanzata a qualsiasi nodo di lavoro o computer jump box facoltativi.
Database di Azure per PostgreSQL è un servizio di database relazionale completamente gestito basato sul motore di database Postgres open source Database di Azure per PostgreSQL offre prestazioni prevedibili e scalabilità dinamica ed è appropriato per i carichi di lavoro critici per l'azienda. Il modello di distribuzione flessibile del server garantisce controllo granulare e flessibilità sulle funzioni di gestione del database e sulle impostazioni di configurazione.
Azure Virtual Machines offre una soluzione di infrastruttura come servizio (IaaS, Infrastructure as a Service). È possibile usare Macchine virtuali per distribuire risorse di elaborazione scalabili su richiesta. Questa soluzione usa macchine virtuali Linux in Azure per fornire un jump box per la gestione delle risorse e dei servizi basati su OMS.
Alternative
Se si ha connettività di rete nell'ambiente Azure, è possibile eseguire l'installazione da un computer esistente invece di utilizzare una VM Azure Linux..
I servizi seguenti in genere non sono necessari, ma sono alternative efficaci:
- IBM Db2 in Azure è un'alternativa facoltativa al modello di server flessibile di Database di Azure per PostgreSQL. Se si esegue IBM Db2 nelle macchine virtuali, acquisire familiarità con l'uso del software di clustering di Azure Load Balancer e Pacemaker per ottenere una disponibilità elevata per i server di database.
- Azure NetApp Files supporta qualsiasi tipo di carico di lavoro con disponibilità elevata e prestazioni elevate. Azure NetApp Files è ideale per carichi di lavoro sensibili alle operazioni di I/O, ad esempio carichi di lavoro IBM Db2 eseguiti in macchine virtuali di Azure.
- Oracle Database in Azure è un'alternativa facoltativa al modello di server flessibile di Database di Azure per PostgreSQL.
Dettagli dello scenario
IBM Sterling OMS è un sistema di gestione degli ordini che offre una piattaforma completa di evasione degli ordini multicanale. Questo sistema include funzionalità come:
- Visibilità e domanda di inventario in tempo reale.
- Orchestrazione e flussi di lavoro dell'ordine completamente configurabili.
- Logistica inversa per i ritorni multicanale e lo stato dell'ordine restituito.
Una partnership tra Microsoft e il team IBM Sterling OMS garantisce che questa soluzione sia configurata per essere eseguita in modo ottimale in Azure. Questo articolo illustra una progettazione per l'esecuzione di Sterling OMS 10.0 e versioni successive su Azure per i clienti che dispongono del supporto di IBM e di un partner per l'installazione. Per risposte a domande specifiche sui prodotti, contatta il tuo team IBM.
Potenziali casi d'uso
Molti settori e settori usano soluzioni OMS, tra cui:
- Vendita al dettaglio
- E-commerce
- Produzione
Per altri casi d'uso di OMS, vedere IBM Sterling Order Management.
Consigli
Queste linee guida supportano Sterling OMS 10.0 Q3 2022 e versioni successive. Queste versioni offrono le migliori opzioni di integrazione con Azure perché supportano PostgreSQL e la piattaforma contenitore Azure Red Hat OpenShift. Prima di creare una distribuzione personalizzata, usare la Guida introduttiva: Sterling Order Management in Azure per distribuire Sterling OMS. Quando si comprende quindi il funzionamento della distribuzione e della configurazione, è possibile determinare più rapidamente i requisiti di progettazione dell'implementazione.
Microsoft collabora a stretto contatto con IBM e altri partner per garantire che le linee guida, l'architettura e la guida all'avvio rapido offrono un'esperienza ottimale in Azure. Seguono le procedure consigliate descritte in Microsoft Azure Well-Architected Framework. Per assistenza oltre a questa documentazione, contattare il team dell'account IBM.
Prima di procedere con la distribuzione, è necessario rispondere alle domande seguenti sulla progettazione:
- La distribuzione di Sterling OMS è una nuova distribuzione o si esegue la migrazione di una distribuzione esistente in Azure?
- Quale piattaforma di database back-end prevedi di utilizzare? Quali dimensioni saranno necessarie per i dati?
- Quale tipo di broker di messaggi basato su JMS si prevede di usare?
- Dove si prevede di distribuire il sistema di messaggistica:
- Nello stesso cluster OpenShift?
- Esternamente al cluster in una piattaforma diversa o nelle macchine virtuali?
- Si dispone di un registro contenitori esistente e si prevede di continuare a usarlo?
- Qual è il numero e le dimensioni delle macchine virtuali necessarie per i nodi di lavoro?
- Quali sono i requisiti di sicurezza correlati alla crittografia?
- Quali sono i requisiti di accesso e quali considerazioni sull'integrazione del provider di identità (IdP) sono disponibili?
- Quali sono le esigenze di connettività? Quali regole del firewall è necessario connettersi ai servizi interni ed esterni (in uscita) ?
- Qual è la tua strategia per l'alta disponibilità e il ripristino di emergenza?
Sterling OMS
Sterling OMS versione 10.0.2209.0 è stato testato in Azure. Ti consigliamo di utilizzare la versione più recente di Sterling OMS.
Prima di distribuire le risorse di Azure per supportare l'ambiente Sterling OMS, acquisire familiarità con i requisiti seguenti:
- Per i requisiti di sistema di Sterling OMS, vedere Requisiti di sistema.
- Sterling OMS ha una dipendenza da un sistema di database relazionale per la gestione dello stato e dei dati. Per i flussi di lavoro di comunicazione da servizio a servizio è necessario anche un sistema di broker messaggi abilitato per JMS. Sterling OMS supporta diverse opzioni di database e broker di messaggi che è possibile distribuire nell'ambiente. Per ulteriori informazioni, consultare le seguenti risorse:
- Livello di database: installazione e configurazione del software del livello di database in UNIX o Linux
- Broker messaggi JMS: Integrazione con i sistemi JMS
Azure Red Hat OpenShift
Sterling OMS è stato testato con Azure Red Hat OpenShift versione 4.10.15. Prima di distribuire Azure Red Hat OpenShift:
- Decidere su un dominio. Quando si distribuisce Azure Red Hat OpenShift, specificare un nome di dominio che viene aggiunto a tutti i servizi distribuiti nel cluster.
- Determinare la visibilità dell'API e del traffico in ingresso. Decidere come si vuole che l'API del cluster OpenShift (per la gestione) e l'ingresso (per le applicazioni e i servizi distribuiti) siano con connessione Internet. Se si usa la connettività privata per nascondere l'API o l'ingresso, è possibile raggiungere questi endpoint solo da un computer in grado di raggiungere la rete in cui si distribuisce il servizio.
- Calcolare le dimensioni e i conteggi delle macchine virtuali di lavoro e di controllo. In Azure Red Hat OpenShift il conteggio dei controlli è un numero fisso, con una dimensione minima consigliata. I nodi di lavoro, che eseguono carichi di lavoro dell'applicazione come Sterling OMS, vengono ridimensionati separatamente. Quando si distribuisce l'istanza, prendere in considerazione il numero necessario di nodi di lavoro nel cluster, oltre alle dimensioni appropriate di ognuna. Potrebbe essere necessario eseguire alcuni test e convalida per determinare i numeri e le dimensioni corretti. Questi valori dipendono dal numero di agenti nella distribuzione e dal numero di pod per ogni tipo di agente eseguito. Dopo la distribuzione, è possibile modificare questi valori quando è necessario ridimensionare.
Per altre informazioni, vedere Prima di Iniziare per Azure Red Hat OpenShift.
Dimensionamento dell'ambiente
È consigliabile usare le macchine virtuali serie Ds più recenti come nodi di lavoro. Gli esempi sono le serie Dsv3, Dasv4, Dsv4, Dasv5 e Dsv5. Le versioni più recenti di queste macchine virtuali offrono prestazioni ottimali. Quando si distribuiscono più nodi, usare solo macchine virtuali con archiviazione Premium.
Specifiche del database
Poiché Sterling OMS dispone di varie opzioni di database back-end, è importante prima decidere la piattaforma in cui ospitare il database. È quindi possibile prendere decisioni sulle dimensioni della piattaforma. Tenere presenti le linee guida generali seguenti durante questo processo:
-
Database di Azure per PostgreSQL modello di distribuzione server flessibile: a causa della natura delle opzioni di scalabilità e ridondanza, il modello di server flessibile di Database di Azure per PostgreSQL è il metodo preferito per l'hosting dei carichi di lavoro di Sterling OMS in Azure. Quando si distribuisce l'istanza:
- Selezionare il livello di calcolo che corrisponde ai modelli di utilizzo. È consigliabile iniziare con un livello per utilizzo generico e selezionare un numero appropriato di core. Si noti anche che la CPU, la memoria e gli I/O sono associati alla selezione delle dimensioni di calcolo.
- Aggiungere una risorsa di archiviazione appropriata. Tenere presente anche che un aumento dei costi di archiviazione aumenta e non è possibile ridurre lo spazio di archiviazione di cui è stato effettuato il provisioning. Di conseguenza, è importante conoscere le dimensioni iniziali dei dati e la crescita stimata.
- Modificare i parametri del server,
max_connections
ad esempio che influiscono sulla capacità degli agenti di mantenere la connettività al database.
- Db2 nelle macchine virtuali: quando si esegue Db2 in macchine virtuali di Azure, sono necessari diversi fattori complessi, ad esempio prestazioni e disponibilità. Per un articolo dettagliato su una distribuzione Db2 ad alte prestazioni in Azure, vedere Disponibilità elevata di IBM Db2 LUW in macchine virtuali di Azure in Red Hat Enterprise Linux Server. Questo articolo illustra le considerazioni sul ridimensionamento e sulle prestazioni. Illustra anche come distribuire un cluster Db2 a disponibilità elevata che usa Pacemaker.
- Oracle: se si usa attualmente Oracle Database o se si prevede di eseguire la migrazione a Oracle, acquisire familiarità con le risorse seguenti per l'esecuzione di carichi di lavoro Oracle in Azure:
Specifiche della coda di messaggi
Sterling OMS richiede un broker di messaggi basato su JMS. Più comunemente viene usato IBM MQ. Il modo migliore per eseguire un'istanza IBM MQ a disponibilità elevata in Azure consiste nell'usare i grafici Helm IBM MQ per le distribuzioni kubernetes. È possibile distribuire questi grafici nel cluster Azure Red Hat OpenShift esistente in ruoli di lavoro separati per isolare i carichi di lavoro. È anche possibile distribuire e installare IBM MQ manualmente nelle macchine virtuali, se si preferisce.
Come parte della distribuzione standard, è possibile definire le code in fase di distribuzione, riducendo il tempo di configurazione necessario per attivare le istanze. La distribuzione standard crea una sola istanza attiva e due passive del gestore code. Al termine della distribuzione, è possibile usare SSH per connettersi al pod leader corrente e definire il file di associazioni JMS. È quindi possibile usare tale file per creare la mappa di configurazione per la distribuzione di Sterling OMS.
IBM supporta anche altri sistemi di accodamento messaggi basati su JMS, ad esempio Apache ActiveMQ. Per altre informazioni, vedere Code di messaggi in Sterling Order Management Software. Le opzioni di distribuzione variano in base alla soluzione.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.
Azure Red Hat OpenShift offre funzionalità predefinite per la riparazione automatica, la scalabilità e la resilienza per garantire il corretto funzionamento di Azure Red Hat OpenShift e Sterling OMS. Azure Red Hat OpenShift e Sterling OMS sono stati progettati per parti che hanno esito negativo e ripristino. Un requisito fondamentale per il funzionamento della riparazione automatica consiste nel fatto che sono presenti nodi di lavoro sufficienti. Per eseguire il ripristino da un errore di zona all'interno di un'area di Azure, i nodi di controllo e di lavoro devono essere bilanciati tra le zone di disponibilità.
Sterling OMS e Azure Red Hat OpenShift usano l'archiviazione del database per rendere persistente lo stato all'esterno del cluster Kubernetes. I log e altre risorse dell'applicazione vengono salvati in modo permanente in un account di archiviazione. Per assicurarsi che le dipendenze di archiviazione continuino a funzionare durante un errore, è consigliabile usare l'archiviazione con ridondanza della zona. Questo tipo di spazio di archiviazione rimane disponibile quando una zona ha esito negativo. La distribuzione del database deve prendere in considerazione anche le configurazioni a più zone.
Poiché l'errore umano è comune, è consigliabile distribuire Sterling OMS usando il maggior numero possibile di automazione. Per alcuni script di esempio per la configurazione dell'automazione completa end-to-end, vedere Guida introduttiva: Sterling Order Management in Azure su GitHub.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.
Mantenere l'accesso e la visibilità sul ciclo di vita di manutenzione degli asset può essere una delle maggiori opportunità dell'organizzazione di operare in modo efficiente e mantenere il tempo di attività. Per migliorare il comportamento di sicurezza dell'ambiente, è importante usare l'autenticazione sicura e mantenere aggiornate le soluzioni. Usare la crittografia per proteggere tutti i dati che si spostano all'esterno e all'esterno dell'architettura.
Azure offre Sterling OMS usando i modelli di IaaS e piattaforma distribuita come servizio (PaaS). Microsoft crea protezioni di sicurezza nel servizio ai livelli seguenti:
- Data center fisico
- Rete fisica
- Host fisico
- Hypervisor
Valutare attentamente i servizi e le tecnologie selezionati per le aree sopra l'hypervisor, ad esempio la versione più recente con patch di Azure Red Hat OpenShift per una versione principale. Assicurarsi di fornire i controlli di sicurezza appropriati per l'architettura. L'utente è responsabile dell'applicazione di patch e della gestione della sicurezza dei sistemi IaaS. Microsoft assume tale ruolo per i servizi PaaS come Azure Red Hat OpenShift. Anche se è possibile avviare un aggiornamento per Azure Red Hat OpenShift, è completamente gestito da Microsoft e Red Hat. Per altre informazioni sull'applicazione di patch e sull'aggiornamento di Azure Red Hat OpenShift, vedere Aggiornare un cluster Azure Red Hat OpenShift.
Usare i gruppi di sicurezza di rete per filtrare il traffico di rete da e verso le risorse nella propria rete virtuale. Con questi gruppi è possibile definire regole che concedono o negano l'accesso ai servizi Sterling OMS. Alcuni esempi:
- Blocco dell'accesso a tutte le altre parti dell'infrastruttura distribuita, ad esempio porte e servizi specifici usati dal broker di messaggi o dal database back-end.
- Controllare quali posizioni possono avere accesso a Sterling OMS e al cluster OpenShift.
I numeri di porta e gli intervalli che è necessario aprire dipendono da molti fattori. Ecco alcuni aspetti da considerare:
- Porta 443, per la comunicazione da servizio a servizio.
- Porte specifiche del database, ad esempio la porta 5432 per l'opzione server flessibile di Database di Azure per PostgreSQL.
- Porte della coda di messaggi, ad esempio la porta 1414 per IBM MQ.
Tenere presenti anche questi aspetti:
- I nodi del cluster Azure Red Hat OpenShift devono avere accesso a Internet in uscita. Se non è possibile fornire questo accesso, questi nodi richiedono almeno l'accesso agli endpoint di registrazione dei servizi e di Azure Resource Manager.
- IBM fornisce indicazioni per l'implementazione di più applicazioni Sterling OMS che condividono servizi comuni come un database back-end. Tali distribuzioni hanno anche considerazioni sul firewall all'interno dell'applicazione. Per altre informazioni, vedere Apertura delle porte del firewall per la comunicazione all'interno dell'app.
Se è necessario accedere agli altri nodi, non Azure Red Hat OpenShift, è possibile usare Facoltativamente Azure Bastion per accedere alle macchine virtuali. Per motivi di sicurezza, non è consigliabile esporre le macchine virtuali a una rete o a Internet senza configurare i gruppi di sicurezza di rete per controllare l'accesso.
La crittografia lato server di Archiviazione su disco di Azure protegge i dati. SEE consente inoltre di soddisfare gli impegni di sicurezza e conformità dell'organizzazione. Con i dischi gestiti di Azure, SSE crittografa i dati inattivi quando vengono mantenuti nel cloud. Questo comportamento si applica per impostazione predefinita sia ai dischi del sistema operativo che ai dischi dati. OpenShift usa SSE per impostazione predefinita. Azure Red Hat OpenShift supporta anche chiavi di crittografia gestite dal cliente (CMEK) per i dischi del sistema operativo nel cluster.
Autenticazione
È consigliabile configurare OAuth per Azure Red Hat OpenShift. Per maggiori informazioni, consultare la sezione Panoramica dell'autenticazione e dell'autorizzazione nella documentazione di Azure Red Hat OpenShift.
Proteggere l'infrastruttura
Controllare l'accesso alle risorse di Azure da distribuire. Ogni sottoscrizione di Azure ha una relazione di trust con un tenant di Microsoft Entra. Usare il Controllo degli accessi in base al ruolo di Azure per concedere agli utenti interni dell'organizzazione le autorizzazioni corrette per le risorse di Azure. Concedere l'accesso assegnando ruoli di Azure a utenti o gruppi in un determinato ambito. L'ambito può essere una sottoscrizione, un gruppo di risorse o una risorsa. Assicurarsi di controllare tutte le modifiche apportate all'infrastruttura. Per maggiori informazioni sul controllo, consultare la sezione Log attività di Monitoraggio di Azure.
Ottimizzazione costi
L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
Una distribuzione standard di SterlingOMS è costituita dai componenti seguenti: È possibile modificare molte di queste risorse basate su calcolo in base alle proprie esigenze. Ad esempio, è possibile aumentare le prestazioni dei nodi dell'agente IBM MQ per consentire una maggiore velocità effettiva.
Domande frequenti su Azure Red Hat OpenShift
- Tre macchine virtuali di controllo (Standard_D8s_v5)
- Tre macchine virtuali di lavoro (Standard_D8s_v5)
Risorse aggiuntive
- Una rete virtuale (/16), con le subnet seguenti considerate:
- Subnet del nodo di controllo Di Azure Red Hat OpenShift (/24)
- Subnet del nodo di lavoro Di Azure Red Hat OpenShift (/24)
- Subnet dei dati, se necessario (/27)
- Subnet vm aggiuntiva, se necessario (/27)
- Subnet di gestione, se necessario (/30)
- Un'istanza di Database di Azure per PostgreSQL con l'opzione server flessibile
- Un'istanza di Registro Azure Container
- Due account di archiviazione di Azure.
- Tre zone DNS
- Due servizi di bilanciamento del carico
- Una macchina virtuale jump box
- Azure Bastion
Le singole distribuzioni possono differire, ad esempio, se si esegue Db2 in macchine virtuali di Azure o se si distribuisce IBM MQ nell'ambiente Azure Red Hat OpenShift. Per esaminare una stima di esempio, usare il calcolatore dei costi. Le configurazioni variano ed è necessario verificare la configurazione con il team di ridimensionamento IBM prima di finalizzare la distribuzione.
Distribuire lo scenario
Prima di iniziare, esaminare i requisiti per Sterling OMS in Requisiti di sistema. Assicurarsi anche di disporre delle risorse seguenti:
- Accesso a una sottoscrizione di Azure con autorizzazione di Lettore
- Registrazione dell'applicazione o nome dell'entità servizio con autorizzazioni collaboratore e amministratore accesso utenti per la sottoscrizione
- Dominio o sottodominio delegato a una zona DNS di Azure
- Una chiave entitlement IBM Sterling OMS.
- Dimensionamento del cluster IBM consigliato
- Rete virtuale esistente o una nuova rete virtuale creata da IPI, a seconda dei requisiti Per un esempio di creazione di una nuova rete virtuale con due subnet vuote, vedere Esercitazione: Creare un cluster Azure Red Hat OpenShift 4.
- Requisiti di disponibilità elevata e ripristino di emergenza per la distribuzione specifica.
- Un file di configurazione OMEnviroment, omenvironment.yaml, da usare quando si distribuisce Sterling OMS tramite openShift Operator Catalog.
Per una guida dettagliata per l'installazione di Azure Red Hat OpenShift e Sterling OMS in Azure, incluso come risolvere i prerequisiti, vedere Guida introduttiva: Gestione degli ordini Sterling in Azure.
Considerazioni sulla distribuzione
È consigliabile distribuire i carichi di lavoro usando l'infrastruttura come codice (IaC) anziché distribuire manualmente i carichi di lavoro, perché la distribuzione manuale può comportare errori di configurazione. I carichi di lavoro basati su contenitori possono essere sensibili alla configurazione errata, riducendo così la produttività.
Prima di creare l'ambiente, vedere Guida introduttiva: Gestione degli ordini in Sterling in Azure per comprendere i parametri di progettazione. La guida all'avvio rapido non è destinata a una distribuzione pronta per la produzione, ma è possibile usare gli asset della guida per passare a un meccanismo di produzione per la distribuzione.
IBM offre servizi specializzati per facilitare l'installazione. Contattare il team IBM per assistenza.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- David Baumintune | Architetto principale
- Drew Furgiuele | Senior Architect
- Roeland): | Capo architetto
Altri contributori:
- Aneesh AR | Cintura nera Servizi cloud senior
- Vijaya Bashyam | Membro senior del personale tecnico
- James Read | EMEA Principal Solution Architect
- Andy Repton | Cintura nera OpenShift gestita
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Prerequisiti per la distribuzione di contenitori certificati con Sterling Order Management Software Operator
- Sterling Order Management - Guida alle procedure consigliate
- IBM Passport Advantage
- Inizio veloce: distribuire un cluster di Azure Red Hat OpenShift
- Avvio rapido: Creare un server flessibile di Database di Azure per PostgreSQL
- Proteggere l'accesso ad Azure Red Hat OpenShift con Frontdoor di Azure
- Usare il provider di Azure Key Vault per il driver CSI dell'archivio segreti in Azure Red Hat OpenShift
- IBM MQ nei contenitori
- Azure Red Hat OpenShift
- Che cos'è Database di Azure per PostgreSQL?
- Introduzione a Red Hat in Azure
- Uso di Database di Azure per PostgreSQL