Mehr Cloud, mehr Pain?

Häufige Cloud-Probleme – und wie man sie löst

25.03.2021
Von 
Oliver Andrew ist ein freiberuflicher Autor und Softwareentwickler mit einer langen Geschichte in den Bereichen Open Source, Datenbanken und Cloud Computing.
Experten schildern die Cloud-Probleme, mit denen sie konfrontiert werden und wie sie diese lösen oder entschärfen.
In der Cloud-Welt gibt es zwar neue Probleme - aber auch bessere Tools.
In der Cloud-Welt gibt es zwar neue Probleme - aber auch bessere Tools.
Foto: Kilroy79 - shutterstock.com

Die Cloud hat den Betrieb von Anwendungen und Diensten in großem Maßstab wesentlich vereinfacht. Doch Cloud Computing bringt auch seine eigenen Probleme mit sich. Eines davon sind die Kosten. In den Zeiten, wo alle Anwendungen im eigenen Rechenzentrum liefen, würde ein aus dem Ruder gelaufener Code lediglich eine schlechtere Performance oder einen Ausfall verursachen. Jetzt aber greift AWS in solch einem Fall tief in Ihre Taschen, stellt Sie auf den Kopf und schüttelt Sie, bis auch der letzte Cent weg ist - die Quittung für den Software-Bug.

Ein anderes Problem: Mittlerweile ist es kinderleicht geworden, Cloud-Datenbanken wie Amazon Kinesis, Azure Cosmos DB oder Google Cloud Bigtable zu nutzen, aber jeder dieser Dienste ist eine Art Einbahnstraße, aus der es fast kein Zurück gibt. Hinzu kommt: Während die Preise für einfache Infrastruktur-Services im Laufe der Zeit gesunken sind, blieben die Preise der Cloud-Anbieter im Allgemeinen konstant (und unverständlich).

Wie soll man angesichts all dieser Komplexität und der Vielzahl an Instanzen die Dinge stabil und sicher halten? Und warum ist meine Kubernetes-Konfiguration so verdammt lang? Die Liste an Problemen ließe sich beliebig fortsetzen. Stattdessen sollen hier Experten zu Wort kommen, die für den Betrieb einiger der wichtigsten Cloud-basierten Dienste im Internet verantwortlich sind. Sie schildern, mit welchen Cloud-Problemen sie konfrontiert werden - und wie sie diese lösen oder zumindest abfedern.

Kostenmanagement in der Cloud

Erinnern Sie sich noch daran, als man dachte, AWS sei billig? Lassen Sie sich nicht täuschen, warnt Marc Sanfaçon, Senior Vice President of Technology und Mitbegründer des kanadischen SaaS-Anbieters Coveo: "Wenn Sie die Hardware in Ihrem Rechenzentrum stehen haben, nutzen Sie sie auch. Sie zahlen für den Strom, aber dann können Sie sie so viel nutzen, wie Sie wollen."

"Aber wenn man ein Unternehmen wie unseres mit mehr als 200 Entwicklern hat", so Sanfaçon weiter, gebe es für diese zwar einige Richtlinien im Unternehmen, wenn sie sich ein neues Telefon oder einen Schreibtisch oder einen Stuhl kaufen möchten. Aber die Entwickler könnten sich tatsächlich umdrehen und in AWS eine neue Maschine hochfahren, die das Unternehmen 25 Dollar pro Stunde kostet, und diese dann einen Monat lang durchgehend laufen lassen. Am Ende des Monats denkt man dann: "Oh mein Gott, das ist eine Menge Geld."

Als Konsequenz schaltet Coveo jetzt Cluster oder Instanzen ab, wenn niemand an ihnen arbeitet, etwa von 8 Uhr abends bis 6 Uhr morgens und an den Wochenenden. Allerdings muss die Company auch Rücksicht auf den Entwickler nehmen, der um 2 Uhr nachts mit einer Inspiration aufwacht und anfängt, daran zu arbeiten.

Bei Coveo gibt es daher bereits jemanden, der drei Viertel seiner Zeit an der Optimierung der Cloud-Kosten arbeitet. Wie Sanfaçon feststellt, gibt es jedoch bereits ein paar FinOps-Unternehmen, deren Produkte bei der Verwaltung und Optimierung von Kosten helfen. Beispiele für Tools, um die Cloud-Ausgaben zu kontrollieren, seien etwa Cloudability und CloudHealth.

Cloud-Unabhängigkeit bewahren

Sanfaçon berichtet von einem weiteren Cloud-Problem, mit dem Coveo zu kämpfen hat: Die Funktionstüchtigkeit seiner Services aufrechtzuerhalten, wenn Amazons Dienste ausfallen.

"Kurz vor dem Black Friday hatte AWS zwei größere Vorfälle mit Kinesis, einem der Dienste, die Coveo nutzt, der aber zugleich auch das Backbone vieler anderer AWS-Services darstellt", so Sanfaçon. Der Ausfall hatte zwar keine Auswirkungen auf die zentralen Services von Coveo, beeinträchtigte aber die Fähigkeit, neue Kunden aufzunehmen und einige Arten von Ereignissen aufzuzeichnen. Coveo ist ein Suchunternehmen, und in den Wochen um den Black Friday herrscht bei vielen E-Commerce-Kunden Hochbetrieb.

Der Manager zog daraufhin in Erwägung, einen eigenen Streaming-Dienst für Coveo zu hosten. So beunruhigend der Ausfall von Amazon Kinesis auch war - es stellte sich die Frage, ob Coveo kostengünstig einen besseren Messaging-Dienst mit mehr Betriebszeit als AWS betreiben könnte. Und selbst wenn - wäre das eine effektive Nutzung der Ressourcen?

Eine weitere Überlegung war: Wenngleich es viele Vorteile hat, einen speziellen Service von einem Cloud-Service-Provider zu nutzen, bedeutet dies im Umkehrschluss, dass man nicht einfach zu einem anderen Anbieter wie Google Cloud oder Microsoft Azure wechseln kann, so Sanfaçon. Eine mögliche Lösung ist die Nutzung von Amazon Managed Streaming for Kafka. Damit könnte Coveo im Falle eines Problems einfach auf das verwaltete Kafka von Azure, Azure HDInsight, oder Confluents Managed Kafka on Google Cloud umsteigen.

Die Cloud-Unabhängigkeit hat allerdings ihren Preis, denn der Betrieb von Amazon Kinesis ist günstiger als der Betrieb von Amazons Managed Streaming for Kafka. Dennoch gibt es auch Vorteile - vor allem, wenn vor dem Black Friday oder während einer Pandemie etwas ausfällt und Sie das Such-Backbone für viele E-Commerce-Seiten sind.

Saravana Krishnamurthy, Vice President of SkySQL Product Management bei MariaDB, rät ebenfalls davon ab, sich auf eine spezifische Cloud zu verlassen. Sein Tipp: "Wenn Sie eine REST-API oder eine andere API in Ihre Lösung eingebaut haben, stellen Sie sicher, dass die gesamte Kommunikation über diese Cloud-unabhängigen APIs läuft." Auf diese Weise sei es einfacher, beim Wechsel von Amazon zu Google oder Azure Anwendungen und Daten zu übertragen, so Krishnamurthy.

Anbieter-Unterschiede bei Multicloud

Jim Walker, Vice President of Product Marketing bei Cockroach Labs, weist darauf hin, dass die Cloud-Anbieter alle ein wenig anders vorgehen. Cockroach Labs hat seinen Datenbankdienst CockroachCloud sowohl auf AWS als auch auf Google Cloud aufgebaut und dabei viel über die Unterschiede gelernt. "Die Dienste sind im Grunde genommen völlig unterschiedlich, was für uns einen erheblichen Aufwand bedeutet, die Nutzererfahrung in jedem der beiden Systeme 'richtig' zu gestalten", so Walker. "Container und Kubernetes haben uns definitiv geholfen, einen Teil der Komplexität zu vereinfachen, aber wir mussten diese immer noch stark an die jeweilige Plattform anpassen.

Zum Beispiel sei der von Kubernetes verwaltete Service in jeder Cloud sehr unterschiedlich, und auch die Netzwerkkomplexität sei völlig anders, erklärt der Manager. "Die Art und Weise, wie wir mit Load Balancern arbeiten, ist in beiden nicht dieselbe. Außerdem können wir in der einen die IOPS anpassen und einstellen, in der anderen nicht. Wenn wir eine Funktion wie VPC [Virtual Private Cloud] Peering für unsere Kunden bereitstellen, ist der Ansatz in beiden (AWS PrivateLink vs. Vanilla) ebenfalls völlig unterschiedlich." Sein Fazit: "Die Cloud-Anbieter sind von großem Wert, aber sie erfordern auch eine Menge Arbeit."

Cloud Security integrieren

MariaDB-Manager Krishnamurthy betont außerdem die Bedeutung der Netzwerksicherheit in der Cloud. "Wir wollen nicht, dass der Datenverkehr eines Kunden einen anderen Kunden stört", so Krishnamurthy. "Wenn also ein Kunde eine Virtual Private Cloud benötigt, in der er den Datenverkehr vom öffentlichen Netzwerk und von anderen Kunden isolieren möchte, bieten wir VPC als Möglichkeit zur Isolierung an."

Das kann jedoch kompliziert werden, wenn jemand beispielsweise Active Directory als Standard nutzt und sich zwischen den VPCs authentifiziert. In einem solchen Fall erfordert dies eine mühsame Konfiguration und das Zuordnen von Richtlinien zu Rollen zwischen den Systemen.

Komplexität, Konfiguration und Compliance

Selbst die Konfiguration von wenigen Servern und diese konsistent zu halten ist eine Herausforderung. Das Versprechen von DevOps war, den Betrieb und die Bereitstellung zu vereinfachen, aber die Konfigurationen verändern sich. Außerdem ist es schwer zu erkennen, "wer" die Konfiguration geändert hat, wenn sie in einer Reihe von Skripten existiert und für potenziell Hunderte von Servern gilt. Für einige Branchen, insbesondere Finanzdienstleistungen, ist das Fehlen eines Audit-Trails ein echtes Problem für die Einhaltung von Vorschriften.

Eine Lösung stellt ein neues Set an Technologien und Methoden namens GitOps dar. Wie der Name schon sagt, kombiniert GitOps das Versionierungs-Tool Git mit DevOps. Doch GitOps ist mehr als das. Es macht auch die Konfiguration deklarativ und misst gleichzeitig den Drift. Außerdem unterhält Git einen Audit-Trail. Wer also hat die Security ausgeschaltet? Sie können diese Frage beantworten, indem Sie sich das Repo ansehen.

Auch wenn der Spruch "Mo servers, mo problems" nach wie vor seine Berechtigung hat: Sie können mit FinOps kosteneffizient bleiben, mit GitOps die Komplexität bekämpfen, Ihre Software vor dem Ausfall eines einzelnen Anbieters bewahren, indem Sie sie in einer Multi-Cloud betreiben, und die Sicherheit und den Datenschutz Ihres Systems aufrechterhalten, indem Sie Ihre Dienste in Ihrer eigenen VPC isolieren.

Vorbei sind die Zeiten, in denen man sich toll fühlte, weil man CVS verwendet, um seine Unix-Konfigurationsdateien einzuchecken - und jeder Unix-Administrator, der das tat, hielt sich für besonders toll. In der Cloud-Welt haben wir mehr Server und mehr Probleme, aber auch bessere Tools. (mb)

Dieser Artikel basiert auf einem Beitrag der US-Schwesterpublikation Infoworld.