6 Aspekte für die Überlegung GCP vs. AWS
Ja, schon wieder eine Liste mit zehn Eigenschaften, Vorteilen oder Merkmalen, bla, bla, bla. Ich bin selbst kein Fan dieser Art von Artikeln. Vor Kurzem wurde ich von einem Unternehmen zu einem anderen versetzt und musste infolgedessen fast meine gesamte Cloud-Arbeit von AWS auf GCP umstellen. Ich muss sagen, dass dieser Weg bisher sehr aufregend war. Daher habe ich mich entschlossen, auf einige Aspekte hinzuweisen, in denen sich diese beiden Plattformen unterscheiden. Ich hoffe, dass dies für andere von Nutzen ist.
Bitte behalte im Hinterkopf, dass ich diesen Text Mitte 2020 verfasse – manches mag sich also ein wenig geändert haben, wenn du diesen Beitrag liest. Außerdem möchte ich betonen, dass es sich hierbei um meine Erkenntnisse für die aktuelle Situation handelt. Deine eigenen können völlig anders ausfallen, und meine können für dich irrelevant sein. Korrigiere mich einfach in der Kommentarspalte. Ich lasse mich gerne eines Besseren belehren!
Was GCP fehlt ... und mir auch
Ich möchte mit einem der offensichtlichsten Aspekte beginnen, die ich bei GCP vermisse: die erstaunliche Bandbreite an Services, die man mit AWS nutzen kann! Dies möchte ich gerne erläutern:
Nehmen wir an, du möchtest einen einfachen Elasticsearch-Dienst verwenden. Nichts Ausgefallenes, keine Plugins. Der Kunde ist bereit, für den Dienst zu bezahlen, da er weiß, dass deine Zeit an anderer Stelle für Wesentlicheres genutzt werden kann. Mit GCP? Pech gehabt.
Der korrekte Weg wäre es, deine App zu analysieren und andere GCP-Dienste zu nutzen. Wenn du jedoch Elasticsearch verwenden möchtest, müsstest du deine GCE-Instanzen bereitstellen und warten. Hier findest du ein Terraform-Repository, in dem genau das implementiert ist: https://github.com/AckeeCZ/terraform-gcp-elasticsearch. Es zeigt, dass wir mit genau diesem Problem zu kämpfen haben – und das ist nur eines von vielen Beispielen.
Mir ist klar, dass das Elasticsearch von AWS nicht dasselbe ist wie das von dir verwaltete Elasticsearch. Dem Dienst fehlen viele Plugins, und er ist für kleine Projekte relativ teuer. Ich vermute, der Hauptgrund dafür, dass der Dienst nicht so offen für jegliche Benutzereinstellungen ist, ist die Einhaltung der sehr anspruchsvollen SLA-Richtlinien von AWS.
Doch, seien wir ehrlich – wer würde nicht lieber auf einige Plugins verzichten, um die Gesamtstabilität der Anwendung zu erhöhen? Und außerdem ist Elasticsearch nicht der einzige eingeschränkte Service in AWS. Viele Funktionen in MySQL AWS Aurora sind ebenfalls deaktiviert oder von anderen Funktionen abgebildet, die von Nicht-Root-Benutzern aufgerufen werden könnten. Über die Gründe kann ich nur Vermutungen anstellen. Wahrscheinlich liegt es auch hier an einem sehr strengen SLA.
Fehlender Dienst? Die Entscheidung liegt bei dir
Als Architekt solltest du die Entscheidung darüber treffen, ob ein fehlender Dienst ein Problem für deine App darstellt. Wenn ja, wechselst du zum allmächtigen AWS mit all seinen Problemen oder verbringst mehr Zeit mit der Analyse deiner App. Möglicherweise hast du in der Architektur einige falsche Entscheidungen getroffen und solltest stattdessen bei der Anpassung deiner App einen anderen GCP-Dienst verwenden. Um diesen ersten Punkt zusammenzufassen: Wenn ein Dienst, mit dem du arbeiten möchtest, in GCP fehlt, ist es gut möglich, dass du einen Fehler gemacht hast. Lässt sich deine Anwendung für GCP-Dienste zurechtbiegen, dann ist es an der Zeit, AWS zu nutzen.
Das zweite Problem, das ich bei der Migration von einer Cloud zur anderen entdeckt habe, ist der Unterschied zwischen den Namen der Datensätze, in denen deine Ressourcen enthalten sind. Bei AWS befinden sich deine Ressourcen im Konto, während es bei GCP Projekte gibt. Meiner Meinung nach sind Projekte sehr viel sinnvoller als Konten. Es hängt jedoch alles vom Blickwinkel ab, aus dem du deine Infrastruktur betrachtest. Wenn du per Lift and Shift zu AWS wechselst, sind deine Server wahrscheinlich Pets, die von dem Unternehmen finanziert werden, dem sie gehören. Das ist natürlich durchaus sinnvoll. Dein Konto wird gehegt und gepflegt. Wenn du eine App entwickelst, die schnell bereitgestellt und noch schneller wieder verworfen werden soll, brauchst du kein Konto mit all seinen Abrechnungsdaten und seiner Einzigartigkeit; du hast ein Projekt.
Stellen wir uns einmal ein verrücktes Szenario vor: Du hast ein Konto. Für das Konto gibt es Abrechnungsdaten. Es gehört nicht zu einer Organisation. Dein Terraform-Code ist fürchterlich. Er neigt dazu, Ressourcen ohne zufälliges Postfix zu benennen, sodass jede Vervielfältigung zu Dubletten der Ressourcen führt, die nicht erstellt werden konnten. Also hast du dich klugerweise und zu Recht für einen (regionalen) Workaround entschieden und die Entwicklungsumgebung nach Frankfurt, das Staging nach London und die Produktion nach Irland verlegt. Super! Du wärst überrascht, wie oft das vorkommt. Anstatt mehrere Konten (oder Projekte) anzulegen, wird einfach immer wieder zwischen den Regionen gewechselt. Bei GCP ist die Terminologie in diesem Fall viel sauberer. Du hast verschiedene Projekte, und das war’s. Du möchtest eine Produktionsumgebung? Kein Problem; setze sie einfach in einem anderen Projekt ein und verknüpfe sie mit dem richtigen Abrechnungskonto.
Unterschiedliche Identitäten, unterschiedlicher Flow
Wenden wir uns den Unterschieden im wichtigsten Service der Cloud zu – AWS IAM vs. GCP IAM. Zunächst möchte ich etwas klarstellen: GCP IAM ist nicht gleich IAM, und dafür gibt es einen einfachen Grund: GCP IAM stellt keine Identitäten bereit. Es nutzt Identitäten der G Suite oder von einem anderen E-Mail-Anbieter. Und es gibt noch etwas, auf das ich bei GCP hinweisen möchte: Dienstkonten. Du hast wahrscheinlich schon erraten, dass diese Konten zur Identifizierung der Dienste verwendet werden (was übrigens äußerst sinnvoll ist).
Bei AWS gibt es natürlich etwas Ähnliches; es nennt sich Rollen. Achtung – der Flow ist ein wenig anders. Ein Beispiel: Bei AWS weist du einer EC2-Instanz eine Rolle zu. Die Instanz-ID identifiziert die Instanz. Die Rolle enthält Berechtigungen, die von der Instanz übernommen (festgelegt) werden. In GCP GCE weist du der Instanz ein Dienstkonto zu. Das Konto identifiziert die Instanz. Das Dienstkonto hat zugewiesene Berechtigungen. Sicherlich hast du bemerkt, dass es offensichtlich einige Probleme mit der Terminologie gibt. Dienstkonten sind sehr viel sinnvoller. Das Problem verschärft sich jedes Mal, wenn die Clouds bei einem gemeinsamen Dienst kollidieren:
- In AWS gibt es K8s-Cluster, die auch Dienstkonten enthalten.
- In der K8s von GCP wird das etwas einfacher, und normalerweise werden die Dienstkonten auf IAM-Dienstkonten abgebildet.
Doch das ist noch nicht alles. Wir dürfen nicht vergessen, dass GCP-Instanzen fast immer ein Standard-Dienstkonto haben, im Gegensatz zu EC2-Instanzen, die nicht über Standardrollen verfügen. Ein Kinderspiel, oder? Noch während ich diesen Absatz schreibe, bin ich mir sicher, dass meine Terminologie nur teilweise korrekt ist. Diese Verwirrung könnte für neue Nutzer irreführend sein.
Wenn du mehr Pods benötigst, machst du vermutlich etwas falsch
Und nun dürfen wir natürlich auch nicht den meistgehypten Dienst der letzten Jahre vergessen – mir kann das jedenfalls nicht passieren... AWS K8s nennt sich EKS, und GCP K8s nennt sich GKE. Ehrlicherweise wurde K8s hauptsächlich von Google entwickelt, daher ist es unfair, GKE mit dem etwas jüngeren EKS zu vergleichen. Auch muss ich dazu sagen, dass die Lage bei EKS von Tag zu Tag besser wird. Ich hatte nur das Pech, dass ich meine K8s-Reise mit EKS beginnen musste, als es damals gerade auf den Markt kam.
Das erste Problem, auf das ich stieß, war das Netzwerk-Overlay, da es keines gab. Wir haben vier kleine Nodes eingesetzt, um das Ganze zu testen. Um die Funktionsweise von EKS zu überprüfen, haben wir zudem etwa hundert Pods eingesetzt. Überraschung, Überraschung – so gut wie jeder Pod war ausstehend und nicht belegbar. Natürlich war unser Szenario unklug. Niemand sollte es so machen wie wir. Die Anzahl der Nodes und ihre Kapazität sollten den Anforderungen der in den Pods ausgeführten Microservices entsprechen. Daher sollte die Anzahl der IP-Adressen auch die Kapazität und Anzahl der Nodes widerspiegeln.
Man darf zudem nicht übersehen, dass ein Pod nur eine IP-Adresse haben kann und AWS standardmäßig kein Netzwerk-Overlay aktiviert. Du hast nur so viele IP-Adressen zur Verfügung, wie dein Instanztyp zulässt. In unserem Fall waren es etwa zehn IP-Adressen. Den schlimmsten Fall könnten die Beschränkungen in der horizontalen Skalierung darstellen. Wenn dir die Instanzen ausgehen, gehen dir später auch die IP-Adressen aus, und die Skalierung wird angehalten.
Versuche einmal, das einem Kundendienstmitarbeiter im Bereitschaftsdienst zu erklären, der mitten in der Nacht nicht hochskalieren kann, weil ein anderer Namensraum alle verfügbaren IP-Adressen im Cluster belegt hat. Der Punkt und mein Hinweis an dich ist, dass die Verwendung eines nativen AWS-Netzwerk-Overlays zum Problem werden kann. Es hat auch seine Sternstunden, doch zum Testen und Entwickeln solltest du einfach Calico verwenden.
Kein gesunder Umgang mit Health Checks
Eine weitere weniger lustige Eigenschaft der GCP-Cloud ist die Art und Weise, wie die Cloud mit Health Checks umgeht. Mir ist klar, dass Google eine absolut einzigartige Lösung für die Cloud VPC anbietet, und seien wir ehrlich – für uns ist sie selbstverständlich. Man denke nur daran: Die VPC deckt die ganze Welt ab, doch warum müssen die Health Checks von bestimmten Subnetzen aus durchgeführt werden? Ich habe keine Ahnung. Meiner Meinung nach wäre es praktischer, dies vom Load Balancer aus zu erledigen.
Außerdem sind die Subnetze bei l4- und l7-Load Balancern unterschiedlich. Jeder erstellt eine Firewall-Regel mit allen Subnetzen, nur um das zu bewältigen. Das ist absolut nicht ideal. Es wirft eine Menge Fragen auf, die oft von Nachwuchsingenieuren gestellt werden. In einer perfekten Welt würde ich vorschlagen, Health Checks vom Load Balancer aus zu senden – doch mir ist klar, dass dies sehr einzigartig ist. Ich habe Tage gebraucht, um einen einfachen, intern verwalteten Load Balancer zu durchschauen. Es ist nicht so, dass ich keinen in einer Cloud-Konsole erstellen könnte – doch das Erstellen eines funktionierenden Terraform-Codes für einen beliebigen GCP-Load Balancer ist eine Aufgabe für kompetente Ingenieure.
Irreführende Benennung
Ich habe bereits angesprochen, dass sich das IAM in AWS und GCP ein wenig unterscheidet. Was wäre, wenn ich dir sagen würde, dass du in die IAM-Einstellungen gehen musst, wenn du die Quote für eine der GCP-Ressourcen vergrößern möchtest? Komisch, oder? In diesem Fall würde ich sagen, dass AWS viel unkomplizierter ist. Ich bin immer noch der Meinung, dass dies zur billing gehören sollte, nicht zum IAM. Aber das ist wohl eine Frage der Perspektive.
Das Spiel mit dem Wert
Anstatt sowohl über AWS als auch über GCP zu lästern, möchte ich diesen kleinen Artikel lieber damit beenden, was du unbedingt wissen solltest. Der Anwendungsfall bestimmt die Infrastruktur. Der Anwendungsfall selbst definiert eine Vielzahl von Bedingungen, die du beachten solltest. Schreibe sie an eine Tafel, ordne die Dienste zu, die diese Bedingungen erfüllen könnten, und wähle dann klug aus, welchen Weg du gehen möchtest.
Natürlich kannst du deine Architektur heterogen gestalten, und in einigen Anwendungsfällen ist das auch durchaus sinnvoll. Du würdest zum Beispiel gerne die starken Machine-Learning-Services von GCP nutzen, aber es ist dir auch recht, wenn dein React-Frontend auf dem AWS S3-Bucket bleibt.
Eines musst du immer im Kopf behalten: Lohnen sich die Kosten für den Betrieb eines solchen heterogenen Designs im Gesamtwert? Und dabei sprechen wir nicht nur von tagtäglichen Arbeiten wie dem Aktualisieren der Nodes im K8s. Du solltest auch berücksichtigen, wie breit die Wissensgrundlage des Einsatzteams sein muss. Was wir zweifelsfrei festhalten können, ist, dass es günstiger ist, nur einen Cloud-Anbieter zu haben!
