Projekt anfragen
Weitläufige Rechenzentrumshalle mit Doppelboden, Serverschränken und blau gebündelten Netzwerkkabeln unter der Decke

Google Cloud

Google-Cloud-Beratung und GCP-Migration

Ob Sie Workloads nach Google Cloud verlagern oder eine gewachsene Projektlandschaft ordnen wollen: SKAFFON entwirft die Landing Zone, migriert und betreibt, von Organisation und Netzwerk bis GKE und Cloud SQL.

Projekt anfragen Landing-Zone-Workshop ansehen
  • Landing Zone als Code (Terraform oder OpenTofu)
  • Entscheidungen vorab als Workshop-Ergebnis dokumentiert
  • Betrieb auf Wunsch aus einer Hand

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Für CTOs und Platform-Teams

Google Cloud lohnt sich bei Containern, Daten und Google-Diensten

Die Plattform passt, wenn Ihre Workloads stark auf Container und Datenverarbeitung ausgerichtet sind, wenn bestimmte Google-Dienste benötigt werden oder wenn Landschaft und Team schon dort liegen. Typisch sind Daten- und Container-Workloads, die auf Google Kubernetes Engine (GKE) und verwalteten Datenbanken wie Cloud SQL laufen sollen.

Bei strengen Vorgaben zu Datenstandort und Betreiberkontrolle vergleichen Sie zuerst Alternativen: Cloud-Übersicht, STACKIT, souveräne Cloud.

02Beispielstruktur

Organisation, Ordner, Projekte und Netz auf einen Blick

Die Ressourcenhierarchie mit Organization Policies und das Shared-VPC-Netz je Umgebung samt VPC-Service-Controls-Perimeter um sensible Projekte.

Beispielstruktur einer Google-Cloud-Landing-Zone Links die Ressourcenhierarchie Organisation, Ordner, Projekte mit Organization Policies. Rechts Shared-VPC mit Service-Projekten, Cloud NAT, Cloud DNS, Anbindung ans Kundennetz und VPC-Service-Controls-Perimeter. Ressourcenhierarchie Netzwerk je Umgebung Organisation Organization Policy Ordner: Plattform Ordner: Produktion Ordner: Nicht-Produktion Ordner: Sandbox Organization Policy Projekt: Netzwerk (Host) Projekt: Logging, Monitoring Projekt: Anwendung A Projekt: Anwendung A VPC-Service-Controls-Perimeter um sensible Projekte Shared-VPC-Host-Projektje Umgebung (Produktion, Entwicklung, Test) Service-Projekt 1 Service-Projekt 2 Service-Projekt 3 Cloud NAT Cloud DNS Firewall-Regeln Kundennetz Interconnect oder VPN Beispielstruktur, an Ihre Organisation anzupassen.
Beispielstruktur, im Workshop an Ihre Organisation anzupassen.
Beispielstruktur einer Google-Cloud-Landing-Zone Oben die Ressourcenhierarchie Organisation, Ordner, Projekte mit Organization Policies. Darunter Shared-VPC mit Service-Projekten, Cloud NAT, Cloud DNS, Anbindung ans Kundennetz und VPC-Service-Controls-Perimeter. Ressourcenhierarchie Organisation Organization Policy Ordner: Plattform Ordner: Produktion Ordner: Nicht-Produktion Ordner: Sandbox Organization Policy Projekt: Netzwerk (Host) Projekt: Logging, Monitoring Projekt: Anwendung A Projekt: Anwendung A Netzwerk je Umgebung VPC-Service-Controls-Perimeterum sensible Projekte Shared-VPC-Host-Projekt je Umgebung(Produktion, Entwicklung, Test) Service-Projekt 1 Service-Projekt 2 Service-Projekt 3 Cloud NAT Cloud DNS Firewall-Regeln Interconnect oder VPN Kundennetz Beispielstruktur, an Ihre Organisation anzupassen.
Beispielstruktur, im Workshop an Ihre Organisation anzupassen.

03Workshop-Katalog

Sieben Entscheidungen bis zur Landing Zone

Google nennt in der Dokumentation zum Landing-Zone-Design vier Kernelemente: Identitätsbereitstellung, Ressourcenhierarchie, Netzwerk und Sicherheitskontrollen. Eine einzige Standardumsetzung gibt es laut Google nicht; die Entscheidungen hängen von Branche, Organisation, Compliance, Workloads und Bestand ab. Unser Workshop arbeitet die Felder in dieser Reihenfolge ab, jeweils mit einem Ergebnisartefakt.

  1. 01

    Wer darf was, auf welcher Ebene?

    Identität

    Wie werden Ihre Benutzer und Gruppen bereitgestellt (Cloud Identity, Synchronisation mit Ihrem bestehenden Identitätsanbieter)? Wer erhält welche IAM-Rollen auf welcher Ebene? Ergebnis: Rollenmodell mit Gruppen statt Einzelrechten.

  2. 02

    Wie schneiden wir Organisation, Ordner und Projekte?

    Hierarchie

    Umgebungen, Teams und Anwendungen bekommen ihren Platz; dazu klären wir, wo Organisationsrichtlinien (Organization Policies) greifen. Ergebnis: Hierarchieentwurf mit Richtlinienzuordnung je Ebene.

  3. 03

    Adressplan und Anbindung an Ihr Netz

    Netzwerk

    IP-Adressbereiche je Umgebung, Shared VPC und die Verbindung zu Ihrem Standort oder Rechenzentrum. Ergebnis: Adressplan und Konnektivitätskonzept (Details im Abschnitt zur Anbindung).

  4. 04

    Braucht Ihr Datenschutz-Ziel einen Perimeter?

    Sicherheit

    Perimeter mit VPC Service Controls schützen gegen Datenabfluss. Ergebnis: Perimeter-Entwurf und Ausnahmeprozess.

  5. 05

    Monitoring, Backup und Kosten im Blick

    Betrieb

    Monitoring und Logging, Backup und Wiederherstellung, Kostenkontrolle. Ergebnis: Betriebskonzept.

  6. 06

    Eine Landing Zone oder mehrere, und womit beginnen?

    Umfang

    Braucht es mehr als eine Landing Zone, und welche Elemente teilen sich? Welche Workloads kommen zuerst, was folgt später? Ergebnis: priorisierte Roadmap.

  7. 07

    Beispielaufbau oder maßgeschneidert bauen

    Bereitstellung

    Google nennt als Optionen unter anderem das Terraform-Beispiel „example foundation“ (ein bewusst stark vorgegebener Landing-Zone-Aufbau), Terraform-Blueprints (Module für Google-Cloud-Ressourcen) und die Konsolenanleitung. Wir empfehlen Infrastructure as Code mit CI/CD und GitOps und wählen mit Ihnen, ob wir mit dem Beispielaufbau starten oder maßgeschneidert bauen. Ergebnis: Repository-Struktur und Pipeline.

04Netzwerk und Konnektivität

Ihr Netz und Google Cloud sauber verbinden

Das Netzwerk ist die Entscheidung, die sich später am schwersten ändern lässt. Im Workshop legen wir fest:

  • Shared-VPC-Netze je Umgebung (Produktion, Entwicklung, Test)
  • VPC-Firewall-Regeln, Cloud NAT und Cloud DNS
  • Anbindung an Ihr Netz über Cloud Interconnect (Dedicated oder Partner) oder Cloud VPN

Mehr zu Cloud Security

Türkisfarbene Glasfaser-Patchkabel mit LC-Steckern an einem Netzwerkgerät in einem Rechenzentrum

05GKE-Betriebsmodus

Autopilot oder Standard: Wer steuert was?

Laut GKE-Dokumentation gibt es zwei Betriebsmodi. Google empfiehlt Autopilot für die meisten Produktionsworkloads, sofern Ihre Anwendung nicht Rechte oder Konfigurationen braucht, die Autopilot einschränkt.

Vergleich der GKE-Betriebsmodi Autopilot und Standard nach Google-Dokumentation
AspektAutopilotStandard
Infrastruktur und Pod-PlatzierungGKE verwaltet den GroßteilSie steuern Node-Pools, Skalierung und Pod-Platzierung selbst
Pod-KonfigurationBest Practices als Standard, zum Beispiel keine privilegierten PodsPods frei konfigurierbar
Workloads im ClusterAutopilot-Workloads laufen auch in Standard-ClusternStandard-Workloads laufen nur in Standard-Clustern

06Modellwahl

Drei Fragen entscheiden den GKE-Modus

Unsere Prüfreihenfolge, bevor wir Cluster zuschneiden:

  1. 01

    Privilegierte Container, Spezial-Treiber oder Knotenzugriff?

    Dann Standard, oder gemischter Betrieb über Compute Classes (siehe Google-Dokumentation).

  2. 02

    Soll Ihr Team keinen Knotenbetrieb übernehmen?

    Dann Autopilot.

  3. 03

    Lässt sich der Bedarf trennen?

    Autopilot-Workloads können auch in Standard-Clustern laufen, Standard-Workloads nur in Standard-Clustern. Das beeinflusst, wie wir Cluster zuschneiden.

07Verantwortung

Google betreibt die Plattform, Sie behalten die Hoheit

Google betreibt die Plattform, Sie verantworten Konfiguration, Identitäten, Daten und Anwendungen. Wir arbeiten mit rollenbasiert und zeitlich begrenzten Rechten. Anwendungslogik und Fachdaten verändern wir nicht ohne eigenen Auftrag.

Nahaufnahme von Serverlüftern und Kühlleitungen in einem Rechenzentrum

08Umsetzung

Von der Landing Zone bis zum laufenden Betrieb

Alle Ressourcen beschreiben wir als Code (Terraform oder OpenTofu): Infrastructure as Code.

09Kosten und Aufwand

Was Ihre Google-Cloud-Kosten und unseren Aufwand bestimmt

Google weist in der Moduswahl darauf hin, dass der Modus die Abrechnung beeinflusst; Details stehen auf der GKE-Preisseite des Anbieters. In der Beratung bewerten wir diese Kostentreiber:

  • Zahl der Projekte und Umgebungen
  • Zahl der Cluster
  • Netzwerk-Egress
  • Datenbanken
  • Auslastung und Reservierungen
  • Hybrid-Anbindung
  • Sicherheits- und Nachweisanforderungen
  • Zahl und Art der Workloads
  • Anteil von Beratung, Umsetzung und Betrieb

10Abgrenzung

Wofür Sie uns beauftragen und wofür nicht

Das bekommen Sie von SKAFFON

  • Architektur, Landing Zone und Migration auf Google Cloud.
  • Kubernetes-Einführung mit GKE, auf Wunsch mit Betrieb.

Das bekommen Sie nicht

  • Lizenzwiederverkauf.
  • Eine Preisbewertung ohne Architektur.
  • Eine Lösung, wenn Datenstandort und Betreiberkontrolle einen US-Anbieterkonzern ausschließen.
  • Plattformaufbau für eine einzelne kleine Anwendung ohne Plattformbedarf.

Anfrage

Ihre Workloads, Projekte und Randbedingungen

Beschreiben Sie Ihre Workloads, vorhandene Projekte und die wichtigsten Randbedingungen.

Projekt anfragen Cloud-Übersicht