Share via

Antimuster für Cloud Readiness

  • Artikel

Kunden sehen sich während der Bereitschaftsphase einer Cloudeinführung oftmals Antimustern ausgesetzt. Diese Antimuster können zu unerwarteten Ausfallzeiten, Problemen bei der Notfallwiederherstellung und Verfügbarkeitsproblemen führen.

Antimuster: Annahme, dass veröffentlichte Dienste für die Produktion bereit sind

Da sich Cloud Computing schnell weiterentwickelt, veröffentlichen Unternehmen oftmals Vorschauversionen von neuen Diensten. Kunden neigen zu der Annahme, dass sie jeden verfügbaren Clouddienst in einer Produktionsumgebung einsetzen können. Aber dabei können Probleme auftreten, aus diesen Gründen:

  • Vorschaudienste bieten in der Regel keine SLAs (Service Level Agreements) zur Betriebszeit.
  • Neue Dienste sind oftmals nicht so ausgereift wie Clouddienste, die bereits verfügbar sind.

Beispiel: Verwenden eines Vorschaudiensts in der Produktion

Ein Forschungsinstitut verwendet die Vorschauversion eines Clouddiensts als Produktionsumgebung. Der Dienst eignet sich anscheinend sehr gut für den Anwendungsfall. Das Institut kommt aber seiner technischen Sorgfaltspflicht im Hinblick auf den Dienst nicht nach. Darüber hinaus folgt das Institut nicht den Anforderungen seiner Referenzarchitektur und ihren Richtlinien.

Es treten Probleme mit dem Vorschaudienst auf, die zu unerwarteten Ausfallzeiten führen. Das Institut gelangt zu der Überzeugung, dass Clouddienste allgemein nicht so ausgereift oder resilient sind wie versprochen.

Bevorzugtes Ergebnis: Verwenden zuvor genehmigter Clouddienste in der Produktion

Wenn Sie neue Dienste beurteilen, die sich in der Vorschauphase befinden, verwenden Sie diese Dienste nur in POC-Szenarien (Proof-of-Concept). Verwenden Sie diese Dienste nicht in Produktionsumgebungen, da sie keine SLAs bieten. Finden Sie bei der Genehmigung von Cloud-Diensten das richtige Gleichgewicht zwischen Funktionalität und Reife. Ein bewährtes Framework, das Sie für die schnelle Beurteilung von Clouddiensten verwenden können, finden Sie unter Checkliste zur Kaufprüfung von Clouddiensten.

Antimuster: Annahme einer höheren Resilienz und Verfügbarkeit

Cloud Computing bietet im Vergleich zum lokalen Computing oftmals Vorteile. Beispiele:

  • Höhere Resilienz: Wiederherstellung nach einem Fehler.
  • Verfügbarkeit: Betrieb in einem fehlerfreien Status ohne erhebliche Ausfallzeiten.

Da die meisten Clouddienste diese Vorteile bieten, nehmen viele Unternehmen an, dass alle Clouddienste standardmäßig Resilienz und hohe Verfügbarkeit bieten. In Wirklichkeit sind diese Features häufig nur mit zusätzlichen Kosten und zusätzlichem technischem Aufwand verfügbar.

Beispiel: Annahme von Hochverfügbarkeit

Ein Start-Up implementiert eine unternehmenskritische Anwendung mit IaaS-Diensten (Infrastructure-as-a-Service). Entwickler im Start-Up haben einen virtuellen Computer (VM) mit einer Betriebszeit-SLA von 99,9% untersucht. Da sie Kosten senken möchten, verwenden sie einen einzelnen virtuellen Computer und Storage Premium.

Als die VM ausfällt, kann ihre Anwendung nicht wiederhergestellt werden. Das Ergebnis sind unerwartete Ausfallzeiten. Sie sind davon ausgegangen, dass Hochverfügbarkeit in der Cloud standardmäßig angeboten wird. Es war ihnen nicht bewusst, dass sich die Leistungsgarantien zwischen diesen verschiedenen Punkten unterscheiden können:

  • Dienstmodellen wie Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS).
  • Technischen Architekturen wie Verfügbarkeitsgruppen mit Lastenausgleich und Verfügbarkeitszonen.

Bevorzugtes Ergebnis: Reduzieren von Ausfällen bei einem ausgewogenen Verhältnis von Resilienz und Kosten

Informationen zu bewährten Architekturmethoden, die den Umfang von Ausfällen verringern können, finden Sie in vertrauenswürdigen, bewährten Ressourcen:

Bestimmen Sie das richtige Gleichgewicht zwischen Kosten und Features wie etwa hoher Resilienz und Verfügbarkeit. Höhere Resilienz und Verfügbarkeit führen in der Regel zu höheren Kosten. Beispiel:

  • Eine einzelne VM verfügt möglicherweise über eine SLA mit einer garantierten Betriebszeit von 99,9 %.
  • Zwei virtuelle Computer, auf denen dieselbe Arbeitsauslastung ausgeführt wird, bieten dann eine SLA mit einer Betriebszeit zwischen 99,95 und 99,99 %.

Schalten Sie sich in den unerlässlichen Prozess des Anforderungs-Managements (Requirements Engineering) ein, wenn Sie eine cloudbasierte Lösung entwerfen. Verwenden Sie einen SLA-Schätzer, um die End-to-End-SLA Ihrer Anwendung zu berechnen.

Antimuster: Selbst zum Cloudanbieter werden

Einige Unternehmen versuchen, ihre interne IT-Abteilung zu einem Cloudanbieter zu machen. Die IT-Abteilung wird dann für Referenzarchitekturen zuständig. Darüber hinaus muss die IT den Geschäftseinheiten IaaS und PaaS zur Verfügung stellen. Da diese Art Arbeit normalerweise nicht zu den Kernkompetenzen der IT gehört, können den sich ergebenden Dienstangeboten die erforderliche Nutzbarkeit, Resilienz, Effizienz und Sicherheit fehlen.

Beispiel: Bereitstellen monolithischer verwalteter Clouddienste

Die IT-Abteilung eines Unternehmens richtet ein Cloudkompetenzzentrum (Cloud Center of Excellence, CCoE) ein, das als Makler zwischen IT und Geschäftseinheiten fungiert. Um sicherzustellen, dass das Unternehmen cloudkompatibel ist, weist der Vorstand dem CCoE die Aufgabe zu, monolithische End-to-End-Dienste bereitzustellen. Das CCoE richtet ein internes Cloud-Beschaffungsportal ein, das von Geschäftseinheiten verwendet werden kann, um eine vollständig verwaltete Cloud-VM als Dienst zu bestellen. Aber die IT steuert, wer Zugriff auf die gesamte Plattform hat und sie nutzen kann. Das hat zur Folge, dass die IT Geschäftseinheiten aktiv daran hindert, den ganzen Bereich von Diensten zu nutzen, die Azure zur Verfügung stellt. Geschäftseinheiten können nicht auf das Cloud-Portal zugreifen. Sie erhalten lediglich Zugriff per Secure Shell (SSH) und Remotedesktopprotokoll (RDP) auf den bestellten Server.

Aus verschiedenen Gründen hat das CCoE dann Probleme, einen monolithischen verwalteten Dienst für das Umschließen jedes Diensts bereitzustellen, der in der Cloud verfügbar ist:

  • Die Cloud bietet eine große Anzahl von Diensten über mehrere Lösungsbereiche. Verglichen mit der Entwicklung von IaaS-Lösungen erfordert das Entwerfen und Entwickeln von IoT- (Internet der Dinge) und KI-Lösungen ganz andere Kompetenzen und Qualifikationen.
  • Clouddienste ändern sich häufig.
  • Der Versuch, monolithische Dienste bereitzustellen, verlängert die Markteinführungszeit erheblich, wenn IT anstelle der Geschäftseinheiten den Prozess verwaltet.

Bevorzugtes Ergebnis: Bereitstellen von Vorgaben

Lassen Sie bei der Einführung von Cloudtechnologien die IT-Abteilung Clouderfahrung aus erster Hand gewinnen, indem Sie mit IT-Workloads anfangen. Verwenden Sie das Microsoft Cloud Adoption Framework für Azure, um Ihr erstes Einführungsprojekt festzulegen.

Verwenden Sie ein ausgereiftes Cloudbetriebsmodell, wie etwa zentralisierte betriebliche Abläufe, das der IT Zuständigkeit für die Definition von Vorgaben wie Governance für die Plattform gibt. Anschließend können Geschäftseinheiten Cloudprojekte auf sichere und konsistente Weise innerhalb der von der IT definierten Vorgaben einführen.

Erwägen Sie, zu Beginn nur einen größeren öffentlichen Cloudanbieter einzusetzen, da sich alle größeren Plattformen erheblich in Setup, Verwaltung und Nutzung unterscheiden.

Verwenden Sie soweit wie möglich SaaS-Lösungen für IT-Tools, wie z. B.:

  • Coderepositorys
  • Continuous Integration und Continuous Delivery (CI/CD)
  • Kollaborationssysteme

Weisen Sie IT an, für Cloudworkloads vertraute Prozeduren zu verwenden, die sicher funktionieren und sich skalieren lassen.

Nächste Schritte