Open Source

„Multicloud Mindset“: Gedanken zu Open Source und Sicherheit in der Multicloud-Welt

Wed, 19 Apr 2023 09:00:00 +0000

Nie gab es einen besseren Zeitpunkt, um über Multicloud zu diskutieren. Folgerichtig wurde eigens zu diesem Zweck die „Multicloud Mindset“-Serie von Google Cloud auf Twitter Spaces ins Leben gerufen. Die Serie setzt sich im Zwei-Wochen-Rhythmus fort und bietet Live-Gespräche mit Top-Expert*innen zu den heißesten Multicloud-Themen. Stellen Sie Ihre persönlichen Fragen in der 15-minütigen Q&A-Session, oder hören Sie die Folgen später offline – sie sind bis zu 30 Tage nach dem Live-Termin verfügbar.

Sollten Sie die letzten Folgen verpasst haben, entdecken Sie in der Blog-Einführung zur Serie, was Ihnen entgangen ist. Befassen wir uns nun mit den jüngsten Inhalten: Open Source und neue Sicherheitsfragen in Multicloud-Umgebungen.

Folge 5: Open Source und Multicloud treffen zusammen

Open Source ist schon sehr lange fester Bestandteil der Computertechnik: Sie war es bereits, bevor Technologiezentren wie das Silicon Valley entstanden. Open-Source-Projekte haben uns weltweit erfolgreiche Softwarelösungen beschert, zum Beispiel Mozilla Firefox oder das Betriebssystem Linux.

In der fünften Folge haben wir uns mit Mike Coleman, Cloud Developer Advocate bei Google Cloud, zusammengesetzt und einen näheren Blick auf die Geschichte der Open-Source-Technologien geworfen – ihre Rolle in einer Multicloud-Welt, und die Sicht von Entwickler*innen auf den Einsatz von Open Source in ihrer Arbeit.

Seine Berechtigung schöpft das Konzept Multicloud aus der Möglichkeit, Workloads in mehreren Clouds zu betreiben und für bestimmte Workload-Anteile den jeweils besten Anbieter auszuwählen. Mit Open-Source-Technologien und -Sprachen können Unternehmen alle Tools nutzen, die sie brauchen, ohne sich von einem bestimmten Cloud-Anbieter abhängig zu machen.

„Vielleicht ziehen Sie einen Umgebungswechsel in Erwägung – von Cloud zu Cloud oder vom Entwickler-Desktop zum endgültigen Ziel, möglicherweise auch zwischen Ihrem Rechenzentrum und einer Cloud. Das ist mit der Open-Source-Software kein Problem ... und Multicloud ist lediglich eine Erweiterung davon. Das Konzept, dieselbe Software zu nutzen, egal wo ich gerade bin, darum geht es.“ — Mike Coleman, Cloud Developer Advocate bei Google Cloud

Wenn Sie wissen möchten, wie Multicloud und Open Source aus Sicht der Entwicklung beurteilt werden und wie sie sich auf Trends der digitalen Transformation auswirken, sollten Sie sich diese Folge nicht entgehen lassen.

Verfolgen Sie das ganze Gespräch auf Twitter Spaces.

Folge 6: Neue Herausforderungen für die Multicloud-Sicherheit

Sicherheitsverantwortliche und -architekt*innen setzen immer seltener auf traditionelle Sicherheitsmodelle – diese werden Multicloud-Umgebungen kaum noch gerecht. Darüber sprachen wir in der sechsten Serienfolge mit Dr. Anton Chuvakin, Security Advisor im Office of the CISO bei Google Cloud.

Immer mehr Unternehmen folgen Multicloud-Ansätzen. Dementsprechend ist die Gewährleistung der Sicherheit in diesen komplexen Umgebungen eine zentrale Frage, genauso wie die zunehmende Belastung der SecOps-Teams. Wie Dr. Chuvakin feststellte, stehen traditioneller aufgestellte Teams bei der Cloud vor vielfältigen Herausforderungen: von der Art der Telemetrie und Protokolle bis hin zu fehlender Klarheit bei der praktischen Erkennung von Einsatzbereichen. Diese Herausforderungen verschärfen sich, wenn mehrere Clouds zu betrachten sind, denn die nötige Vorgehensweise kann sich von Anbieter zu Anbieter grundsätzlich unterscheiden.

„Wenn Sie sich für Multicloud entscheiden, müssen Sie sich mit der Public Cloud und ihrer Funktionsweise besser auskennen, als wenn Sie nur einen Anbieter nutzen. Wer drei Autos reparieren will, muss erst einmal in der Lage sein, überhaupt ein Auto zu reparieren. Multicloud erfordert mehr Cloud-Wissen, nicht weniger. Und im Public Cloud-Bereich braucht es eben ein paar Superkräfte mehr: Man kann nicht nur einen Provider durchdenken und sich dann zufrieden zurücklehnen.“ — Dr. Anton Chuvakin, Security Advisor, Office of the CISO bei Google Cloud

Im Gespräch formulierte er drei Tipps für die Sicherheit in Multicloud-Umgebungen:

Lernen Sie mehr über die Cloud, nicht weniger, wenn Sie auf Multicloud setzen. Multicloud setzt mehr Cloud-Know-how voraus: Sie können sich nicht nur mit einem Provider befassen und dann zurücklehnen. Sie müssen die Unterschiede zwischen den Clouds verstehen, wenn Sie mehrere Cloud-Umgebungen sicher machen wollen.
Konzentrieren Sie sich darauf, das Cloud-Identitätsmanagement zu erlernen und wie es im Vergleich zu Ihren herkömmlichen ID-Verwaltungsdiensten funktioniert. Nehmen Sie sich Ihre Clouds sukzessive vor und erfassen Sie zunächst die Unterschiede und Gemeinsamkeiten.
Untersuchen Sie, wo sich die Bedrohungsbereiche in Cloud-Umgebungen ändern, wenn Sie die Maßnahmen zur Erkennung und Reaktion planen. Sie wollen schließlich wissen, ob mit Ihrer Erkennungsmethodik alle Clouds abgedeckt sind.

Wenn Ihr Unternehmen auf Multicloud setzt, sollten Sie sich diese Folge auf jeden Fall anhören. Sie werden einiges über Cloud-Sicherheit, die wichtigsten Überlegungen und Herausforderungen für Sicherheitsteams sowie über Best Practices für Multicloud-Sicherheit erfahren.

In diesem Blog informieren wir Sie jeden Monat über die neuesten Themen und Folgen. Bis zum nächsten Mal!

Sieben Cloud Spanner-Mythen

Mon, 22 Aug 2022 04:00:00 +0000

Einführung in Cloud Spanner

Cloud Spanner ist eine unternehmenstaugliche, global verteilte und extern konsistente Datenbank mit unbegrenzter Skalierung und 99,999 % Verfügbarkeit. Sie erfordert keine Wartungsfenster, bietet eine vertraute PostgreSQL-Schnittstelle und verbindet die Vorteile relationaler Datenbanken mit der unübertroffenen Skalierbarkeit und Verfügbarkeit nicht-relationaler Datenbanken.

Spanner bietet Unternehmen, die ihre Software-Ausstattung modernisieren und vereinfachen möchten, neue Möglichkeiten, um ihre Vorstellung und Nutzung von Datenbanken für die Entwicklung neuer Anwendungen und Kundenerlebnisse zu transformieren.

Es ist nicht einfach, die richtige Datenbank für Ihre Workloads auszuwählen. Der Markt bietet unzählige Optionen, die sich in Sachen Onboarding und Betrieb teilweise deutlich unterscheiden. Das Google Cloud-Team möchte Ihnen gerne dabei helfen, sich in diesem großen Angebot zurechtzufinden: In diesem Blogbeitrag möchten wir sieben Missverständnisse aufklären, die im Zusammenhang mit Spanner besonders oft aufkommen, damit Sie eine faktenbasierte Entscheidung treffen können.

Mythos Nr. 1: Der Einsatz von Spanner ist nur bei massiven Workloads sinnvoll

Es ist in der Tat so, dass Spanner für die weltweit verfügbaren Google-Produkte wie YouTube, Drive und Gmail eingesetzt wird und viele groß angelegte Transformationen – unter anderem bei Uber, Niantic und Sharechat – möglich gemacht hat. Richtig ist auch, dass Spanner zu Spitzenzeiten mehr als eine Milliarde Abfragen pro Sekunde verarbeitet.

Dennoch schätzen auch viele Kunden mit kleineren Workloads – also weniger Transaktionen und geringerer Speichergröße – die Verfügbarkeit und Skalierbarkeit von Spanner. So laufen beispielsweise auch die kleineren Workloads von Google Password Manager auf Spanner. Kunden wie diese entscheiden sich für Spanner, weil sie sich keine Ausfallzeiten leisten können, beim Betrieb ihrer Anwendungen auf Hochverfügbarkeit angewiesen sind und verlässliche Skalierbarkeit für ihr künftiges Wachstum benötigen.

Unbegrenzte Skalierbarkeit mit höchster Verfügbarkeit ist in vielen Branchen, wie der Gaming Industrie und dem Einzelhandel, entscheidend – wenn etwa ein Spiel nach der Veröffentlichung über Nacht zum Verkaufsschlager wird oder ein Einzelhändler am Black Friday oder Cyber Monday plötzlich einen besonders hohen Ansturm bewältigen muss.

Ganz gleich, wie groß die Workloads sind: Jedes Unternehmen, das auf dem Weg in die Cloud ist, legt Wert auf Skalierbarkeit und Verfügbarkeit und möchte den Arbeits- und Kostenaufwand für Patches, Upgrades und andere Wartungsarbeiten verringern.

Mythos Nr. 2: Spanner ist zu teuer

Anstatt bei der Beurteilung einer Datenbank nur auf den Listenpreis zu schauen, sollten Sie die Gesamtbetriebskosten und den Gebrauchswert, den sie bietet, mit in Betracht ziehen. Spanner bietet einen erheblichen Mehrwert in entscheidenden Punkten wie Verfügbarkeit, Preis-Leistungs-Verhältnis und verringerte Betriebskosten.

Verfügbarkeit: Spanner überzeugt mit hoher Verfügbarkeit und Zuverlässigkeit durch synchrone Replikation von Daten. Was die Notfallwiederherstellung betrifft, bietet Spanner 0-RPO und 0-RTO für zonale Ausfälle regionaler Instanzen und regionale Ausfälle überregionaler Instanzen. Das bedeutet weniger Ausfallzeiten und mehr Umsatz.

Preis-Leistungsverhältnis: Mit Blick auf das Preis-Leistungs-Verhältnis ist Spanner die ideale Lösung für anspruchsvolle und leistungskritische Anwendungen, denn großartige Kundenerlebnisse erfordern konsistent optimale Latenzzeiten.

Verringerte Betriebskosten: Bei Spanner profitieren Kunden von Upgrades und Schemaänderungen ohne Ausfallzeiten und ohne Wartungsfenster. Dank automatischer Fragmentierung ist, anders als bei herkömmlichen Datenbanken, keine aufwändige Skalierung nötig. Das bedeutet weniger Verwaltungsaufwand und damit mehr Zeit für Innovationen.

Sicherheit & Compliance: Spanner verschlüsselt Daten bereits standardmäßig bei der Übertragung über seine Client-Bibliotheken und bei der Speicherung mit von Google verwalteten Schlüsseln. CMEK-Unterstützung für Spanner sorgt dafür, dass Sie jetzt die volle Kontrolle über die Schlüssel haben. Zudem bietet Spanner Unterstützung für VPC Service Controls und kann dank Compliance-Zertifizierungen und der nötigen Genehmigungen für Workloads verwendet werden, die ISO 27001, 27017, 27018, PCI DSS, SOC1|2|3, HIPAA und FedRAMP erfordern.

Bei Spanner haben Sie die Gewissheit, dass die Sicherheit, Verfügbarkeit und Zuverlässigkeit Ihrer Daten nicht beeinträchtigt werden.

Profi-Tipp: Nutzen Sie den Auto-Scaler, um Ihre Spanner-Instanzen richtig zu dimensionieren, und TTL, um die Speicherdatenmenge zu reduzieren.

Mythos Nr. 3: Sie müssen Skalierung, Konsistenz und Latenzzeit gegeneinander abwägen

Tatsächlich lässt sich Spanner je nach Anwendungsfall und Konfiguration der Instanz so nutzen, dass Sie keine Kompromisse bezüglich Konsistenz, Latenz und Skalierung schließen müssen.

Um Datenkonsistenz zu gewährleisten, verwendet Spanner ein synchrones, Paxos-basiertes Replikationsschema, bei dem die Replikate jede Schreibanforderung bestätigen. Ein Schreibvorgang wird nur dann ausgeführt, wenn die Mehrzahl der Replikate (z. B. 2 von 3) als sogenanntes Quorum zustimmen. Bei regionalen Instanzen befinden sich die Replikate in der Region. Deshalb sind die Schreibvorgänge schneller als bei überregionalen Instanzen, deren Replikate auf mehrere Regionen verteilt sind. Im letzteren Fall kann die mehrheitliche Genehmigung von Schreibvorgängen mehr Zeit in Anspruch nehmen und die Latenz geringfügig erhöhen. Dennoch werden auch Spanner-Multiregionen geografisch sorgfältig konfiguriert, so dass die Replikate stets schnell genug kommunizieren können und die Schreiblatenzen annehmbar bleiben.

Lesevorgänge werden als Strong Read (standardmäßig) oder als Stale Read ausgeführt. Ein Strong Read ist ein Lesevorgang, bei dem garantiert alle bis zum aktuellen Zeitpunkt übertragenen Daten erfasst werden. Ein Stale Read hingegen erfasst den Datenstand eines länger zurückliegenden Zeitpunkts. Bei einem Strong Read garantiert das Replikat, das die Daten bereitstellt, dass alle bis zum Beginn des Lesevorgangs übertragenen Daten angezeigt werden. Hierfür muss sich dieses Replikat unter Umständen beim Leader-Replikat rückversichern, dass es über die neuesten Daten verfügt. Im Falle einer überregionalen Instanz, bei der die Daten nicht von einem Leader-Replikat bereitgestellt werden, kann die Leselatenz deshalb etwas höher ausfallen als bei der Bereitstellung aus einer Leader-Region. Ein Stale Read liefert Daten, die zu einem Zeitpunkt in der Vergangenheit übertragen wurden, und kann daher mit sehr geringer Latenz vom nächstgelegenen Replikat bereitgestellt werden, das über den Datenbestand zum angeforderten Zeitpunkt verfügt. Für latenzkritische Anwendungen können Stale Reads mit einem empfohlenen Stale-Read-Wert von 15 Sekunden sinnvoll sein.

Mythos Nr. 4: Spanner spricht kein PostgreSQL

Tatsächlich ist Spanner sehr flexibel und kann nicht nur in einem SQL-Dialekt, der auf dem ANSI 2011-Standard basiert, sondern auch über eine für Leistung und Komfort optimierte REST oder gRPC API-Schnittstelle mit der Datenbank kommunizieren. Darüber hinaus haben wir kürzlich eine PostgreSQL-Schnittstelle für Entwicklungsteams eingeführt, die lieber auf der ihnen vertrauten Oberfläche der weit verbreiteten Umgebung arbeiten. Die PostgreSQL-Schnittstelle stellt ein umfangreiches Subset des PostgreSQL Open Source SQL-Dialekts mit der gängigen Abfragesyntax sowie wichtigen Funktionen und Operatoren bereit. Sie unterstützt alle grundlegenden Open Source PostgreSQL-Datentypen, DDL-Syntax und Informationsschema-Ansichten. So können Sie die mächtige relationale Semantik von Spanner auch in Ihrer vertrauten PostgreSQL-Umgebung nutzen.

Weitere Informationen zu unserer PostgreSQL-Schnittstelle finden Sie hier.

Mythos Nr. 5: Beobachtbarkeitsdaten können nur in der Spanner Console abgerufen werden

Die Client-Bibliotheken von Spanner unterstützen OpenCensus Tracing und Metriken, die Einblick in die Client-Interna bieten und die Fehlersuche in der Produktion erleichtern. Client-seitige Traces und Metriken enthalten sitzungs- und transaktionsbezogene Informationen.

Außerdem unterstützt Spanner den OpenTelemetery-Empfänger, sodass Sie Metriken aus Cloud Spanner-Systemtabellen mühelos verarbeiten, visualisieren und in das Application Monitoring (APM)-Tool exportieren können. Das kann entweder eine Open-Source-Kombination aus einer Zeitreihen-Datenbank und einem Grafana-Dashboard oder aber ein kommerzielles Angebot wie Splunk, Datadog, Dynatrace, NewRelic oder AppDynamics sein. Zudem haben wir Grafana-Referenzdashboards veröffentlicht, sodass Sie die häufigsten Anfragen von Nutzerinnen und Nutzern wie „Warum ist meine Tail-Latenz so hoch?“ oder „Warum sehe ich trotz unveränderter Workload eine CPU-Spitze?“ sofort bearbeiten können. Dieser Docker-Dienst ist ein Beispiel dafür, wie der Cloud Spanner-Empfänger mit dem Prometheus-Exporter und Grafana-Dashboards zusammenarbeiten kann.

Wir setzen auch weiterhin auf offene Standards und die Integration mit unserem Partnernetzwerk. Außerdem entwickeln wir die von Google Console bereitgestellte Beobachtbarkeit weiter, um Kunden unabhängig von ihrem Standort das bestmögliche Erlebnis zu bieten.

Mythos Nr. 6: Spanner eignet sich nur für globale Workloads, die Kopien in mehreren Regionen voraussetzen

Tatsächlich bietet Spanner neben einer Reihe von überregionalen Instanzkonfigurationen in jeder GCP-Region auch eine regionale Konfiguration. Jeder regionale Knoten wird in drei Zonen innerhalb der Region repliziert, ein überregionaler Knoten mindestens fünfmal in verschiedenen Regionen. Eine regionale Konfiguration bietet eine Four-Nines-Verfügbarkeit und Schutz vor zonalen Ausfällen.

Eine überregionale Instanzkonfiguration ist in der Regel angezeigt, wenn Ihre Anwendung Workloads an mehreren geografischen Standorten umfasst oder Ihr Unternehmen eine Verfügbarkeit von 99,999 % und Schutz vor regionalen Ausfällen benötigt. Mehr dazu erfahren Sie hier.

Mythos Nr. 7: Spanner-Schemaänderungen erfordern teure Sperren

Die Wahrheit ist, dass Spanner auf Tabellenebene überhaupt keine Sperren hat. Seine Architektur ermöglicht Spanner, mehrere gleichzeitige Schema- und Datenversionen zu erkennen und zu verwalten. Das erlaubt qualifizierte Ad-hoc- und Online-Schemaänderungen ganz ohne Ausfallzeiten, zusätzliche Tools, Migrationspipelines oder komplexe Rollback-/Backup-Pläne. Nach dem Start einer Schemaaktualisierung können Sie ohne Unterbrechung weiter in der Datenbank schreiben und lesen, während Spanner das Update-Backfill verarbeitet – ganz gleich, ob Ihre Tabelle zehn Zeilen oder zehn Milliarden Datensätze umfasst.

Dieser Mechanismus kann auch für die Wiederherstellung zu einem bestimmten Zeitpunkt und für Snapshot-Abfragen verwendet werden, um sowohl das Schema als auch den Zustand der Daten mit einer bestimmten Abfragebedingung und einem bis zu sieben Tage zurückliegenden Zeitstempel zu regenerieren.

Nun kennen Sie die Wahrheit über Cloud Spanner und können direkt einsteigen – besuchen Sie unsere Website.