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.
Source: Mehr Cloud, mehr Pain?: Häufige Cloud-Probleme – und wie man sie löst
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.
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.
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.
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.”
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.”
- Michael von der Horst, Cisco
„Soll eine Multifaktor-Authentizierung plattform-übergreifend und sicher sein, dann empfiehlt es sich, nicht die eines SaaS-Anbieter zu nehmen. Sehr oft wird auch die Absicherung des Endgeräts vergessen. Habe ich kein sicheres Endgerät, kann ich in Richtung Cloud Security machen was ich will – letztendlich bleibt ein ungeschützter Angriffsvektor. Zusätzlich ist es hilfreich den Rückkanal für Malware zu blockieren, also den DNS-Layer inhaltlich zu schützen.“ - Roman Hugelshofer, Ergon
„Die Preise der großen Cloud-Anbieter für ihre Security- und IAM-Services sind deshalb so gering, weil man damit einen Lock-in der Kunden erreichen will. Wer plant, seine Apps auf eine andere Plattform zu übertragen, oder eine Mutlicloud-Strategie zu fahren, steht am Ende da wie der Esel am Berg. Meiner Meinung nach ist es zielführender, einen Dienstleister zu wählen, der Lösungen unabhängiger Hersteller in der Cloud für seine Kunden betreibt.“ - Dr. Steffo Weber, ForgeRock
„Bei großen Unternehmen würde ich bei 90 Prozent der Anwendungen immer das Least Privilege in Frage stellen, vor allem für die Absicherung der Arbeitsplätze. Als wir noch alle ins Büro gehen konnten, konnte ich ohne weiteres an den Schreibtisch meines Kollegen gehen. Da war nichts abgesichert. Wenn wir also das Ganze managerbar und handhabbar machen wollen, sollten wir dann nicht einfach von diesen überdimensionierten Least-Privilege-Anforderungen einen Schritt zurück gehen und dies einfacher gestalten? Bei der Cloudifizierung geht es ja auch um eine Vereinfachung von Geschäftsprozessen.“ - Sascha Spangenberg, Lookout
„Sehr oft reichen die von der Firma bereitgestellten Services nicht aus. Es beginnt schon beim Teilen einer Datei über Googledrive zum Beispiel. Hat der Empfänger keinen Account, müsste der Sender die Datei für jedermann im Internet freigeben. Und so werden Tools aus der Schatten-IT genutzt. Wenn also keinerlei Cloud-Tools zur Verfügung stehen, wird allein das Datei-Sharing schon extrem schwierig. Und da reden wir noch gar nicht von Collaboration. An solchen Dingen sehe ich, dass viele die Digitalisierung verpasst haben, während andere bereits Tools wie Slack oder Teams nutzen, mit denen man schön zusammenarbeiten kann.“ - Alexander Häußler, TÜV Süd
„Education ist eines der Kernthemen. Der Mangel an Spezialisten ist ein großes Problem, das wir mit der Cloud zum Teil zu lösen versuchen. Ganz nach dem Motto: Wir haben nicht die richtigen Leute, also schieben wir es in die Cloud, dann kümmert sich jemand darum. Dass man diesen Leuten aber auch auf die Finger sehen oder sagen muss, was man eigentlich braucht, um die Daten sicher zu machen, wird übersehen. Und so macht man die Fehler, die man früher im Office-Umfeld gemacht hat, nun in der OT und in der Cloud. Wir scheinen nicht aus den Fehlern gelernt zu haben, die uns die Vergangenheit gezeigt hat.“ - Andreas Müller, Vectra
„Früher war der Gedankenweg: ich baue eine große Mauer und dann passt alles. Bildlich gesprochen sind die Angreifer aber einfach aussen herum gelaufen. Das funktionierte, weil hinten meist ein Tor offen stand. Das ist der große Gedankenfehler, den wir auch heute immer noch machen. Diejenigen, die jetzt für die Cloud Security zuständig sind, stammen aus der selben alten Denke. Deshalb liegt die große Herausforderung genau darin, diese überholte Denkweise über Bord zu werfen und neu anzufangen. Security ist ein geschäftskritischer Prozess. Diese Erkenntnis muss in den Unternehmen ankommen. Erst dann kann man sich um die individuell richtige Antwort auf das Warum, Was und Wie kümmern. Auch weil es technologisch nicht die eine Standardauskunft für alle Gegebenheiten und Eventualitäten gibt.“ - Arno Edelmann, Verizon
„Viele User nutzen Cloud-Dienste auf dem Desktop. Und so ist bei vielen Firmen die Cloud bereits da, obwohl es die Kollegen nicht wissen. Dementsprechend muss ich das ins Kalkül nehmen, bevor ich überhaupt den Weg in die Cloud beschreite. Skandinavien ist uns bei der Cloud-Adaption und bei der Planung um Lichtjahre voraus. Gerade bei Kollegen in Finnland und Norwegen sehe ich Dinge, die ich in der Form in Deutschland selbst bei sehr großen Firmen nur selten finde.“ - André Röhrich, q.beyond AG
„Nachdem man sich darüber im Klaren ist, was man eigentlich schützen will, muss man sich fragen: Können wir das? Wenn nicht, was ist notwendig, damit wir es können? So komisch das auch klingen mag, aber man muss sich fragen, ob die eigene Mannschaft das trotz Aus- und Weiterbildung stemmen kann. Oder kann vielleicht ein externes SOC (Security Operation Center) eine Etappe auf der Cyber-Security-Reise sein, Und das ohne erst fünf Security-Spezialisten einzustellen, die aufgrund des Fachkräftemangels sowieso nicht zu bekommen sind? Denkbar ist auch ein Hybridmodus: die eigenen Mitarbeiter ausbilden und einen Partner dazu nehmen, der einen auf dieser Reise begleitet und die eigenen Mitarbeiter coacht.“
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.
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.
