Das Ziel dieses Artikels besteht darin, technische Details zur Implementierung von Murex-Workloads in Azure bereitzustellen.
Aufbau
Murex MX.3-Workloads können mit Datenbanken wie Oracle, Sybase oder SQL Server ausgeführt werden. Diese Architektur konzentriert sich auf die Details zur Implementierung der MX.3-Anwendung mithilfe von Oracle als Datenbank.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
- Greifen Sie auf die MX.3-Präsentationsebenenkomponente der in Azure gehosteten Logikschicht zu, indem Sie eine Azure ExpressRoute- oder VPN-Verbindung zwischen Azure und Ihrer lokalen Umgebung verwenden. Die Verbindung wird mithilfe von Azure Firewall geschützt.
- Greifen Sie auf die Präsentationsebene mit VDI-Lösungen (Virtual Desktop Infrastructure) wie Citrix zu. Sie können auch direkt über eine Desktopanwendung auf die Ebene zugreifen oder die Webschnittstelle verwenden, die von der MX.3-Anwendung bereitgestellt wird.
- Die Anwendungsebene enthält die Präsentationsebene, die Geschäftsebene, die Orchestrierungsebene und die Rasterebene. Sie greift auf die Oracle-Datenbank zu, um Daten zu speichern und abzurufen.
- Die Präsentationsschicht greift auf Komponenten der Geschäftsebene, der Orchestrierungsebene und der Rasterebene zu, um den Geschäftsprozess abzuschließen.
- Die Oracle-Datenbank verwendet Azure SSD Premium oder Azure NetApp Files als Speichermechanismus für schnelleren Zugriff.
- Auf die Anwendungsebene greift auf Azure Key Vault-Dienste zu, um Verschlüsselungsschlüssel und Geheime sicher zu speichern.
- Administratorbenutzer greifen sicher auf die Murex MX.3-Server zu, indem Sie den Azure Bastion-Dienst verwenden.
Komponenten
- Azure Bastion: Azure Bastion ist ein vollständig verwalteter Dienst, der sichereren und nahtloseren Zugriff auf VMs über RDP (Remotedesktopprotokoll) und SSH (Secure Shell-Protokoll) ohne jegliche Verfügbarkeit über öffentliche IP-Adressen bietet.
- Azure Monitor: Mit Azure Monitor können Sie Telemetriedaten aus Ihren Azure- und lokalen Umgebungen sammeln, analysieren und auf sie reagieren.
- Azure Firewall: Azure Firewall ist ein cloudnativer, intelligenter Netzwerkfirewall-Sicherheitsdienst, der erstklassigen Bedrohungsschutz für Ihre cloudbasierten, in Azure ausgeführten Workloads bietet.
- Azure ExpressRoute: Mithilfe von Azure ExpressRoute können Sie private Verbindungen zwischen Azure-Rechenzentren und Infrastrukturen erstellen, die sich an einem lokalen Standort oder in einer Colocationumgebung befinden.
- Azure Files: Vollständig verwaltete Dateifreigaben in der Cloud, auf die über die SMB- und NFS-Branchenstandardprotokolle zugegriffen werden kann.
- Azure Disk Storage: Azure Disk Storage bietet hochleistungsfähigen, permanenten Blockspeicher für unternehmenskritische Anwendungen.
- Azure Site Recovery: Bereitstellen von Replikations-, Failover- und Wiederherstellungsprozessen über Site Recovery, damit Ihre Anwendungen während geplanter und ungeplanter Ausfälle weiterhin ausgeführt werden.
- Azure NetApp Files: Azure NetApp Files ist ein leistungsstarker Dateispeicherdienst auf Unternehmensniveau.
- Azure Key Vault: Verwenden von Azure Key Vault, um Geheimnisse sicher zu speichern und darauf zuzugreifen.
- Azure VPN Gateway: VPN Gateway sendet verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem lokalen Standort über das öffentliche Internet.
- Azure Policy: Verwenden von Azure Policy zum Erstellen, Zuweisen und Verwalten von Richtliniendefinitionen in Ihrer Azure-Umgebung.
- Azure Backup: Azure Backup ist eine kostengünstige, sichere Sicherungslösung mit einem Klick, die basierend auf Ihren Sicherungsspeicheranforderungen skalierbar ist.
Szenariodetails
Murex ist ein weltweit führender Softwareanbieter von Lösungen für Handel, Risikomanagement, Abwicklung und Post-Trade für Kapitalmärkte. Viele Banken stellen die dritte Generation der MX.3-Plattform von Murex bereit, um Risiken zu managen, die Transformation zu beschleunigen und die Einhaltung von Vorschriften zu vereinfachen – und das alles bei gleichzeitiger Steigerung der Erträge. Die Murex-Plattform ermöglicht es Kunden, bessere Kontrolle über ihre Abläufe zu erlangen, die Effizienz zu steigern und die Betriebskosten zu senken.
MX.3 ist eine Client-/Serveranwendung, die auf einer dreistufigen Architekturstruktur mit drei Ebenen basiert. Banken nutzen MX.3 für ihre geschäftlichen Anforderungen, etwa Vertrieb und Handel, Risikomanagement sowie Sicherheitsleistungen und Investitionen.
Microsoft Azure bietet Murex-Kunden eine schnelle und einfache Möglichkeit zum Erstellen und Skalieren einer MX.3-Infrastruktur. Azure ermöglicht eine sichere, zuverlässige und effiziente Umgebung für Produktions-, Entwicklungs- und Testsysteme. Die Infrastrukturkosten, die für den Betrieb der MX.3-Umgebung erforderlich sind, werden erheblich reduziert.
Um detaillierte Informationen zu den verschiedenen Schichten und Ebenen der Murex MX.3 Anwendungs-, Compute- und Speicheranforderungen zu erhalten, wenden Sie sich an das technische Team von Murex.
Linux ist eine Marke des entsprechenden Unternehmens. Die Verwendung dieser Marke impliziert keine Empfehlung.
Mögliche Anwendungsfälle
Diese Lösung eignet sich ideal für die Finanzbranche. Im Folgenden werden einige mögliche Anwendungsfälle aufgeführt.
- Bessere Kontrolle des Betriebs, höhere Effizienz und geringere Infrastrukturkosten.
- Schaffen einer sicheren, zuverlässigen und effizienten Umgebung für Produktion und Entwicklung.
Überlegungen
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Murex MX.3 ist eine komplexe Workload mit hohen Arbeitsspeicher-, geringen Latenz- und hohen Verfügbarkeitsanforderungen. In diesem Abschnitt werden einige der technischen Überlegungen beschrieben, die beim Implementieren einer Murex MX.3-Workload in Azure analysiert werden müssen.
- MX.3 verwendet eine Client-/Serverarchitektur. Bei der Implementierung in Azure müssen Sie eine IaaS-Architektur (Infrastructure-as-a-Service) anwenden. Analysieren Sie sorgfältig alle nativen Azure-Dienste, um sicherzustellen, dass sie die technischen Anforderungen für Murex erfüllen.
- Sie können die MX.3-Lösung vollständig in Azure bereitstellen oder eine Teilmenge von Azure-Komponenten mithilfe eines Hybridmodells bereitstellen. In diesem Artikel werden keine Hybridmodelle behandelt. Sie sollten die Architektur und die technischen Anforderungen sorgfältig analysieren, bevor Sie ein hybrides Bereitstellungsmodell verwenden. Hybride Bereitstellungsmodelle für MX.3 unterliegen der technischen Überprüfung durch das Murex-Team.
- Sie können direkt vom Benutzerdesktop oder über VDI-Lösungen wie Citrix auf die MX.3-Clientebene zugreifen.
- Die Murex MX.3-Workloads in verschiedenen Ebenen erfordern bestimmte Arten von Computeressourcen, um die funktionalen und technischen Anforderungen zu erfüllen. Unter Murex MX.3-Architektur finden Sie Informationen zu den Compute-, Arbeitsspeicher- und Speicheranforderungen für eine MX.3-Workload.
- Die MX.3-Anwendung erfordert externe (Internet) und interne (lokale) Konnektivität, um Aufgaben auszuführen. Die Azure-Architektur für die MX.3-Anwendung muss ein sicheres Konnektivitätsmodell unterstützen, um in interne und externe Dienste integriert zu werden. Verwenden Sie ein Azure-Site-to-Site-VPN oder ExpressRoute (empfohlen), um eine Verbindung mit lokalen Diensten herzustellen.
- Für die Sicherung können Sie native Azure-Sicherungsdienste in Kombination mit Azure-Speicher verwenden. Verwenden Sie diese Dienste für tägliche, wöchentliche oder monatliche Sicherungen der Anwendungs-VMs oder anderer Sicherungs-/Archivierungsanforderungen, die für die Logikschicht spezifisch sind. Verwenden Sie für Datenbankanforderungen datenbanknative Replikations- oder Sicherungstools.
- Um Hochverfügbarkeit und Resilienz der Murex-Lösungen in Azure zu erhalten, sollten Sie jede Ebene der Logikschicht in mindestens zwei VMs ausführen. Sie können eine Azure-Verfügbarkeitsgruppenkonfiguration verwenden, um Hochverfügbarkeit über mehrere VMs hinweg zu erreichen. Sie können Azure Virtual Machine Scale Sets auch für Redundanz und verbesserte Leistung von Anwendungen verwenden, die auf mehrere Instanzen verteilt sind. Sie können Hochverfügbarkeit für die Orchestrierungsebene erreichen, indem das Hosting in mehreren Instanzen erfolgt und die Instanzen mithilfe benutzerdefinierter Skripts aufgerufen werden. Sie können Datenbankfeatures für Hochverfügbarkeit wie Oracle Data Guard oder SQL Server Always On verwenden, um die Hochverfügbarkeitsanforderungen zu erreichen.
- Um die erforderlichen Leistungsmetriken für Murex-Workloads zu erreichen, sollten Sie das MX.3-Anwendungsverzeichnis und die -Datenbanken in Azure Managed Disks mit SSD Premium speichern. Für hohe Eingabe-/Ausgabevorgänge pro Sekunde und niedrige Latenzanforderungen können Sie Azure NetApp Files als Speicheroption verwenden. Sie können eine Näherungsplatzierungsgruppe und Netzwerkbeschleunigung in Azure verwenden, um einen hohen Netzwerkdurchsatz über Ebenen hinweg zu erreichen.
- Sie können Azure Monitor verwenden, um die Azure-Infrastrukturkomponenten zu überwachen. Sie können den zugehörigen Warnungsmechanismus verwenden, um präventive Aktionen wie automatische Skalierung oder Benachrichtigungen zu ermöglichen.
- Verwenden Sie Dienste wie Azure Key Vault, um die Sicherheitsanforderungen der MX.3-Anwendung in Azure zu berücksichtigen, indem Schlüssel und Zertifikate gespeichert werden. Sie können virtuelle Azure-Netzwerke, Netzwerksicherheitsgruppen (NSGs) und Anwendungssicherheitsgruppen verwenden, um den Zugriff zwischen verschiedenen Ebenen und Schichten zu steuern. Sie können Azure Firewall, DDoS-Schutz und Azure Application Gateway- oder Web Application Firewall-Dienste verwenden, um die Front-End-Ebene abhängig von den Sicherheitsanforderungen zu schützen.
- Sie können Infrastrukturautomatisierung erreichen, indem Sie IaC-Dienste (Infrastructure-as-Code) wie Azure Resource Manager-Vorlagen oder Terraform-Skripts verwenden. Sie können Murex DevOps-Tools verwenden, um die DevOps-Anforderungen auf Anwendungsebene zu berücksichtigen.
Zuverlässigkeit
Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.
- Alle Ebenen der Logikschicht werden in mindestens zwei VMs oder VM-Skalierungsgruppen innerhalb jeder Verfügbarkeitszone gehostet, um hohe Ausfallsicherheit zu unterstützen.
- Die Geschäfts- und Rasterebenen der Logikschicht werden in VM-Skalierungsgruppen gehostet. Diese Skalierungsgruppen unterstützen automatische Skalierung der VMs basierend auf vorkonfigurierten Bedingungen.
- Für die Orchestrierungsebenen können die Server bei Bedarf auf verschiedene VMs verteilt werden. Wenn Probleme mit einer der VMs auftreten, können Sie Automatisierungsskripts (Resource Manager-Vorlage oder Terraform) und Warnungsbenachrichtigungen konfigurieren, um automatisch weitere VMs bereitzustellen.
- Für die Persistenzebene können Sie Hochverfügbarkeit der Oracle-Datenbank über eine Oracle Data Guard-Lösung erreichen. In dieser Lösung werden mehrere VMs in Verfügbarkeitszonen ausgeführt, wobei aktive Replikation zwischen ihnen konfiguriert ist.
- Für die Logikschicht werden redundante VMs für jede der Ebenen gehostet. Wenn ein Notfall in einer der VMs vorliegt, stellt Azure sicher, dass eine andere Instanz der VM automatisch bereitgestellt wird, um die erforderliche Notfallwiederherstellungsebene zu unterstützen.
- Für Notfallwiederherstellung sollten Sie die Notfallwiederherstellungswebsite in einer anderen Azure-Region ausführen. Sie können Aktiv/Aktiv- oder Aktiv/Passiv-Notfallwiederherstellungskonfigurationen basierend auf den Anforderungen an Recovery Point Objective und Recovery Time Objective verwenden. Sie können Site Recovery verwenden, um den Notfallwiederherstellungsprozess und native Datenbankreplikation zu automatisieren. Sie können auch Sicherungstools verwenden, um die erforderliche Ebene von RPO-Metriken zu erreichen.
- Für die Persistenzebene sollten Sie Oracle DataGuard mit maximaler Leistung (synchroner Commit) einrichten, um Auswirkungen auf MX.3 zu vermeiden. Oracle-Datenbankinstanzen zwischen Verfügbarkeitszonen stellen sicher, dass die Anwendung mit minimalem Datenverlust wiederhergestellt wird.
- Wenn ein Regionsfehler auftritt, können Sie Automatisierungsskripts (Resource Manager oder Terraform) oder Site Recovery-Dienste verwenden, um die Umgebung schnell in einer gekoppelten Azure-Region bereitzustellen.
- Abhängig von den RPO-Anforderungen können Sie native Oracle-Sicherungslösungen wie Recovery Manager (RMAN) verwenden, um die Datenbank regelmäßig zu sichern und wiederherzustellen.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.
- Sie können Azure Firewall verwenden, um das virtuelle MX.3-Netzwerk zu schützen. Diese Lösung hilft bezüglich Threat Intelligence und beim Steuern des eingehenden Datenverkehrs in der Präsentationsebene und des ausgehenden Datenverkehrs aus der Logikschicht in das Internet.
- NSGs im Anwendungssubnetz und im Datenbanksubnetz einer MX.3-Anwendung ermöglichen die Steuerung des Netzwerkdatenverkehrs, der die Datenbank-, Geschäfts- und Orchestrierungsebene durchläuft.
- Sie können den Azure-Key Vault-Dienst verwenden, um vertrauliche Informationen und Zertifikate sicher zu speichern.
Kostenoptimierung
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.
- Sie können Infrastrukturressourcen für VDI-Lösungen wie Citrix in Azure hosten. Auf der Clientebene werden VDI-Lösungen verwendet, um auf die Logikschicht zuzugreifen und die Gesamtkosten und die Leistung der Lösung zu optimieren.
- Verwenden Sie für Compute Azure-Reservierungen und den Azure-Sparplan für Compute, und erhalten Sie erhebliche Einsparungen im Vergleich mit nutzungsbasierten Preisen.
Sie können den Azure-Preisrechner verwenden, um Ihre Kosten zu ermitteln.
Erstklassige Betriebsprozesse
Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.
- Sie können Azure Monitor verwenden, um die Plattform zu überwachen, und Azure Monitor-Protokolle zum Überwachen der Anwendung nutzen. Sie können jedoch auch Ihr eigenes benutzerdefiniertes Tool konfigurieren, um die Plattform und die Anwendung bei Bedarf zu überwachen.
- Sie können Ressourcentagging verwenden, um Ressourcen zu bezeichnen und die Überwachung von Warnungen und Benachrichtigungen zu erweitern, indem Sie die effektive Integration eines IT-Service-Managementsystems verwenden.
- Sie können IaC-Tools wie Resource Manager-Vorlagen oder Terraform-Skripts verwenden, um den Infrastrukturbereitstellungsprozess zu automatisieren. Sie können Azure DevOps-Tools verwenden, um IaC-Tools in die Murex DevOps-Toolkette zu integrieren.
- Sie können Azure-Richtlinien verwenden, um die Sicherheits- oder Complianceanforderungen zu kodifizieren und die Azure-Umgebung für Überwachungs- und Complianceanforderungen zu validieren.
Sie können die VMs in der Orchestrierungsebene der Logikschicht mithilfe von benutzerdefinierten Skripts bereitstellen.
Effiziente Leistung
Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.
- Sie können hohen Speicherdurchsatz für einen Datenbankserver erreichen, indem Sie Azure NetApp Files Ultra-Speicher verwenden, um die Oracle-Datenbank zu hosten. Sie können jedoch auch eine Azure-VM mit einem verwalteten Datenträger für einen niedrigeren Speicherdurchsatz wie SSD Premium-Speicher verwenden.
- Verwenden Sie für Szenarien mit geringer Latenz Azure-Näherungsplatzierungsgruppen zwischen der Logikschicht und der Persistenzebene.
- Für bessere Leistung und Zuverlässigkeit sollten Sie ExpressRoute verwenden, um eine Verbindung mit einem lokalen System herzustellen.
- Sie können Azure Files verwenden, um Dateien zu speichern, die von der MX.3-Logikschicht verwendet werden, z. B. Konfigurationsdateien, Protokolldateien und Binärdateien.
Hub-and-Spoke-Netzwerkmodell
Ein wichtiger Aspekt bei der Implementierung von MX.3-Workloads in Azure ist die Definition der Zielzonenarchitektur. Diese Architektur enthält das Abonnement, die Ressourcengruppe, die virtuelle Netzwerkisolation und die Konnektivität zwischen verschiedenen Komponenten der Lösung. Dieser Abschnitt behandelt die Zielzonenarchitektur für die Implementierung einer MX.3-Workload in Azure, basierend auf dem Microsoft Cloud Adoption Framework.
Die folgende Abbildung zeigt eine allgemeine Ansicht einer Zielzone, die die Hub-Spoke-Netzwerktopologie in Azure verwendet.
- Die Verwendung dieses Modells ermöglicht eine starke Isolierung der Spoke-Netzwerke, die zur Ausführung verschiedener Umgebungen verwendet werden. Das Modell sieht auch sicheren Steuerungszugriff und eine gemeinsame Dienstebene im Hubnetzwerk vor.
- Sie können das gleiche Hub-Spoke-Modell in einer anderen Region verwenden, da es sich um eine Lösung für mehrere Regionen handelt. Sie können einen Hub für jede Region erstellen, gefolgt von verschiedenen Spokes für Nichtproduktions- und Produktionsumgebungen.
- Sie können diese Zielzone für ein einzelnes Abonnement oder mehrere Abonnements verwenden, je nachdem, wie Ihre Organisation Ihre Anwendungen kategorisiert.
Jede Komponente in der Zielzone wird unten erläutert.
Hub: Der Hub ist ein virtuelles Netzwerk, das als zentraler Ort für die Verwaltung der externen Konnektivität zum lokalen Netzwerk eines MX.3-Kunden und der von mehreren Workloads genutzten Hostingdienste dient.
Spoke: Die Spokes sind virtuelle Netzwerke, die die Azure-Workloads von MX.3 hosten und über Peering virtueller Netzwerke mit dem zentralen Hub verbunden sind.
Peering virtueller Netzwerke: Virtuelle Hub-and-Spoke-Netzwerke werden über Peering virtueller Netzwerke verbunden, das Verbindungen mit geringer Latenz zwischen den virtuellen Netzwerken unterstützt.
Gateway: Ein Gateway wird verwendet, um Datenverkehr vom lokalen Netzwerk eines MX.3-Clients an das virtuelle Azure-Netzwerk zu senden. Sie können den Datenverkehr verschlüsseln, bevor er gesendet wird.
Gatewaysubnetz: Das Gateway, das Datenverkehr aus einer lokalen Umgebung an Azure sendet, verwendet ein bestimmtes Subnetz, das als Gatewaysubnetz bezeichnet wird. Das Gatewaysubnetz ist Teil des IP-Adressbereichs für das virtuelle Netzwerk, den Sie beim Konfigurieren Ihres virtuellen Netzwerks angeben. Es enthält die IP-Adressen, die von den Ressourcen und Diensten des Gateways für virtuelle Netzwerke verwendet werden.
Azure Jumpbox-VM: Jumpbox verbindet Azure-VMs der Anwendungs- und Persistenzebenen über eine dynamische IP-Adresse. Jumpbox verhindert, dass alle Anwendungs- und Datenbank-VMs öffentlich verfügbar gemacht werden. Diese Verbindung ist Ihr Einstiegspunkt, um aus dem lokalen Netzwerk eine RDP-Verbindung herzustellen.
Azure Firewall: Sie sollten die gesamte ein- und ausgehende Konnektivität zwischen MX.3-VMs und dem Internet über Azure Firewall weiterleiten. Typische Beispiele für eine solche Konnektivität sind Zeitsynchronisierung und Virenschutzdefinitionsupdates.
Azure Bastion: Durch die Verwendung von Azure Bastion können Sie die Anwendungs- und Datenbank-VMs über das Azure-Portal sicher verbinden. Stellen Sie den Azure Bastion-Host innerhalb des virtuellen Hubnetzwerks bereit, und greifen Sie dann in den virtuellen Spoke-Netzwerken mit Peering auf die VMs zu. Diese Komponente ist optional, und Sie können sie bei Bedarf verwenden.
Azure Bastion-Subnetz: Azure Bastion erfordert ein dediziertes Subnetz: AzureBastionSubnet. Sie müssen dieses Subnetz im Hub erstellen und den Bastion-Host in diesem Subnetz bereitstellen.
Azure-Verwaltungssubnetz: Azure Jumpbox muss sich im Verwaltungssubnetz befinden. Jumpbox enthält VMs, die Verwaltungs- und Überwachungsfunktionen für die Anwendungs- und Datenbank-VMs im virtuellen Spoke-Netzwerk implementieren.
Anwendungssubnetz: Sie können hier alle Komponenten unter der Logikschicht platzieren. Ein dediziertes Anwendungs-Subnetz hilft auch bei der Steuerung des Datenverkehrs zu den Geschäfts-, Orchestrierungs- und technischen Dienstebenen durch NSGs.
Datenbanksubnetz: Sie können die Komponenten im Datenbanksubnetz in einem dedizierten Subnetz platzieren, um den Datenverkehr rund um die Datenbank zu verwalten.
Private Link: Azure-Dienste wie Recovery Services-Tresor, Azure Cache for Redis und Azure Files werden alle über eine private Verbindung mit dem virtuellen Netzwerk verbunden. Durch eine private Verbindung zwischen diesen Diensten und dem virtuellen Netzwerk wird die Verbindung zwischen den Endpunkten in Azure gesichert, da die Daten nicht im Internet verfügbar sind.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Gansu Adhinarayanan | Director – Partner Technology Strategist
- Vandana Bagalkot | Principal Cloud Solution Architect
- Marc van Houten | Senior Cloud Solution Architect
Andere Mitwirkende:
- Astha Malik | Senior Program Manager
- Jason Martinez | Technical Writer
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Zentralisieren von Kerndiensten mithilfe der Hub-Spoke-Architektur virtueller Azure-Netzwerke
- Einstieg in Finance and Operations-Apps
- Hub-and-Spoke-Netzwerktopologie
- Murex MX.3-Architektur
- Empfohlene Methoden für den Erfolg mit Oracle in Azure IaaS
- Referenzarchitekturen für Oracle Database Enterprise Edition in Azure
- Ausführen Ihrer anspruchsvollsten Oracle-Workloads in Azure, ohne die Leistung oder Skalierbarkeit zu beeinträchtigen