Cloud-Hosting – Überlegungen & Muster

für unabhängige Softwareanbieter (ISVs)

Zum Hosten ihrer Anwendungen benötigen unabhängige Softwareanbieter (ISVs) sichere, skalierbare und zuverlässige Plattform- und Infrastrukturservices. Noch mehr als IT-Unternehmen, die ein Backofficesystem in der Cloud betreiben, müssen sich ISVs mit 24x7-Vorgängen, geografisch verteilten Deployments, dynamischen Kundentrafficmustern, die möglicherweise elastische Skalierung erfordern, und den sicherheitsrelevanten Herausforderungen auseinandersetzen, die die Bereitstellung ihrer Anwendungen im öffentlichen Internet mit sich bringen.

Ein ISV, der zu Hyperscale-Cloud-Providern wechselt oder diese nutzt, muss eine Reihe wichtiger Entscheidungen und Muster berücksichtigen. Sollten Sie Ihre Anwendung unverändert per Lift and Shift verschieben oder eine Cloud-Migration als Gelegenheit nutzen, um in eine cloudnativere Position umzustrukturieren und möglicherweise die verwalteten PaaS-Services eines Anbieters zu nutzen? Kann ein Cloud-Deployment Ihre High-Availability-(HA-) und Disaster Recovery-(DR-)Position verändern, indem es die Möglichkeit bietet, Faultdomains im Rechenzentrum, Availability-Domains in der Region oder regionenübergreifende Interconnects zu nutzen? Welche Tools bietet Ihr Cloud-Provider, um Ihre Daten, Ihr internes Netzwerk, Ihre Compute-Hosts/-Container sowie Ihre Interaktionen mit Ihren Kunden zu sichern? Und stellen Sie Ihre Anwendung als mehrmandantenfähige SaaS-Lösung oder in einer einzelmandantenfähigen Konfiguration für jeden Kunden bereit?

Neben Hunderten von Anwendungen, die Oracle auf OCI umgestellt hat, hat unser Cloud-Engineering-Team Dutzende von ISVs bei der Planung und anschließenden Umstellung auf OCI unterstützt. Diese Microsite bietet Orientierungshilfe und stellt unterschiedliche Hostingmuster für ISVs vor.

Wir untersuchen verschiedene Themen im Hinblick auf unterschiedliche Ansätze zur Einführung von Oracle Cloud.

Diese Microsite ist nicht dazu gedacht, linear gelesen zu werden. Das folgende Diagramm zeigt, wie Sie basierend auf Ihrem eigenen Profil durch diese Site navigieren können. Lesen Sie im Anschluss an diese Einführung den Abschnitt Unser Prozess, und wählen Sie dann abhängig von Ihrem aktuellen Hostingmodell den Abschnitt Von Beginn an in der Cloud oder On Premise/Colocation. Lesen Sie anschließend je nach Anwendungsbereitstellungsmodell entweder den Abschnitt Mehrmandantenfähiges SaaS-Modell oder Einzelmandantenfähiges SaaS-Modell. Der allgemeine Abschnitt Cross-Cutting Concerns und die Zusammenfassung werden zum Abschluss allen Lesern empfohlen.

Unser Prozess

Unsere Teams von Architekten und Ingenieuren unterstützen Sie nicht nur bei der erfolgreichen Migration zu OCI, sondern auch bei der gewinnbringenden Ausführung Ihrer Anwendung in der Cloud. Wir legen großen Wert auf enge Zusammenarbeit und stehen Ihnen bei jedem Schritt mit Anleitungen und Expertise zur Seite. Wir engagieren uns früh im Lebenszyklus und helfen Ihnen zu verstehen, worum es bei OCI geht. Gleichzeitig arbeiten wir mit Ihnen zusammen, um Ihr SaaS-Angebot kennenzulernen und zu verstehen. Anschließend bringen wir beides zusammen. Wir unterstützen Sie nicht nur bei der Schulung Ihres Teams in OCI Foundations, sondern auch bei der Konzeption, Gestaltung und dem Aufbau Ihres gesamten OCI-Mandanten.

Intern nutzen unsere Cloud-Ingenieure einen agilen Ansatz für Cloud-Deployments für Kunden. Dieser umfasst ein integriertes Modell zur Kundeneinbindung, bei dem unsere Ingenieure die Definitions-, Design- und Bereitstellungsphasen mit Ihnen durchgehen, die allgemeine und vereinbarte Meilensteine und Artefakte beinhalten. Zu den generierten Prozessartefakten gehören gemeinsame Projektpläne, logische Architekturen und operative RACIs, die viele Kunden als wertvollen Input für ihren eigenen Cloud-Rollout-Prozess schätzen.

Bei einem typischen (kostenlosen) Engagement mit einem potenziellen ISV-Partner würden wir beispielsweise folgendermaßen vorgehen:

  1. Oracle weist dem Engagement einen Executive Sponsor, einen Business Analyst und einen erfahrenen Cloud-Architekten zu.
  2. Zunächst definieren wir die Ziele unseres Engagements, den Umfang, die Annahmen, den Zeitplan sowie die wichtigsten Akteure auf beiden Seiten und dokumentieren dies in einem gemeinsamen Ausführungsplan.
  3. Anschließend setzen wir uns mit Ihrem technischen Team zusammen und arbeiten Ihre aktuelle Architektur vollständig auf. Dabei gehen wir einen detaillierten Ermittlungsfragebogen durch und sammeln Daten, um Ihren Softwarebestand, Ihre logische Architektur und Ihr Betriebsmodell mit dem Fokus auf Personal, Prozessen und Technologien zu analysieren.
  4. Wenn Schulungssessions erforderlich sind, wird unser Cloud-Architekt Spezialisten einbinden, die tiefgreifende Analysen von Bereichen wie Sicherheit, Datenbank, Beobachtbarkeit usw. ausführen können.
  5. Gemeinsam mit Ihrem Team werden wir eine zukunftstaugliche technische Architektur auf OCI sowie eine Stückliste in OCI entwickeln. Bei Bedarf erstellen wir einen Kostenvergleich mit Ihrer bestehenden Hostingumgebung und helfen Ihnen, einen wettbewerbsfähigen Business Case aufzubauen.
  6. Wir empfehlen dringend, einen Proof of Concept (POC) zu implementieren. Unser Architekt wird dies eingehend mit Ihrem Team besprechen und die erforderlichen Cloud-Engineering-Ressourcen von Oracle hinzuziehen, um die Durchführung mit dem von Ihnen gewünschten Engagement im Rahmen des POC sicherzustellen.
  7. Wenn Sie bereit für den Übergang sind, arbeiten wir Hand in Hand mit Ihnen, um Ihren OCI-Mandanten betriebsfähig zu machen, und helfen Ihnen, von Anfang an Best Practices zu implementieren.

Unser Engagement endet nicht mit der Bereitstellung der ersten Workloads. Ein klares Unterscheidungsmerkmal zwischen OCI und anderen Cloud-Anbietern sind die Cloud Lift Services von Oracle. Dieser spezielle High-Touch-Service wird von einer dedizierten Gruppe von OCI-Experten bereitgestellt, die Sie vom Anfang bis zum Go-Live unterstützen, einschließlich Bewertung, Design und Prototyping, Migration und Management, um Ihre Wertschöpfungszeit zu verkürzen, ohne dass Ihnen Kosten entstehen. Von diesem Programm profitieren sowohl Neu- als auch Bestandskunden. Deren Berechtigung wird während der Vertragsphase oder im Rahmen neuer Erweiterungsmöglichkeiten festgestellt. Migrations- und Go-Live-Support für berechtigte Workloads bedeuten, dass unsere Experten während und nach dem Verkaufsprozess aktiv werden können, um Workloads schneller in die Produktion zu bringen.

Mit Oracle Cloud Lift Services können ISVs ohne zusätzliche Kosten einige der folgenden Aktivitäten ausführen:

  • Anwendungen zu OCI migrieren
  • OCI-Mandanten, -Compartments, -Quoten und -Identitäten konfigurieren; grundlegende Überprüfungen von Netzwerkkonfigurationen und -sicherheit durchführen und FastConnect, Audits und Bewertungen der Einhaltung gesetzlicher Vorschriften einrichten.
  • Interne Ressourcen in OCI schulen
  • Terraform-Pläne erstellen, um Ihre Infrastructure-as-Code-Aktivitäten zu automatisieren

Die umfassenden Erfahrungen, die unsere Cloud-Engineering-Organisation im Laufe vieler Jahre der Migration von SaaS-Anwendungen von Kunden zu OCI sammeln konnte, wurden im Playbook zur SaaS-Migration für ISVs festgehalten.

Unsere Cloud-Ingenieure erfassen alle migrierten Kunden-Workloads im OCI Architecture Center als bewährte Blueprints und dokumentieren allgemeine Best Practices im Best Practices-Guide für OCI. Bitte nehmen Sie sich einen Moment Zeit, um sich mit diesen Informationen vertraut zu machen und einen Eindruck von der Vielfalt der benutzerdefinierten Lösungen zu erhalten, die heute auf OCI ausgeführt werden.

Viele ISV-SaaS-Provider haben ihren Ursprung in der Cloud, was nach "cloudnativ" klingt, aber nicht immer der Fall ist. Von Beginn an in der Cloud bedeutet in der Regel den Wunsch, nicht mehr an Legacy-Systeme gekoppelt zu sein und modernen Anwendungsdesign-Prinzipien zu folgen. Modernes Anwendungsdesign ist der architektonische Leitfaden, der die als Twelve-Factor App umrissenen Prinzipien verkörpert. Auch dies ist nicht dasselbe wie eine cloudnative Architektur, wenn auch eng verwandt. Wenn Sie mehr über "cloudnative" aus der Perspektive von Oracle erfahren möchten, empfehlen wir die Lektüre von Cloud Native Patterns, einem E-Book mit Schwerpunkt auf Cloud-Native-Design.

Unabhängig davon, ob die SaaS-Anwendung nach modernem Anwendungsdesign oder nach cloudnativen Prinzipien erstellt wird, gibt es einige Schlüsselfaktoren, die gleich sind:

  • Wunsch, den Prinzipien der modernen Anwendungsentwicklung zu folgen
  • Wunsch, sich auf die Anwendung und nicht auf die Infrastruktur zu konzentrieren
  • Schnellere Wertschöpfung der Features
  • Kontinuierliche, zuverlässige und wiederholbare Deployments
  • Entkopplung von "Legacy"- oder Single-Vendor-Systemen
  • Wunsch, eine moderne Architektur zu entwickeln, zu betreiben und zu unterstützen
  • Wunsch nach der elastischen Arbeitsweise, die mit Cloud-Computing möglich ist

ISVs, die diese Ziele verfolgen, haben in der Regel eine stärker entkoppelte Servicearchitektur. Anwendungskomponenten in ihrer Workload lassen sich unabhängig bereitstellen, oft als Container, und die Anwendungsarchitektur ist für Application Continuity beim Ausfall von Komponenten ausgelegt. Anwendungen müssen nicht nur die Konsistenz der Daten, sondern auch die Verfügbarkeit der Anwendung handhaben.

Abhängig von der gewählten Laufzeitarchitektur wird der ISV wahrscheinlich Überwachung und Benachrichtigungen in die Steuerung seiner Infrastruktur integriert haben. OCI bietet Services zur Unterstützung von:

Die Kommunikation zwischen den Komponenten implementiert normalerweise ein asynchrones Muster, bei dem Komponenten eher Ereignisse als direkte Anweisungen erzeugen und darauf reagieren. OCI bietet den Streaming-Service – ein Kafka-kompatibler, serverloser Streaming-Service, der häufig für diese Art der Kommunikation verwendet wird. Vorteil dieses Ansatzes ist der Schutz von Komponenten bei Ausfall, wobei die Auswirkungen durch intelligentes Queuing oder Routing reduziert werden.

Eine zusätzliche Entkopplung wird durch die Trennung von Anwendungen und Infrastruktur erreicht. Elastizität wird häufig durch die Nutzung von von Cloud-Serviceprovidern (CSP) bereitgestellten Autoscaling-Mechanismen ermöglicht. Autoscaling kann auf Containerebene erfolgen, indem die Oracle Container Engine for Kubernetes (OKE), die Instanzgruppierungsebene oder die Servergruppenebene genutzt wird.

Im Laufe der Zeit weichen einige SaaS-Anwendungen von ihrer ursprünglich geplanten standardbasierten Architektur ab, da die Teams beginnen, die nativen PaaS-Services eines einzelnen CSP zu nutzen. Beispiele hierfür sind: Verwendung eines exklusiven Datenmanagementservice für eine einzelne Cloud, Einbetten eines direkten API-Aufrufs an eine anbieterspezifische NoSQL-Plattform ohne geeignete Abstraktionsebenen in der Implementierung für einen zukünftigen Austausch, Nutzung von IDEs, die herstellerspezifischen Code generieren. Zur Aufrechterhaltung der Cloud-Portabilität müssen ISVs den Komfort eines Plattformservice mit der Gefahr einer Anbieterabhängigkeit abzuwägen, die sich ergeben kann, wenn der Service nicht anbieterneutral ist. Viele ISVs haben mit der Modernisierung ihrer Anwendungen begonnen, um einen echten Multi-Cloud-Footprint zu erreichen. Dazu überprüfen sie die engen Kopplungspunkte mit Single-Vendor- oder Single-Use-Technologien.

Im Laufe der Zeit kann es zu Abweichungen in der Infrastrukturkonfiguration kommen. Die meisten ISVs verfolgen einen Infrastructure-as-Code-(IaC-)Ansatz, und OCI unterstützt branchenübliche Tools, geht jedoch noch einen Schritt weiter. Um Abweichungen in der Infrastruktur zu überwachen, zu verfolgen und zu reparieren, kann OCI Resource Manager, ein verwalteter Terraform-Service, verwendet werden.

Eine Lift-and-Shift-Implementierung besteht in der Migration Ihrer On Premise oder in einer Colocation ausgeführten Produktions-Workloads zu Oracle Cloud Infrastructure (OCI). In einigen Fällen kann es ratsam sein, Ihre Anwendungen mit den nativen Cloud-Services von OCI anzureichern. Diese "Move-and-Improve"-Aktivität ist ein weiterer überzeugender Grund, zu OCI zu wechseln. Die folgenden Abschnitte behandeln den Lift-and-Shift-Prozess und gehen bei Bedarf auf die Move-and-Improve-Möglichkeiten ein.

Dieses Szenario ist ideal für ISVs geeignet, die ihren Investitionsaufwand reduzieren und einen Teil der betrieblichen Komplexität in Bezug auf Verfügbarkeit, Sicherheit und Performance an einen Cloud-Serviceprovider (CSP) wie Oracle delegieren möchten. Normalerweise implementiert ein ISV eine der folgenden Strategien:

  • Lift and Shift: Migration von On-Premise- oder Colocation-Anwendungen zu OCI
  • Move and Improve: Migration von On-Premise- oder Colocation-Anwendungen zu OCI und deren Anreicherung mithilfe cloudnativer Services oder durch Migration von Datenbanken zu cloudbasierten Angeboten.

Nichts hindert Sie daran, diese Strategien zu kombinieren und abzugleichen, wenn einige Workloads unverändert migriert werden, andere jedoch modifiziert werden, um verwaltete OCI-Services (PaaS) zu nutzen.

Lift and Shift

Die Lift-and-Shift-Cloud-Migrationsstrategie besteht darin, Ihre On-Premise-Anwendung in OCI zu verschieben, sodass das resultierende Deployment dem On-Premise-Deployment möglichst ähnlich ist. Der erste Schritt dieses Prozesses ist die Identifizierung von Workloads/Anwendungen, für die Sie die Möglichkeiten von OCI nutzen und Ihre strategischen Ziele erreichen können. Wir bieten zahlreiche Hostingmodalitäten, aus denen Sie je nach Datenresidenz-, Latenz- und Konnektivitätsanforderungen wählen können. Unabhängig davon, für welche der folgenden Hostingtypen Sie sich entscheiden, haben Sie Zugriff auf das vollständige Portfolio von OCI.

Hostingtyp Beschreibung
Public Cloud Umfassende Plattform mit IaaS-, PaaS- & SaaS-Services
Government Cloud (eingeschränkte Bereiche) Umfassende Plattform mit IaaS-, PaaS- & SaaS-Services, die in einem eingeschränkten Bereich für Entitäten der öffentlichen Verwaltung bereitgestellt werden
Dedicated Region Cloud@Customer Umfassende Plattform mit IaaS-, PaaS- & SaaS-Services, die in Ihrem Rechenzentrum bereitgestellt werden
Roving Edge Infrastructure Umfassende Plattform mit IaaS-, PaaS- & SaaS-Services, die über robuste Oracle Roving Edge Devices (Oracle REDs) bereitgestellt werden und Cloud-Computing- sowie Speicherservices an der Netzwerk-Edge und an getrennten Standorten liefern
Oracle Cloud VMWare Verlagern Sie VMware-basierte Workloads in die Cloud, oder erweitern Sie Ihr On-Premise-VCenter um Cloud-Funktionen, ohne die Anwendungsarchitektur zu ändern oder Betriebsabläufe umzurüsten.

Oracle unterstützt eine Vielzahl von Netzwerkkonnektivitätsoptionen, mit denen Sie eine Hybrid-Cloud-Lösung entwerfen können, die OCI-Ressourcen mit Komponenten kombiniert, die in Ihrem Rechenzentrum ausgeführt werden, oder eine Multi-Cloud-Lösung, die Ihren OCI-Footprint mit dem eines anderen Cloud-Serviceproviders verbindet. Beide Ansätze sind weit verbreitet und können die Migration von Workload-Abhängigkeiten für vorhandene Anwendungen erleichtern, die On Premise oder in Umgebungen anderer Cloud-Provider ausgeführt werden, um Anforderungen an Datenresidenz, IT-SLAs oder andere Anforderungen zu erfüllen.

OCI ermöglicht diese Kommunikation über das öffentliche Internet, über ein IPSec-VPN oder über dedizierte Konnektivität (FastConnect). In der folgenden Tabelle werden einige Merkmale der einzelnen Ansätze beschrieben:

Methode Latenz Kosten Zuverlässigkeit Sicherheit
Öffentliches Internet Variabel Variabel Variabel Geringste Sicherheit
IPSec-VPN Variabel Variabel Variabel Traffic wird verschlüsselt, aber der Tunnel läuft über das öffentliche Internet
OCI FastConnect Gering und vorhersagbar Vorhersagbar Zuverlässigste Lösung Am sichersten; Traffic führt über eine private Verbindung

Obwohl mit den oben genannten Technologien eine Cloud-zu-Cloud-Verbindung zwischen OCI und jeder anderen Cloud möglich ist, kann Oracle aufgrund seiner Partnerschaft mit Microsoft Azure eine als Produkt umgesetzte Interkonnektivität zwischen beiden Clouds mit geringer Latenz in vielen Regionen der Welt bereitstellen.

Oracle hat eine Reihe von Partnern, die sich auf die Automatisierung der Migration zu OCI aus beliebig vielen Quellen spezialisiert haben, einschließlich Public Clouds von Mitbewerbern und virtualisierten/nicht virtualisierten On-Premise-Umgebungen. Eine vollständige Liste der Migrationsanbieter finden Sie auf unserem Marketplace. Hervorzuhebende Beispiele sind Rackware und ZConverter.

Wenn Sie die Migration von Oracle Database aus anderen Clouds oder On-Premise-Umgebungen in Erwägung ziehen, bietet Oracle eine Reihe von Tools für die Offline- oder Zero-Downtime/Live-Migration. Zu diesen Tools gehören Zero Downtime Migration (ZDM), OCI Database Migration (DMS), GoldenGate, DataPump, RMAN und andere. Das Tool der Wahl hängt von den Merkmalen Ihrer Quell- und Zieldatenbank sowie Ihrer Betriebsumgebung ab. Weitere Details finden Sie in auf der Landingpage für die Datenbank-Cloud-Migration von OCI.

Move and Improve

Die Cloud-Migrationsstrategie "Move and Improve" besteht darin, einen vorhandenen Service durch ein Cloud-Angebot anzureichern oder zu ersetzen. Während der Identifizierung der geeigneten Kandidaten für die Migration in die Cloud sollten Sie den Möglichkeiten zur Anreicherung oder Ersetzung von Services hohe Priorität einräumen. Beispielsweise können Sie vorhandene On-Premise-Anwendungen verbessern, indem Sie die On-Premise-Datenbank, die eine geschäftskritische Anwendung unterstützt, zu unserem verwalteten Database Cloud Service, unserer führenden selbststeuernden Autonomous Database oder zu Exadata Cloud Service, der schnellsten Plattform zum Ausführen von Oracle Databases in der Cloud, migrieren.

Darüber hinaus gewährt die Einführung von Oracle Cloud Infrastructure Zugriff auf das gesamte Serviceportfolio, das folgende Bereiche umfasst:

Ein mehrmandantenfähiges Bereitstellungsmodell für SaaS-Anbieter verwendet Software, die auf einer gemeinsam genutzten Infrastruktur ausgeführt wird, um einzelne ISV-Endkunden (Mandanten) zu unterstützen.

Die Kundendaten werden normalerweise in mehreren gemeinsam genutzten Tabellen gespeichert, und alle Anwendungslayer kennen die eindeutige ID eines Kunden. Die Anwendung selbst unterstützt mehrere Clients. Die Anwendung ist in der Regel auch für die Verwaltung von Benutzerabonnements zuständig. Darüber hinaus muss die Infrastruktur basierend auf der Anzahl der Kunden, Transaktionen und Vorschriften, die unterstützt werden müssen, in Servergruppen kategorisiert werden.

Was spricht für dieses Modell?

Ein mehrmandantenfähiges Modell bringt dem ISV (Independent Software Vendor, unabhängiger Softwareanbieter) Vorteile. Die Skaleneffekte eines mehrmandantenfähigen Modells bieten viele Effizienzgewinne. Da die Zusammensetzung der Servergruppen bekannt ist, lassen sich Effizienzsteigerungen bei der Verwaltung und Überwachung der Infrastruktur erzielen. Zum Starten eines neuen Servicebereichs müssen einfach nur der Infrastrukturautomatisierungscode ausgeführt und anschließend die Anwendung bereitgestellt werden. Die gemeinsame Infrastruktur bietet auch eine einheitliche Transparenzebene für die Überwachung.

Da Kunden auf gemeinsamen Compute-, Speicher- und Datenbanksystemen gehostet werden, ist eine einfachere Anwendungs-Deployment-Strategie möglich. ISVs, die dieses Modell nutzen, haben normalerweise eine einzige Codebasis, die das Deployment von Updates im gesamten Kundenstamm erleichtert. Viele ISVs, die dieses Modell verwenden, bieten Kunden die Möglichkeit, sich mithilfe von Feature-Flags für neue Features zu entscheiden.

All diese Vorteile können natürlich auch Nachteile mit sich bringen. Die Unterstützung von Kunden mit spezifischen Anforderungen an Datenresidenz erfordert eine regionale Deployment-Strategie, und es kann Szenarien geben, in denen Kunden aufgrund betrieblicher Anforderungen nicht auf denselben Servern wie ein Mitbewerber gehostet werden können. Abhängig von der Architektur der Anwendung können die Clients durch einen Noisy Neighbor beeinträchtigt werden. Wenn eine Servergruppe gesättigt ist, muss der ISV entscheiden, den Kunden entweder zu einer neueren, weniger genutzten Servergruppe zu migrieren oder die Kapazität der bestehenden Gruppe zu erweitern.

Eine unbeabsichtigte Folge der ordnungsgemäßen Unterstützung des mehrmandantenfähigen SaaS-Modells besteht darin, dass die Anwendungsarchitektur gut durchdacht und auf einer höheren Ebene als in einer einzelmandantenfähigen Architektur geplant werden muss. Von Anfang an müssen angemessene Zugriffskontrollen und Datentrennungsmodelle in das Anwendungs-Framework integriert werden, und ISVs müssen sicherstellen, dass sie über die entsprechenden internen Engineering-Skills verfügen.

Oracle kann helfen, die Lücke zu schließen, indem unsere Cloud-Architekten einbezogen werden, um Sie bei der Modernisierung Ihrer Anwendung und deren Optimierung für eine erfolgreiche Cloud-Migration zu beraten. Unsere Architekten arbeiten mit anderen ISVs des gesamten Spektrums zusammen und können Erfahrung mit ähnlichen Problemen sowie Best Practices in Ihre Cloud-Transformation einbringen.

Isolierung von Servergruppen

Ein Schlüsselkonstrukt des mehrmandantenfähigen Modells ist eine gemeinsame Umgebung für gehostete Mandanten. Als ISV müssen Sie sicherstellen, dass die SaaS-Anwendung so konzipiert ist, dass sie Kundendaten während der Laufzeit ordnungsgemäß trennt und schützt. Sie müssen auch in der Lage sein, die Vorgänge in den verschiedenen Servergruppen, die Ihre Anwendung hosten, angemessen zu verwalten, zu überwachen und zu warten.

Möglicherweise haben Sie spezifische Anforderungen, um Kunden aus bestimmten Regionen von Kunden aus anderen Regionen (oder Unterregionen) zu trennen. Diese Art der Trennung kann erreicht werden, indem Sie Ihre Workloads in eine Kombination aus OCI-Regionen und -Compartments einteilen. Ein Beispiel hierfür wäre ein SaaS-Anbieter in den USA, der Services sowohl an das Gesundheitswesen als auch an den allgemeinen Fertigungsmarkt verkauft. Der Anbieter könnte diese Workloads mithilfe regionaler und Compartment-Konstrukte trennen und unterschiedliche Funktionen bereitstellen (d. h. HIPPA/HITRUST-Compliance für die Workloads im Gesundheitswesen).

Eine natürliche Entwicklung für ISVs, die mit einem mehrmandantenfähigen Modell begannen, ist die Weiterentwicklung ihres Angebots, um eine bessere Isolierung von Kundendaten zu bieten. Normalerweise findet diese Entwicklung zuerst auf der Datenebene statt, und Oracle Database unterstützt ein mehrmandantenfähiges Modell, das die Einbettung unabhängiger, integrierbarer Datenbanken in eine einzelne Containerdatenbank ermöglicht.

Ein einzelmandantenfähiges Bereitstellungsmodell verwendet Software, die auf einer dedizierten Infrastruktur ausgeführt wird, um einzelne ISV-Endkunden zu unterstützen. Im Gegensatz zu einem mehrmandantenfähigen Modell, bei dem mehrere Kunden dieselben Compute-Zyklen teilen und Daten in gemeinsamen Datenbanktabellen gemischt werden, basiert ein einzelmandantenfähiges Modell auf eindeutigen Compute-VMs, eindeutigen Datenbanken und einer eindeutigen unterstützenden Infrastruktur (Load Balancer, Nachrichtenqueues usw.) für jeden Kunden.

Was spricht für dieses Modell?

Ein einzelmandantenfähiges Modell bringt dem ISV (Independent Software Vendor, unabhängiger Softwareanbieter) zahlreiche Vorteile. Durch das Hosten von Kunden/Mandanten auf separaten Compute-, Speicher- und Datenbanksystemen ist eine bessere Trennung der Belange hinsichtlich Sicherheit und Performance möglich. Kunde "A" kann Kunde "B" weder durch böswillige Handlungen noch durch versehentliche Mehrnutzung von mehr als dem zugewiesenen Anteil an Ressourcen beeinträchtigen oder schaden. Darüber hinaus wird das Ausmaß schwerwiegender Fehler begrenzt. Der Ausfall einer einzelnen Komponente (d. h. einer Datenbank oder einer Nachrichtenqueue) wirkt sich auf einen einzelnen Kunden und nicht auf die gesamte SaaS-Anwendung aus. Jeder Mandant hat seine eindeutige, mit eigenen Features und Patches angepasste Umgebung, wodurch ein stark kundenorientiertes Bereitstellungsmodell ermöglicht wird.

All diese Vorteile können natürlich auch Nachteile mit sich bringen. Jeder Vorteil, der sich beispielsweise aus der Bereitstellung kundenorientierter Umgebungen ergibt, kann durch den Mehraufwand für Konfigurationsmanagement und erhöhte Überwachung und Wartung zunichte gemacht werden. Durch ein mehrmandantenfähiges Modell werden viele weitere Vorteile dieses Ansatzes realisiert, auch wenn dies ein strikteres Design und eine strengere Implementierung der SaaS-Anwendung des ISV erfordert.

Letztendlich hängt die Entscheidung davon ab, ob ein ISV in die Mehrmandantenfähigkeit seiner SaaS-Anwendung investieren möchte und über die dafür erforderlichen internen Softwareentwicklungsskills verfügt. Andernfalls kann er sich auf die inhärenten Fähigkeiten zur Bildung von Compartments seiner Softwareplattform und/oder seines Hyperscale-Cloud-Providers verlassen. Jeder ISV muss diese Entscheidung basierend auf seiner spezifischen Situation treffen.

Oracle kann Ihnen bei der Entscheidungsfindung helfen, indem unsere Cloud-Architekten einbezogen werden, um Sie bei der Modernisierung Ihrer Anwendung und deren Optimierung für eine erfolgreiche Cloud-Migration zu beraten. Unsere Architekten arbeiten mit anderen ISVs des gesamten Spektrums zusammen und können Erfahrung mit ähnlichen Problemen sowie Best Practices in Ihre Cloud-Transformation einbringen.

Mandantenisolierung

Ein Schlüsselkonstrukt des einzelmandantenfähigen Modells ist eine isolierte Umgebung für jeden Mandanten. Als ISV möchten Sie dedizierte Compute-, Netzwerk-, Speicher-, Messaging- und Datenbankressourcen für jeden Ihrer Kunden bereitstellen. Diese Ressourcen sollten sowohl aus Laufzeit- als auch aus Verwaltungsperspektive voneinander getrennt sein.

OCI bietet ein einzigartiges Feature namens Compartments, das für eine starke logische Trennung zwischen OCI-Ressourcen sorgt. Sie können eine gesamte Kundenumgebung einschließlich Netzwerk, Computer usw. in einem Compartment platzieren und OCI-Richtlinien aufstellen, die den Zugriff auf diese Ressourcen steuern. Mit diesen beiden OCI-Kernfeatures können Sie den Kunden "A" effektiv von Kunde "B" trennen und jegliche Ressourcen-, Management- oder Informationsüberschneidungen verhindern. Compartments sind hierarchisch, sodass Sie sie verschachteln und mit diesem Ansatz komplexe Kundensetups modellieren können. Stellen Sie sich beispielsweise ein realistisches Kundenszenario mit mehreren Geschäftsbereichen vor, bei dem eine Trennung zwischen den Geschäftseinheiten gewünscht wird, gleichzeitig jedoch einige gemeinsame Unternehmensressourcen beibehalten werden sollen.

Obwohl das Compartment-Modell die sichersten Garantien für eine Trennung bietet, gibt es einige Zwischenansätze, die auf bestimmten Anwendungsebenen genutzt werden können, um die Ressourcenauslastung zu verbessern, während gleichzeitig auf eine nicht angepasste Methode zur Trennung von Mandanten zurückgegriffen wird. Anstatt beispielsweise für jeden Mandanten ein separates Datenbanksystem zu erstellen, können Sie die Mehrmandantenfähigkeitsfunktionen von Oracle Database nutzen, um eine einzelne Containerdatenbank mit mehreren integrierbaren Schemas zu implementieren. Dieser Ansatz reduziert den Aufwand für die Einrichtung mehrerer Datenbankcluster und ermöglicht es der Datenbank dennoch, eine Trennung durchzusetzen, ohne dass ein Neuschreiben des Anwendungsschemas erforderlich wird. Die virtuellen Maschinen und Bare-Metal-Database-as-a-Service-Lösungen von Oracle unterstützen Out-of-the-box-Mehrmandantenfähigkeit. Gleiches gilt für die autonome dedizierte Datenbank, die für besonders anspruchsvolle Workloads genutzt werden kann.

Dieser Zwischenansatz wird nicht nur auf der Data Tier unterstützt. Wenn Ihre Anwendung containerisiert ist, können Sie die Container Engine for Kubernetes (OKE) von Oracle verwenden, um mehrere Kundencontainer in einer einzigen Infrastruktur bereitzustellen. Im Anschluss können Sie native Kubernetes-Primitives wie Namespaces, rollenbasierte Zugriffskontrolle (RBAC), Secrets und Ressourcen-Quotas verwenden, um die Mandantentrennung aufrechtzuerhalten. Wie bei der Datenbank können Sie einfach die Funktionen der zugrunde liegenden Cloud-Services nutzen, anstatt Ihre Anwendung für Mandantenfähigkeit umzuschreiben.

Erfahren Sie, warum ISVs sich für Oracle Cloud entscheiden

Mit dem breiten Spektrum an Services und Support von OCI können ISVs ihren Kunden erheblichen Mehrwert bieten.

Weitere Informationen

Cross-Cutting Concerns

Vielleicht arbeiten Sie als ISV "von Beginn an in der Cloud" und verwenden eine einzelmandantenfähige SaaS-Infrastruktur, die die inhärenten Fähigkeiten Ihres Hyperscalers nutzt. Oder Sie haben mit einem On-Premise-Deployment begonnen und migrieren Ihre mehrmandantenfähige SaaS-Anwendung, um ausschließlich in der Cloud zu agieren. Und natürlich kann es auch sein, dass Ihr Unternehmen eine Kombination dieser Ansätze nutzt. Ungeachtet des eingeschlagenen Pfads muss sich jeder in der Cloud operierende ISV mit wichtigen Cross-Cutting Concerns wie Sicherheit, Beobachtbarkeit, Geschäftskontinuität und Automatisierung befassen. In den folgenden Abschnitten sehen wir uns an, wie Oracle aufgestellt ist, um diese funktionalen Herausforderungen zu meistern und sich von der Konkurrenz abzuheben.

  • Sicherheit, Governance und Compliance

    Oracle verfolgt den Ansatz, dass Sicherheitsfunktionen standardmäßig immer aktiviert sind und dass sie einfach und präskriptiv sein sollten. Außerdem sind wir der Ansicht, dass Kunden sich nicht zwischen Kosten und Sicherheit entscheiden müssen, und sind bestrebt, alle sicherheitsrelevanten Services entweder unentgeltlich oder zu geringen Kosten über Partneralternativen auf unserem Marktplatz anzubieten. Wir sind davon überzeugt, dass Kunden Sicherheitsprobleme nicht aufgrund fehlender Tools zur Vermeidung von Angriffen erleiden, sondern weil diese Tools für die meisten Unternehmen entweder zu teuer oder zu komplex sind.

    Oracle ist der Ansicht, dass Sicherheit in der gemeinsamen Verantwortung des Cloud-Providers und des ISVs liegt. Wir bieten bestimmte Kernfunktionen wie isolierte Netzwerkvirtualisierung und Hardware-Root-of-Trust und erweitern diese um Tools und Services, mit denen der ISV seinen Sicherheitsstatus anpassen kann. ISVs, die sich einen Überblick über unsere Sicherheitsangebote verschaffen möchten, sollten sich zunächst unsere Landingpage für Sicherheit und Cloud-Sicherheitsarchitektur ansehen.

    Kernsicherheit garantieren wir ausgehend von unserer robusten Identity & Access Management-(IAM-)Implementierung, die rollenbasierte Zugriffskontrollen mit unserem intuitiven Policy-Framework verbindet. Diese Funktion deckt eine Vielzahl von Themen ab, darunter Benutzer, Gruppen, Identity Federation und Instanz-/Resource-Principal-Autorisierung. Auch wenn dies nicht durch IAM abgedeckt ist, gewährleistet ein weiteres zentrales Sicherheitskonzept benutzerdefiniertes Networking mithilfe von Netzwerksicherheitsregeln, Gruppen und Listen.

    Wenn Sie mit der Entwicklung einer sicheren technischen Architektur auf Oracle Cloud Infrastructure (OCI) beginnen, ist das Center for Internet Security (CIS) als herstellerneutrale Organisation, die Best Practices zum Thema Internetsicherheit katalogisiert, ein guter Ausgangspunkt. CIS hat eine sichere Benchmark für OCI-Anwendungen bereitgestellt, und Oracle hat mit Terraform Automatisierungsfunktionen entwickelt, die ISVs bei der Umsetzung von CIS-Empfehlungen unterstützen.

    OCI bietet eine Reihe weiterer grundlegender Sicherheitsservices:

    Eine einzigartige und neuartige Fähigkeit von OCI sind Zonen mit maximaler Sicherheit, die automatisch Sicherheits-Policys in OCI einrichten und durchsetzen. Dies ermöglicht die Durchsetzung deklarativer Sicherheit mit Best Practices und bietet einen proaktiven statt reaktiven Sicherheitsansatz für die kritischsten Ressourcen.

    Keine Sicherheitsimplementierung ist vollständig ohne eine Verwaltung des Sicherheitsstatus. Diese Funktionalität wird von Cloud Guard für die gesamte OCI-Umgebung und von Data Safe für die Datenbank-Workloads bereitgestellt. Beide Services stehen OCI-Kunden kostenlos zur Verfügung. Sie gewährleisten, dass falsch konfigurierte Ressourcen und unsichere Aktivitäten mithilfe von Out-of-the-box-Sicherheitsrezepten oder durch Senden von Daten an SIEM/SOC-Systeme schnell und automatisiert erkannt und behoben werden.

  • Beobachtbarkeit

    Jedes Unternehmen muss die Möglichkeit haben, Einblicke in die Performance seines Cloud-Bestands zu erhalten, um den laufenden Betrieb und die zukünftige IT-Planung zu unterstützen. Insbesondere ISVs benötigen umfangreichere Funktionen, da sie in der Regel benutzerdefinierte Anwendungen ausführen, die oft eine tiefere Instrumentierung der Anwendungsperformance erfordern. Darüber hinaus führen viele ISVs ihre Workloads in Cloud-Umgebungen mit einer externen 24x7-Kundenbasis aus, was eine höhere Verfügbarkeit als ein typisches Backofficesystem erforderlich macht.

    OCI bietet auf Basisebene einen Monitoring-Service, der Echtzeiteinblicke in die Performance der Workloads auf OCI ermöglicht und Out-of-the-box-Metriken für Zustand und Performance zur Verfügung stellt. Benutzer können Alarme konfigurieren, um Anomalien zu erkennen und darauf zu reagieren. Dieser Service wird mit unserem Haupt-Loggingservice kombiniert, der zusätzlich zu den von Ihren Workloads generierten Logs OCI-Logs anzeigt. Alle Bedingungen oder Probleme, die durch einen der oben genannten Services identifiziert werden, können von unserem Notifications-Service bearbeitet werden. Dieser stellt ein hochverfügbares Publish-Subscribe-System mit geringer Latenz bereit, das Alerts an serverlose Funktionen (zur automatischen Korrektur), E-Mail- oder Nachrichtenübermittlungspartner wie Slack und PagerDuty sendet.

    Darüber hinaus bietet Oracle eine Reihe von Machine Learning-(ML-)basierten Services, die tiefergehende Analysen in den Bereichen Logging, Anwendungsperformance, Datenbankperformance und Betrieb ermöglichen. Mit Logging Analytics können Sie sämtliche Logdaten überwachen, aggregieren, indexieren und analysieren sowie mithilfe von ML Problemcluster und Anomalien erkennen. Application Performance Monitoring ist ein standardkonformer (OpenTracing & OpenMetrics) Service, der synthetisches Monitoring, verteiltes Tracing und Analyse der Transaktionsausführung von benutzerdefinierten Anwendungen ermöglicht, einschließlich nativer Unterstützung für Microservices-Telemetrie, die von Kubernetes-/Docker-Umgebungen abgeleitet wird, die viele ISVs anbieten. Database Management bietet Überwachungsfunktionen für Oracle Database-Flotten und Operations Insights, mit denen Administratoren Performanceprobleme aufdecken, den Verbrauch prognostizieren und die Kapazität mithilfe von ML-Analysen planen können. Mit diesen Funktionen können Unternehmen datengestützte Entscheidungen zur Optimierung der Ressourcennutzung, proaktiven Vermeidung von Ausfällen und Verbesserung der Performance treffen.

    Alle diese Beobachtbarkeitsfunktionen werden als integrierte Services in OCI bereitgestellt und umfassen großzügige "Free Tiers", die es dem ISV ermöglichen, Services in begrenzten Szenarien zu nutzen und dann aufbauend auf einer erfolgreichen Implementierung auf eine größere Nutzung auszuweiten.

  • Geschäftskontinuität

    Die Anforderungen eines ISV an Geschäftskontinuität können oft strikter sein als die eines herkömmlichen IT-Unternehmens. Während Ausfallzeiten bei einem traditionellen Backofficesystem wie ein Human Capital Management-(HCM-) oder Enterprise Resource Planning-(ERP-)System problematisch sein können, können die meisten ISVs nicht einmal vorübergehende Unterbrechungen ihrer Kundensysteme tolerieren, da sie das Lebenselixier ihres Unternehmens sind. Zu diesem Zweck sind Konzepte wie High Availability (HA) und Disaster Recovery (DR) extrem wichtig, und ISVs müssen die Funktionen, die OCI in diesen Bereichen bietet, in größtmöglichem Umfang nutzen.

    High Availability

    Eine OCI-Region ist ein bestimmter geografischer Bereich, der aus einer oder mehreren Availability-Domains besteht, die jeweils wiederum drei Faultdomains umfassen. High Availability wird durch redundante Faultdomains innerhalb der Availability-Domains gewährleistet.

    Eine Availability-Domain besteht aus mindestens einem Rechenzentrum in einer Region. Availability-Domains sind voneinander isoliert und fehlertolerant. Die Wahrscheinlichkeit, dass sie gleichzeitig ausfallen, ist daher sehr gering. Da Availability-Domains keine gemeinsame physische Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domain-Netzwerk verwenden, ist es unwahrscheinlich, dass ein Fehler, der sich auf eine Availability-Domain auswirkt, die Verfügbarkeit anderer beeinträchtigt.

    Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain enthält drei Faultdomains. Mit Faultdomains können Sie Ihre Instanzen so verteilen, dass sie sich nicht auf derselben physischen Hardware innerhalb einer einzigen Availability-Domain befinden. Infolgedessen wirkt sich ein unerwarteter Hardwarefehler oder eine Compute-Hardwarewartung, der/die eine Faultdomain betrifft, nicht auf Instanzen in anderen Faultdomains aus.

    Alle Availability-Domains in einer Region sind über ein Netzwerk mit geringer Latenz und hoher Bandbreite miteinander verbunden. Diese vorhersagbare, verschlüsselte Verbindung zwischen Availability-Domains bildet die Grundlage für High Availability und Disaster Recovery.

    Sie können Lösungen für mehrere Regionen, mehrere Availability-Domains oder mehrere Faultdomains entwerfen, je nachdem, vor welcher Fehlerkategorie Sie sich schützen möchten.

    Um Ihre Netzwerkressourcen, Speichersysteme und Datenbankressourcen vor lokalisierten Fehlern zu schützen, stehen Ihnen zahlreiche Funktionen in OCI sowie andere Optionen zur Auswahl. Eine hervorragende Informationsquelle, um fundierte Entscheidungen bezüglich Ihres Betriebsmodells treffen zu können, ist die vollständige Lektüre des Playbooks für High Availability-Lösungen im OCI Architecture Center.

    Disaster Recovery

    Jedes Ereignis, das Ihre Anwendungen gefährdet – von Netzwerkausfällen über Gerätefehler bis hin zu Naturkatastrophen –, kann Disaster Recovery-Funktionen erforderlich machen. Ein gut durchdachter Disaster Recovery-(DR-)Plan ermöglicht Ihnen eine schnelle Wiederherstellung nach Ausfällen und die unterbrechungsfreie Bereitstellung von Services für Ihre Benutzer. Die DR-Funktionalität von OCI baut auf den umfangreichen High Availability-(HA-)Funktionen auf, die im vorherigen Abschnitt besprochen wurden.

    Bei der Planung Ihrer DR-Strategie müssen Sie zunächst Ihr Recovery Time Objective (RTO) und Recovery Point Objective (RPO) berücksichtigen. Das RTO ist die Zielzeit, innerhalb der eine bestimmte Anwendung nach einem Notfall wiederhergestellt werden muss. Je kritischer die Anwendungen, desto niedriger ist in der Regel das RTO. Das RPO ist der Zeitraum nach einem Notfall, in dem die Anwendung verlorene Daten tolerieren kann, bevor es zu Beeinträchtigungen des Geschäftsbetriebs kommt.

    Als Nächstes müssen Sie bestimmen, für welche Art von Ausfallszenario Sie planen. Möchten Sie sich vor Anwendungsfehlern, Netzwerkfehlern, Rechenzentrumsausfällen, regionalen Ausfällen oder allen genannten Widrigkeiten schützen? Die Antwort auf diese Frage sowie Ihre RTO/RPO-Überlegungen bestimmen Ihre DR-Strategie.

    OCI bietet Anleitungen zum Aufbau desastertoleranter Architekturen auf Compute-, Netzwerk-, Speicher-, Anwendungs- und Datenbankebene. Mit diesen Tools können Sie entweder eine Active-Active-Architektur aufbauen, in der Ihre Anwendungen gleichzeitig in zwei Regionen funktionieren und ein Fehler in Region "A" von Region "B" behandelt werden kann, ein Warm-Backup-Szenario, bei dem eine sekundäre Region vorbereitet wird und bereitsteht, den Traffic bei Ausfall der primären Region zu übernehmen, ein Cold-Backup-Szenario, bei dem eine Mischung aus manuellen und/oder automatisierten Schritten erforderlich sein kann, um den Geschäftsbetrieb wiederherzustellen, oder eine Hybridimplementierung daraus.

    Eine hervorragende Informationsquelle, um fundierte Entscheidungen bezüglich Ihres Betriebsmodells treffen zu können, ist die vollständige Lektüre des Playbooks für Disaster Recovery-Lösungen im OCI Architecture Center.

  • Budgets und Quotas

    Als ISV, der eine SaaS-Anwendung ausführt, die OCI-Compartments zur Isolierung nutzt, sollten Sie einige zugehörige Primitives in Betracht ziehen, die Ihnen – und Ihren Kunden – die Ressourcenverwaltung vereinfacht. Jeder OCI-Mandant ist normalerweise mit einem bestimmten jährlichen Budgetlimit vorkonfiguriert, und obwohl Überschreitungen keine Strafen zur Folge haben, bevorzugen die meisten ISVs eine strikte Kontrolle der Ressourcenauslastung.

    ISVs sollten zunächst Compartment-Quotas als Tool zur Aufteilung der mandantenübergreifenden Ressourcen auf verschiedene Compartments im Mandanten in Erwägung ziehen. Mit diesen Primitives können gemeinsam genutzte Ressourcen wie CPUs und Speicherblöcke oder spezialisiertere Ressourcen wie GPUs und Exadata über Compartments hinweg zugeteilt werden, um sicherzustellen, dass kein Mandant eine übergroße Ressourcenzuteilung erhält und bestimmte spezialisierte Ressourcen an den richtigen Stellen zugewiesen werden.

    Quotas gelten für Cloud-Ressourcen. Bei der Kontrolle der Budgetzuteilung sollten ISVs OCI-Budgets in Betracht ziehen. Mit dieser Funktion können Sie Nutzungsbudgets für jedes Compartment festlegen und Alerts erhalten, wenn sich ein Budget einem variablen Grenzwert nähert oder einen absoluten Grenzwert überschritten hat. Mit diesem Feature können ISVs ihre Ausgaben für mehrere Kunden verwalten und den Bedarf für zukünftiges Ressourcenwachstum vorhersagen.

    Chargeback

    Auch wenn jeder ISV seine SaaS-Services anders bepreist, gilt das Konzept der Herstellkosten des Umsatzes (COGS) als gemeinsamer Ansatz vieler Preismodelle. Ohne die Ausgaben für die Entwicklung und Bereitstellung eines Produkts zu kennen, lässt sich nur schwer ermitteln, wie der Preis angemessen berechnet und anschließend verbraucherabhängig variiert werden kann.

    In einen SaaS-Service fließen viele Preisinformationen ein, einschließlich der Kosten für Entwicklung und Marketing; eine Schlüsselkomponente sind jedoch die Kosten für das Cloud-Hosting. Dies ist ein Bereich, in dem die Kostenanalyse von OCI Ihnen helfen kann, indem dynamische Visualisierungen der Nutzung mandantenübergreifend nach Compartments und/oder Kostenverfolgungstags bereitgestellt werden. Mit diesen Tools können Sie die Höhe Ihrer Ausgaben für das Hosting jedes Kunden ermitteln und entscheiden, ob Sie die angebotenen Preise möglicherweise anpassen müssen oder nicht.

    Falls unsere Visualisierungsdaten für Ihre Zwecke nicht detailliert genug sind, können Sie vollständig granulare Nutzungsdaten in einem maschinenlesbaren Format zur weiteren Analyse mit einem Tool Ihrer Wahl exportieren. Wenn Sie in einer Hybrid-Cloud-Umgebung arbeiten, können Sie mit Multi-Cloud-Drittanbietertools wie CloudHealth einheitliche Analysen durchführen.

  • Infrastrukturautomatisierung

    Nur sehr wenige Unternehmen erstellen ihre Umgebungen von Grund auf neu. Insbesondere ISVs haben den Wert der Infrastrukturorchestrierung und des Konfigurationsmanagements durch den Einsatz von Infrastructure-as-Code-(IaC-)Tools wie Terraform, Ansible, Puppet usw. erkannt. IaC ist unabhängig von der Größe Ihres Unternehmens, dem technischen Fußabdruck oder dem Deployment-Ansatz optimal geeignet. Dies gilt speziell für expandierende ISVs, die ihre regionale Präsenz und installierte Basis ständig erweitern. Ohne Automatisierung wird Ihr Wartungsaufwand exponentiell anwachsen und schwer zu verwalten sein.

    OCI unterstützt eine Reihe branchenüblicher Automatisierungstools für die Implementierung cloud-unabhängiger Automatisierungsstrategien. Dazu gehören produktbasierter Support für HashiCorp Terraform, Ansible und Chef. Da OCI alle Funktionen über SDKs und über CLI zur Verfügung stellt, lassen sich beliebig viele andere Tools wie Puppet ganz einfach integrieren.

    Mit dem verwalteten Service Resource Manager baut OCI auf den Funktionen von Terraform auf. Dieser Service, der OCI-Kunden kostenlos zur Verfügung steht, ermöglicht die Ausführung von Terraform innerhalb der Grenzen des policy-basierten Sicherheitsmodells von OCI und bietet out-of-the-box Statusverwaltung, Vorlagen, Ressourcen-Discovery und GitHub-/GitLab-Integration.

  • Automatisierung des Softwarelebenszyklus

    ISVs verwenden automatisierte Erstellungs- und Deployment-Tools, um ihren Code durch den Softwareentwicklungslebenszyklus zu bewegen. Bei der Betrachtung eines einzelmandantenfähigen Bereitstellungsmodells wird eine starke Automatisierung noch wichtiger, da ein einzelnes Deployment an Hunderte von Mandanteninstanzen geliefert werden kann. Darüber hinaus müssen diese Deployments häufig rollierend durchgeführt werden, um Ausfallzeiten zu vermeiden. Sie müssen flexibel genug sein, um spezifische branchenabhängige Anpassungen für einzelne Kunden zu bewältigen.

    OCI unterstützt die überwiegende Mehrheit branchenführender CI/CD-Tools auf dem Markt. Ungeachtet dessen, ob Sie Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions, CircleCI oder andere Lösungen nutzen, gibt es sehr wahrscheinlich Benutzer im Software-Ökosystem, die Ihr bevorzugtes Tool mit OCI verwenden.

    Darüber hinaus bietet OCI einen einfach zu verwendenden DevOps Service, bei dem es sich um eine End-to-End-Plattform für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) für Entwickler handelt. Mit diesem Service können ISVs Software ganz einfach auf OCI entwickeln, testen und bereitstellen sowie Quellcode mit gehosteten, privaten Git-Repositorys verwalten.

Zusammenfassung

Oracle ist sich bewusst, dass alle ISVs eigene Herkunftsgeschichten, Quellumgebungen, technische Architekturen, Deployment-Modelle sowie betriebliche & technische Voraussetzungen mitbringen. Es gibt keinen allgemeingültigen Ansatz für den Wechsel zu Oracle Cloud Infrastructure (OCI), der all diese einzigartigen Faktoren bei der Nutzung der Funktionen von OCI berücksichtigt.

Ein wesentlicher Bestandteil unserer Ansatzes zur ISV-Migration ist die Kombination unseres Interaktionsprozesses, der Architekten, Business Consultants und Fachingenieure vereint, um Sie bei der Entwicklung Ihrer Cloud-Lösung zu unterstützen, mit unseren Cloud Lift Services, mit denen wir gemeinsam Ihre Workloads zu OCI migrieren.

Was Oracle im ISV-Bereich einzigartig macht, ist unsere Bereitschaft und unser Bestreben, mit Kunden auf strategischer, Go-to-Market-, Architektur- und Implementierungsebene in Kontakt zu treten und sie mit unseren Experten zusammenzubringen, um ihre Anforderungen an die Cloud zu erörtern und zu erfüllen.

Erfahren Sie, warum ISVs sich für Oracle Cloud entscheiden