Anti-Patterns in der öffentlichen Cloud

Die Einführung von Public Clouds ist nicht immer einfach und in der Regel ein Kampf, um es richtig zu machen. In den letzten Jahren habe ich in meinem Alltag als Cloud Consultant bei Xebia einige Erfahrungen gesammelt, indem ich Unternehmen beim Umstieg auf die Public Cloud geholfen habe. Ich denke, es ist an der Zeit, einen Teil dieses Wissens mit Ihnen zu teilen.

Nur ein weiteres Rechenzentrum

Beim Start von "Cloud"-Projekten sagen die Leute oft: "Ich kann meine Anwendung auf einer virtuellen Maschine in einer öffentlichen Cloud hosten". Ja, natürlich können Sie das tun. Aber höchstwahrscheinlich wird das nicht die Veränderung bringen, die sich Ihr Unternehmen wünscht. Nach der Migration werden Sie immer noch damit beschäftigt sein, Ihre Anwendung zu betreiben, zu warten und zu debuggen. Es lohnt sich nicht, Zeit und Geld in ein Lift-and-Shift-Projekt zu investieren, da der wirtschaftliche Nutzen höchstens 10 % beträgt und Ihre lokalen Herausforderungen wie Hardwareprobleme, Skalierungsprobleme usw. durch Cloud-bezogene Herausforderungen wie die Speicherung von Status, Sicherheit, dynamische Adressierung, Wissen usw. ersetzt werden. Meistens nennen wir dies "Ihr Chaos für weniger Geld".

Tun: Schauen Sie sich die Dienste des Cloud-Anbieters an. Denken Sie nicht, dass die öffentliche Cloud nur eine Erweiterung Ihres Rechenzentrums vor Ort ist. Cloud-native Services bringen Ihnen den größten Nutzen, wenn es um Fokus, Reife, Skalierbarkeit, Sicherheit und Innovation geht. Nutzen Sie abstrahierte Dienste auf höherer Ebene, wie z.B. Function as a Service (FaaS), verwaltete Datenbanklösungen, Warteschlangendienste, usw., usw.

Tools über Dienstleistungen

Die wahre Stärke eines Cloud-Service-Anbieters liegt in der Anzahl und Vielfalt der von ihm angebotenen Dienste. Wenn Sie einen kurzen Blick auf das Periodensystem von AWS werfen, werden Sie feststellen, dass es rund 170 Services gibt, von Compute bis Game Tech, von Mobile bis Blockchain und von Augmented Reality & Virtual Reality bis Sicherheit. Es gibt fast einen Service für alles und es werden immer mehr. Laut den großen Tech-Giganten ist dies erst der Anfang.

In meiner täglichen Arbeit als Cloud-Berater erlebe ich oft, dass Menschen auf ihre eigenen Tools statt auf einen Cloud-Service setzen. Die Gründe dafür sind: Unkenntnis der Cloud-Services, mangelndes Vertrauen in den Service, Macht der Gewohnheit, Schutz des Arbeitsplatzes oder falsche Versprechungen von Tool-Anbietern. Dieser Fehler wird am häufigsten in den Bereichen gemacht, in denen man dazu neigt, Probleme mit Tools zu lösen, anstatt sich auf die Ziele zu konzentrieren. Wie z.B. Verschlüsselung, Verwaltung von Geheimnissen, Überwachung, Schwachstellen-Scanning, usw., usw.

Aufenthalt: Verwenden Sie Cloud-Dienste in Ihrer Architektur. In den meisten Fällen gibt es einen Dienst, der fast alle Ihre Anforderungen abdeckt. Wenn Sie keinen geeigneten Dienst finden, überdenken Sie Ihre Anforderungen, denn wahrscheinlich machen Sie etwas ganz falsch. Denken Sie an den hohen Aufwand für die Auswahl, den Kauf und den Betrieb Ihrer eigenen Tools. Sie müssen einen sehr guten Grund haben, dies zu tun.

Anwendung allgemeiner Sicherheitskontrollen

Die Risiken, die bei der Ausführung von Anwendungen in der öffentlichen Cloud identifiziert wurden, sind in gewisser Weise vergleichbar mit denen von On-Premises-Workloads, mit ein paar Ergänzungen. Auch wenn die Risiken ähnlich sind, sollte die Lösung, mit der die Risiken gemindert werden, nicht notwendigerweise die gleiche für die öffentliche Cloud und die lokale Umgebung sein. Vorzugsweise nicht. In den meisten Fällen verwenden wir monolithische und teure Lösungen, um unsere Herausforderungen vor Ort zu lösen, wie z.B. Firewall und Proxy, Schlüsselverwaltung und Remote Access Appliances.

Ohne Cloud-Kenntnisse wäre Ihre erste Reaktion wahrscheinlich: Lassen Sie uns eine virtualisierte Version dieser Appliance verwenden, damit wir einen einheitlichen Überblick über unsere Sicherheitslandschaft haben und spezifisches Wissen wiederverwenden können. Leider irren Sie sich. Sie werden bei der Implementierung auf Herausforderungen stoßen, da es an Integration, Orchestrierung, Skalierbarkeit, Verfügbarkeit, Elastizität, hohen Kosten usw. fehlt.

Tun Sie das: Schreiben Sie Ihre Anforderungen so um, dass sie den Output ('was') definieren, lassen Sie die Cloud-Spezialisten das 'wie' entwerfen und erlauben Sie ihnen, neue Ideen einzubringen. Die Anforderung "Die Kundendaten sollten im Ruhezustand und während der Übertragung geschützt werden" wird Ihnen beispielsweise eine wertvollere native Lösung auf der Grundlage von Cloud-Diensten liefern, als wenn Ihre Anforderungen angeben, welches bereits bekannte Tool verwendet werden soll.

Agnostische Architekturen

Dies ist mein Lieblingsthema. Für mich ist dies der größte Marketing-Slogan, der derzeit verwendet wird. Es ist keine Überraschung, dass die Leute glauben, dieser Mythos sei wirklich wahr. Jahrelang haben die Anbieter an ihrem Ruf gearbeitet, indem sie die Lizenzkosten Jahr für Jahr erhöhten, Sie durch unvorhersehbare Produktlebenszyklen zwangen, auf neuere Produkte umzusteigen usw. usw. Dies hat zu etwas geführt, das wir heute "Vendor Lock-in vermeiden" nennen. Viele Anbieter versuchen, Ihnen Tools oder Lösungen zu verkaufen, die das Versprechen erfüllen, dass Sie den Vendor Lock-in tatsächlich vermeiden können. "Wenn mein Cloud-Anbieter die Preise erhöht, kann ich meine Workload-Mobilität nutzen, um meine Anwendung innerhalb von Minuten bei einem günstigeren Anbieter laufen zu lassen". Klingt gut, nicht wahr? Ich habe eine kleine Überraschung für Sie: Jede technische Entscheidung führt zu einem Vendor Lock-in.

Wenn Sie Ihre Anwendung so gestalten, dass sie völlig agnostisch ist, bringt Sie das nicht weiter, außer dass Ihnen mit Sicherheit die Zeit und das Budget ausgehen. Die Wahrscheinlichkeit, dass Anwendungen aufgrund hoher Kosten oder plötzlicher Preissteigerungen von einer Plattform auf eine andere wechseln, ist sehr gering. Diese Risiken können in den meisten Fällen gemildert werden. Bekannte Ausnahmen sind Dropbox und Netflix, die die öffentliche Cloud aufgrund extrem hoher Volumina (teilweise) verlassen haben. Ich gehe nicht davon aus, dass Ihre Anwendungen, bei allem Respekt, jemals diese Größenordnung erreichen werden. Sie können möglicherweise nie einen vernünftigen Business Case für Workload-Mobilität erstellen, wenn Sie die Vor- und Nachteile von Cloud-Native und Agnostic (gemeinsamer Nenner) vergleichen.

Tun: Stellen Sie sicher, dass Ihr Unternehmen vorbereitet ist. Diskutieren Sie nicht über die Angst vor einer Anbieterbindung, sondern über die Wechselkosten Ihrer Anwendung. Ein Beispiel: Wir können diese Anwendung bei Cloud-Anbieter X in vier Sprints entwickeln. Wahrscheinlich können wir dasselbe bei Cloud-Anbieter Y in derselben Zeit oder sogar noch schneller erreichen, da die Innovationsgeschwindigkeit enorm ist und die großen Cloud-Anbieter einander folgen.

Aufbau einer neuen Plattform

Es ist weit verbreitet, dass die Leute denken, dass die öffentliche Cloud nur ein Pool unbegrenzter Rechen-, Netzwerk- und Speicherressourcen ist und dass Sie Ihre eigene Plattform darauf aufbauen müssen. Ja, die Public Cloud bietet grundlegende Ressourcen als Infrastructure is a Service, aber das ist nicht die Art von Service, die Sie wahrscheinlich nutzen möchten. Der größte Vorteil der Public Cloud besteht darin, dass die Cloud-Service-Anbieter immer mehr Dienste für Sie entwickeln. Warum sollten Sie ein eigenes Kraftwerk betreiben, wenn Sie ein Gut wie Strom auch einfach über ein Kabel beziehen können, das zu Ihrem Gebäude führt?

Ich werde mir nicht viele Freunde machen, wenn ich sage, dass IT eine Massenware ist. Die Zeiten, in denen man einen Server zusammenstellen, ihn im Rechenzentrum aufstellen und darauf Linux und eine Oracle-Datenbank installieren musste, sind vorbei. Heute kann jeder, der über ein wenig technisches Wissen, eine Kreditkarte und einen Browser verfügt, eine Datenbank bereitstellen. IT ist Massenware.

Der wirkliche Unterschied liegt in der Geschäftslogik, die Sie auf der Commodity ausführen. Je mehr Sie sich darauf konzentrieren können, eine Logik zu entwickeln, die Ihr Geschäft ermöglicht, desto besser kann sich Ihr Unternehmen abheben. Machen Sie nicht den Fehler zu glauben, dass Ihr Unternehmen andere IT-Anforderungen hat als alle anderen Unternehmen auf diesem Globus. Es macht keinen Sinn, Zeit und Geld in den Aufbau einer Plattform zu investieren, wenn Ihr Cloud Service Provider bereits etwas für Sie aufgebaut hat und weiter aufbaut. Eine Plattform wie OpenShift oder Kubernetes in einer öffentlichen Cloud zu betreiben, ist meist eine schlechte Idee, da sie von den Kernprinzipien des Cloud Service Providers (z.B. IAM und Netzwerkkontrollen) abweicht.

Tun Sie es: Nutzen Sie die vom Cloud-Service-Anbieter bereitgestellten Plattformfunktionen. Glauben Sie nicht, dass Sie es besser machen können. Sie haben einfach nicht die Größe, die sie haben. Nicht, wenn es um das Budget und vor allem nicht um das Wissen geht.

Endzustand Architektur

Das Innovationstempo in der Public Cloud ist schnell, sehr schnell. Die Zahl der neuen Dienste und Funktionen, die jährlich auf den Markt kommen, ist enorm und nimmt jedes Jahr zu. Wenn Sie den Status Quo einige Jahre lang beibehalten können, machen Sie etwas falsch. Neue Funktionen können zu neuen Erkenntnissen über Leistung, Skalierbarkeit, Sicherheit und Kosten führen. Das Pay-per-Use-Modell ermöglicht es Ihnen, zu wechseln, ohne Verträge zu brechen. Agilität.

Aufgrund der Wirtschaftlichkeit der öffentlichen Cloud ist auch die Länge des Lebenszyklus von Workloads sehr flexibel. In traditionelleren Umgebungen war es üblich, langfristige Verträge (4-8 Jahre) abzuschließen. Bei der Cloud basieren die meisten Preismodelle auf dem Pay-per-Use-Modell und werden oft pro Minute, Sekunde oder Sub-Sekunde abgerechnet. Die Abrechnung wird sofort nach Beendigung der Ressource eingestellt. So können Sie kürzere Laufzeiten für Marketingkampagnen und auch sehr lange Laufzeiten für Archivierungszwecke haben.

Tun Sie es: Betrachten Sie Ihre Architektur als eine fortlaufende Version, die ständig verbessert werden sollte. Scheuen Sie sich nicht, Ihr Design oder Ihre Meinung aufgrund der sich ständig verändernden Welt der Public Cloud zu ändern.

Haftungsausschluss: Jede Ähnlichkeit mit tatsächlichen Unternehmen ist rein zufällig. Machen Sie sich keine Sorgen, die hier beschriebenen Herausforderungen sind allgemeiner Natur und treffen in den meisten Fällen zu.