Google Cloud Spanner ist jetzt zum halben Preis von Amazon DynamoDB nutzbar

 (cloud.google.com)
1 Punkte von GN⁺ 2023-10-13 | 1 Kommentare | Auf WhatsApp teilen
  • Google Cloud gibt an, den Durchsatz von Cloud Spanner bei unverändertem Preis um bis zu 50 % zu erhöhen und die Speicherkapazität pro Node um das 2,5-Fache zu steigern. Damit koste Spanner bei den meisten Workloads im Vergleich zu Amazon DynamoDB nur die Hälfte
  • Auch nach den Verbesserungen behält Spanner starke externe Konsistenz, Latenzen im einstelligen Millisekundenbereich, praktisch unbegrenzte Skalierung und ein SLA für 99,999 % Verfügbarkeit bei
  • Die Speicherkapazität pro Node steigt von 4 TB auf 10 TB; Nutzer zahlen unabhängig vom höheren Limit weiterhin nur für den tatsächlich genutzten Speicherplatz
  • Das Update ist zunächst für einige regionale und multiregionale Instanzkonfigurationen verfügbar; die übrigen Konfigurationen sowie das Speicher-Upgrade folgen in den kommenden Monaten
  • Kunden erhalten die Verbesserungen zum aktuellen Preis, ohne Re-Provisionierung, Downtime oder eigenes Zutun. Produktionsreife Instanzen starten ab 65 US-Dollar pro Monat, alternativ gibt es eine kostenlose 90-Tage-Testversion

Besseres Preis-Leistungs-Verhältnis für Cloud Spanner

  • Google Cloud erhöht den Durchsatz um bis zu 50 % und erweitert die Speicherkapazität pro Node um das 2,5-Fache, ohne den Preis von Cloud Spanner zu ändern
  • Laut Google kann Spanner dadurch bei den meisten Workloads zu halb so hohen Kosten wie Amazon DynamoDB genutzt werden
  • Spanner kombiniert hohen Durchsatz, praktisch unbegrenzte Skalierung, Latenzen im einstelligen Millisekundenbereich, ein SLA für 99,999 % Verfügbarkeit und starke externe Konsistenzsemantik
  • Die Änderungen werden in den kommenden Monaten für alle Spanner-Kunden ausgerollt; Re-Provisionierung, Downtime oder Nutzeraktionen sind nicht erforderlich

Änderungen bei Compute und Speicher

  • Beim Compute verbessert sich der Durchsatz um 50 %, wodurch relationale Workloads und Key-Value-Workloads kosteneffizienter werden
  • Beim Speicher steigt die Kapazität, die ein einzelner Spanner-Node aufnehmen kann, von bisher 4 TB auf 10 TB
    • Trotz des höheren Kapazitätslimits zahlen Nutzer nur für den tatsächlich genutzten Speicherplatz
    • Dadurch steigt die Flexibilität bei der Optimierung von Spanner-Umgebungen
  • Für vergleichbare Workloads bietet Spanner laut Google einen bis zu 2-mal höheren Lesedurchsatz pro Dollar als Amazon DynamoDB

Leistungsmerkmale und geeignete Workloads

  • Spanner bietet vorhersehbare Latenzen im einstelligen Millisekundenbereich für stark konsistente Lese- und Schreibvorgänge über mehrere Verfügbarkeitszonen innerhalb derselben Region hinweg
  • Mit vertrautem SQL, ohne Wartungs-Downtime und mit einem SLA für 99,999 % Verfügbarkeit eignet sich Spanner nicht nur für relationale Daten, sondern auch für leseintensive Key-Value-Workloads
  • Intern bei Google wird Spanner für Dienste wie Ads, Gmail und Photos genutzt
  • Laut Amazons Prime-Day-Blogbeitrag verarbeitet DynamoDB zu Spitzenzeiten 126 Millionen Abfragen pro Sekunde
  • Spanner verarbeitet laut Google zu Spitzenzeiten 3 Milliarden Abfragen pro Sekunde und verwaltet mehr als 12 Exabyte an Daten

Kundenbeispiele und Verfügbarkeit

  • Uber bezeichnet Spanner als wichtigen Bestandteil des geschäftskritischen Betriebs und sieht den Wert in Skalierbarkeit und niedrigen Betriebskosten
    • Vor der Einführung von Spanner erforderte das Framework für Datenmanagement viel Überwachung und Betriebsaufwand, wodurch Komplexität und Ausgaben stiegen
    • Traditionelle Workarounds wie Sharding und Eventual Consistency wurden zu Hindernissen für die Entwicklungsgeschwindigkeit
    • Nach der Einführung von Spanner wurden die Betriebskosten vereinfacht und die Zuverlässigkeit verbessert; zugleich erhielt Uber bei gleichem Preis besseren Durchsatz und höhere Leistung
  • CERC verbessert durch den höheren Durchsatz und die größere Speicherkapazität pro Node die betriebliche Effizienz
  • Die Verbesserungen beim Preis-Leistungs-Verhältnis sind derzeit für einige regionale und multiregionale Instanzkonfigurationen verfügbar; die übrigen Konfigurationen folgen später
  • Das Speicher-Upgrade wird in den kommenden Monaten ausgerollt
  • Nutzer können eine kostenlose 90-Tage-Testversion verwenden oder eine produktionsreife Instanz ab 65 US-Dollar pro Monat starten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-13
Hacker-News-Meinungen

  • Wir haben kürzlich unsere Infrastruktur von GCP zu AWS migriert. Kubernetes-Cluster, Load Balancer, Storage, Lambda, KMS – alles wurde umgezogen.
    Google wirkt, als würde es seinen Tech-Stack wie ein Startup betreiben, das seinen Lebenslauf aufhübschen will; es gab zu viele unausgereifte Teile, Hacks und undokumentierte Funktionen. Wenn man GKE nutzt, kommen ständig neue Versionen und Features heraus, und wegen Fehlern auf Google-Seite mussten wir zentrale Workarounds in unserer Infrastruktur immer wieder nacharbeiten.
    Die Zeit des Infrastrukturteams ging zur Hälfte dafür drauf, sich gegen Google-Probleme zu wappnen, und zur Hälfte für die ursprünglich geplante Infrastrukturarbeit – ohne Ende. Nach dem Umzug zu AWS lag die Rechnung für drei Kubernetes-Cluster bei etwa 60 % dessen, was wir bei GCP bezahlt hatten.
    Der AWS-Support war unglaublich gut, der Google-Support furchtbar. Ein Bug, den wir 2020 gemeldet hatten, wurde kürzlich ohne Maßnahmen als stale geschlossen, mit der Begründung, die API habe sich so stark geändert, dass er inzwischen ohnehin keine Bedeutung mehr habe. Jeden Monat am Abrechnungstag wurde ich daran erinnert, dass wir Entwickler dafür bezahlen, etwas nicht hinzubekommen, was andere Unternehmen viel besser machen; ich vermisse es überhaupt nicht.

    • Interessanterweise entspricht das genau meiner Erfahrung, wenn man GCP und AWS im Text vertauscht.
      Ich arbeite in Europa im Videospielbereich, und bei Ubisoft hat AWS bei mir einen sehr schlechten Eindruck hinterlassen. Nach dem Wechsel zu Tencent/Sharkmob habe ich versucht, AWS zu mögen, weil es Branchenstandard ist, aber das meiste fühlte sich wie inkonsistenter Müll an, überdeckt mit Lambda-Funktionen.
      Solche seltsamen Fallen nannten wir 3-Uhr-morgens-Themen: Probleme, für die man um 3 Uhr morgens nicht die mentale Kapazität hat. Also überzeugten wir das Studio, zu GCP zu wechseln, und ich bin bis heute sehr dankbar für diese Entscheidung.
    • Es überrascht mich, dass es so viele Beschwerden über GCP gibt. Wir betreiben ein großes Deployment über mehr als 100 Regionen hinweg und nutzen GCP, Azure und AWS; bei GCP ist der Support ordentlich, wenn man ein ausreichend großer Kunde ist.
      Azure dagegen, das einen deutlich größeren Marktanteil als GCP hat, ist furchtbar und insgesamt ein völliges Chaos. Selbst wenn man für Support bezahlt, ist es schwer, jemanden aus dem Engineering zu erreichen; AWS ist hervorragend.
      Wir nutzen Enterprise Support, daher sind die Ansprechpartner in unseren Slack-Channels, und auch die TAMs sind gut. Wenn man jemanden für Route53 braucht, wird noch in derselben Woche ein Call angesetzt, und über einen EKS-Feature-Request kann man noch am selben Nachmittag mit einem Produktmanager sprechen. Azure ist von Grund auf ein Durcheinander.
    • Die Aussage „AWS-Support ist unglaublich gut“ ist die Stelle, an der ich die früheren wöchentlichen Kunden-Calls vermisse.
      Als ich AWS-Services entwickelte, nahm ich selbst Support-Anrufe von Kunden entgegen, ohne Zwischeninstanz. Techniker sprachen direkt miteinander, wir gaben Kunden auch spontan Zusagen, und manchmal übernahmen Kunden sogar das Projektmanagement für unsere Arbeit.
    • Es gibt die alte Geschichte von einem Unternehmen, das „laut aussprach, was man leise sagen sollte“. Eine Abteilung von Google nutzte unseren Service und fragte, warum es so viele Downtimes gebe. Wir zeigten auf GAE und antworteten: „Wenn die ausfallen, fallen wir auch aus.“
      Als sie mit GAE sprachen, stellte sich heraus, dass die von ihnen beobachteten Downtimes tatsächlich mit GAE-Downtime korrelierten. Eine Zeit lang wurde die Verfügbarkeit von GAE besser, aber wir nutzen inzwischen ebenfalls AWS.
    • Ich stimme zu, dass „AWS-Support unglaublich gut ist“. Auch das Support-Portal wirkt, als hätten sie es selbst besser gebaut als fertige Anbieterprodukte wie Zendesk – und das sage ich als zahlender Zendesk-Kunde.
      GCP-Support bekommt die Note F; es fühlt sich an, als müsse man fast betteln, um überhaupt irgendeine Hilfe zu bekommen.

  • Der Vergleich „Laut dem Amazon-Prime-Day-Blog verarbeitet DynamoDB in der Spitze 126 Millionen Abfragen pro Sekunde. Spanner dagegen verarbeitet in der Spitze 3 Milliarden Abfragen pro Sekunde, also mehr als 20-mal so viel, und verwaltet über 12 Exabyte Daten“ wirkt nicht wirklich fair
    Amazons 126 Millionen Abfragen pro Sekunde lese ich so, dass das die Last ist, die Amazon-nahe Dienste zur Bewältigung des Prime Day auf DynamoDB erzeugt haben, nicht die gesamte AWS-Last
    Für einen faireren Vergleich müsste Google die Spitzenlast teilen, die Google-Dienste auf Cloud Spanner erzeugen, und nicht alle Spanner-Dienste zusammenzählen, die über die gesamte GCP und Googles interne Nicht-GCP-Infrastruktur laufen
    Wenn man sagt, dass Photos, Gmail und Ads stark auf GCP-Infrastruktur angewiesen sind, wäre das ein starkes Vertrauenssignal, aber für mich wäre das neu. Besonders verwirrend finde ich, dass in diesem Artikel normalerweise von „Cloud Spanner“ die Rede ist, bei Gmail, Ads und Photos aber nur von „Spanner“, sodass unklar bleibt, ob sie Cloud-Spanner-Infrastruktur nutzen oder Spanner auf eigener Infrastruktur betreiben
    Bei Amazon scheint praktisch jeder Dienst auf AWS aufgebaut zu sein, was wie ein klares Vertrauensvotum wirkt; bei GCP hatte ich historisch den Eindruck, dass es von Googles internen Diensten deutlich weniger genutzt wurde

    • Im ursprünglichen AWS-Blog steht Folgendes:
      „DynamoDB powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day, these sources made trillions of calls to the DynamoDB API. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 126 million requests per second.“
      Amazon hat diesen Punkt sehr klar gemacht. Wenn Google diese Zahl ohne solche Hinweise verwendet hat, ist das ein völlig niederträchtiger und unehrlicher Vergleich. Der Autor dieses Beitrags scheint es an Ehrlichkeit mangeln zu lassen
    • Auf der diesjährigen Google Cloud Next Developer Keynote wurden einige Details zur Migration von Gmail auf Spanner geteilt. Soweit ich weiß, war das das erste Mal, dass diese Geschichte öffentlich erzählt wurde
      https://www.youtube.com/watch?v=268jdNwH6AM
    • Ich bin mir nicht sicher, ob es ein Vertrauenssignal ist, dass Photos, Gmail und Ads GCP-Infrastruktur nutzen. Es ist unklar, was hier mit „GCP-Infrastruktur“ gemeint ist
      Im Blog steht: „Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.“ Aber Googles internes Spanner und GCP Spanner sind zu unterscheiden. Dass ein Google-Dienst Spanner nutzt, heißt nicht zwingend, dass er GCP nutzt
      Allerdings sind Spanner und GCP Spanner nach meinem Verständnis deutlich ähnlicher zueinander als Borg und Kubernetes
    • Es gibt auch keinen Hinweis darauf, dass Google von Spanner insgesamt spricht. Die genannten Beispiele sind alles interne Google-Dienste, und es heißt ausdrücklich „inside Google“
      Selbst wenn man die gesamte AWS-Nutzung zusammenzählt: Wenn Amazons eigene Prime-Day-Nutzung 126 Millionen Abfragen pro Sekunde beträgt, ist ziemlich fraglich, ob DynamoDB Spanner übertreffen würde
    • Bei Amazon nutzt praktisch jeder AWS-Dienst DynamoDB, und es wird auch für Use Cases wie mandantenfähige Work Queues verwendet, an die man normalerweise nicht als Datenbankeinsatz denkt
      Wenn man nach „Database as a Queue“ sucht, bekommt man ein Gefühl dafür. Tatsächlich ist es bei AWS wirklich schwierig, relationale Datenbanken zu verwenden; wenn ein Team eine Ausnahme bekommen will, muss das bis zur CEO-Genehmigung gehen, was die Robustheit von DDB zeigt

  • Für viele Projekte ist Postgres weiterhin günstiger als beide. Ich habe beide benutzt, aber ich würde es viel eher vorziehen, ein Projekt auf Postgres/CockroachDB zuzuschneiden, als Spanner oder DynamoDB zu verwenden
    Spanner und DynamoDB haben deutlich mehr Fallstricke, plötzliche Kostenexplosionen, Vendor Lock-in und andere Probleme. AWS, GCP, Azure, Oracle Cloud und sogar Kubernetes-Operator-basierte Deployments unterstützen Postgres sehr gut, also kann man einfach Postgres verwenden

    • Nach dieser Logik ist sqlite3 im Arbeitsspeicher noch günstiger als Postgres
      Wenn man Postgres ordentlich betreiben kann, sollte man es natürlich verwenden. Wenn man alle Daten in Postgres auf einer Maschine unterbringen kann, gibt es keinen Grund, eine global skalierbare P-Klasse-Datenbank zu verwenden
    • Gibt es nicht auch Projekte, zu denen NoSQL besser passt als eine relationale Datenbank?
      Wenn man eine Chat-App mit Millionen von Nachrichten und kaum „Beziehungen“ baut, frage ich mich ernsthaft, ob man Postgres verwenden sollte oder irgendeine NoSQL-Variante
    • Ich habe die Hauptdatenbank meiner Anwendung gerade von PG zu DynamoDB migriert. Für Datenanalysen kopiere ich weiterhin nach SQL
      Da ich mit verteilten Funktionen und Code auf Lambda zu tun habe, wurde das SQL-Verbindungsmanagement zum Albtraum, und fehlgeschlagene Requests traten überall auf
    • Das geht ein wenig am Punkt vorbei. Wenn man DynamoDB oder Spanner in Betracht zieht, dann normalerweise, weil man die Skalierung dieser Engines braucht
      PostgreSQL ist großartig, und obwohl ich bei Google arbeite, stimme ich zu 100 % zu. Solange es funktioniert, sollte man einfach PG verwenden. Erst wenn man in den Bereich von Spanner und DynamoDB kommt, wird diese Diskussion sinnvoll
    • Postgres und Spanner erledigen unterschiedliche Dinge auf unterschiedliche Weise, mit unterschiedlichen Kosten, Risiken und Implikationen
      Wenn etwas völlig anderes nur ein bisschen günstiger ist, kann man genauso gut „nimm einfach irgendwas“ sagen. Zum Beispiel könnte man Records als Commits in einem GitHub-Repository speichern; das ist kostenlos und für kleine Projekte billig genug, aber es ist nicht dasselbe

  • GCP Spanner kostet „ab 65 US-Dollar pro Monat“, während das kostenlose AWS-Kontingent unter anderem „25 GB Datenspeicher, 2,5 Millionen Stream-Leseanforderungen“ bietet.
    https://aws.amazon.com/dynamodb/pricing/
    Irgendwann werden sich die Linien im Diagramm wohl schneiden, aber Googles Überschrift wirkt irreführend.

    • Das kostenlose Kontingent ist hier völlig irrelevant. Der Grund, Spanner zu nutzen, ist seine herausragende Skalierbarkeit.
      Außer zu Lernzwecken gibt es kaum Gründe, es für kleine Projekte einzusetzen; Spanner-Kunden sind zum Beispiel solche, denen selbst CockroachDB nicht reicht. Für Datenbanken, die nicht derart riesig sind, genügt PostgreSQL.
    • Das sind gerade einmal 50 QPS. Bei 50 Abfragen pro Sekunde macht man sich natürlich keine Gedanken über die massive Skalierbarkeit und Verfügbarkeit von Cloud Spanner.
      Heutzutage gibt es viele Anwendungen, die innerhalb eines Monats mehr als 100 Millionen Nutzer erreichen; da geht es nicht um 50 QPS. Außerdem wurde die Byte-Grenze von DynamoDB ausgelassen. Wenn man 1 KB auch nur um 1 Byte überschreitet, werden zwei Read Units berechnet.
    • Das wirkt ziemlich kleinkariert. Das kostenlose Kontingent ist ein Marketingprogramm, kein Produkt.
      Zu sagen „Google sollte ebenfalls einen Einsteigerrabatt anbieten“ ist völlig berechtigt, sagt aber nicht aus, ob das eigentliche Produkt teurer oder günstiger ist.

  • Ich würde Spanner gern für persönliche Projekte oder Nebenprojekte ausprobieren, aber produktionsreife Instanzen beginnen bei 65 US-Dollar im Monat. DynamoDB kann man mit Abrechnung pro Anfrage praktisch für 0 Dollar im Monat betreiben.

    • Das geht. Für Spanner gibt es eine kostenlose Testversion: https://cloud.google.com/spanner/docs/free-trial-instance
      Allerdings ist auch die Abrechnung pro Anfrage nur kostenlos, solange man innerhalb des kostenlosen Kontingents bleibt. Man muss die Limits prüfen; überschreitet man sie, ist es nicht mehr kostenlos.
    • Genau deshalb ist DynamoDB gut. Ein Nebenprojekt kann man im Grunde unbegrenzt für 0 Dollar pro Monat betreiben.
    • Wenn dich Spanner interessiert, lohnt sich ein Blick auf CockroachDB. Es gibt insbesondere ein produktionsreifes Serverless-Angebot, bei dem nur nach Nutzung abgerechnet wird.
      Die CRDB-Architektur ist im Kern intern Spanner recht ähnlich.
      https://www.cockroachlabs.com/get-started-cockroachdb/

  • Früher mochte ich Google-Produkte ziemlich, daher bin ich hin- und hergerissen. Ich hänge ziemlich an Gmail fest und betreibe bereits einiges auf GCP.
    Gleichzeitig habe ich zunehmend das Gefühl, mich daran verbrannt zu haben, dass Google Dienste plötzlich einstellt. Ich hatte alle Domains bei Google Domains und war zufrieden, aber kürzlich wurde es plötzlich an Squarespace verkauft, und mit diesem Unternehmen möchte ich nichts zu tun haben.
    Ich nutze ein Google Pixel und habe auch die Google-Podcasts-App verwendet; auch die wird eingestellt und soll wohl zu YouTube Music migriert werden. YouTube Music habe ich ausprobiert, fand es aber wirklich furchtbar, also muss ich eine Alternative finden.
    Langfristig mögen das eher kleinere Dienste sein, aber es verunsichert mich, Google erneut wichtige Dienste anzuvertrauen. Bevor ich Zeit investiere, frage ich mich: „Was passiert, wenn Google Cloud Spanner irgendwann verkauft oder einstellt? Würde mich das dann in Schwierigkeiten bringen?“

    • Wir sind gerade dabei, die Organisation auf GKE umzustellen, und die Einstellung von Google Domains war wirklich die erste Einstellung, die sich für mich beängstigend angefühlt hat. Soweit ich weiß, war es der erste Fall, in dem ein ordentliches B2B-IT-Produkt ohne Vorwarnung geschlossen wurde.
      Domain-Registrierung kann in regulatorischer Hinsicht und beim Ruf ein Minenfeld sein, aber das gilt ebenso für andere Cloud-Produkte, einschließlich Content-Auslieferung. Ich würde noch nicht sagen, dass es ein großes Muster bei der Einstellung von Google-Cloud-Diensten zeigt, aber zumindest leuchtet jetzt die gelbe Warnlampe.
    • „Google“ als Suchunternehmen und „Google Cloud“ sind bei Produkten und Diensten, die sie auf den Markt bringen, unterschiedlich.
      Die Einstellung von Google-Produkten ist ärgerlich, hat aber nichts mit Produkten und Diensten von Google Cloud zu tun. Google Cloud hat zahlende Kunden, daher glaube ich nicht, dass dort die Einstellung von Produkten oder Diensten plötzlich angekündigt wird.
      Google Domains ist ein Google-Produkt; das entsprechende Angebot auf Google-Seite für Google-Cloud-Kunden ist Google Cloud Domains.

  • „Organisationen jeder Größe und aus allen Branchen haben einen wachsenden Bedarf, ihre digitale Transformation zu beschleunigen und KI-gestützte Innovation voranzutreiben“ – wie ist Google nur so weit gekommen?

    • Indem sie Leute von VMWare, Dell und Oracle eingestellt haben.
    • Du bist nicht die Zielgruppe; vermutlich ist irgendein Manager die Zielgruppe.
    • Der aktuelle CEO von Google Cloud war vor dieser Rolle 22 Jahre bei Oracle.
    • Wegen der neuen Cloud-Führung, die Buzzwords hinterherläuft.
    • Es wirkt wie ein Großkonzern, weil es ein großer Konzern geworden ist.

  • Wenn es für Spanner keine On-Demand-Version gibt, bei der nach Arbeitseinheiten statt nach Nodes abgerechnet wird, ist es für viele Anwendungsfälle schwer mit DynamoDB zu vergleichen.

    • Stimmt. Bei Spanner muss man für den Spitzen-Durchsatz provisionieren.
      Der durchschnittliche Durchsatz liegt deutlich unter dem Peak, daher bezweifle ich, dass man bei Spanner Kosteneinsparungen sehen wird.
      Allerdings dürfte die Entwicklung mit Spanner viel einfacher sein als mit DynamoDB.

  • Google hat in der Vergangenheit die Kosten für Dienste drastisch erhöht. Vendor Lock-in ist riskant.

    • Bei Google Maps ist das tatsächlich passiert, und Google war dort klar der dominierende Anbieter.
      Ich frage mich, ob es das auch bei anderen Diensten gab. Bei einem Business-Cloud-Dienst, der weit hinter AWS auf Platz zwei oder drei liegt, erscheint mir das deutlich unwahrscheinlicher.
      Es ist zwar ein altes Beispiel, aber ich kenne auch einen Fall, in dem Kosten gesenkt wurden: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
    • Ich frage mich, ob sie jemals die Preise eines bestehenden Google-Cloud-Dienstes erhöht haben.
      Soweit ich weiß, hat AWS die Preise seiner Dienste zum Beispiel nur gesenkt.
    • Dafür bräuchte es Belege.
    • Gibt es Belege dafür, dass Vendor Lock-in tatsächlich ein weit verbreitetes Problem ist?

  • Wenn man eine Postgres-DB auf einem Droplet betreibt, ist das fast kostenlos und die Performance ist auch ziemlich gut.
    Für 65 Dollar im Monat bekommt man bei Hetzner auch einen sehr leistungsstarken Server. Man muss sich durch das verrückte Dickicht der Cloud-Produktmenüs kämpfen; nach einem Blick darauf kam ich zu dem Schluss, dass es besser ist, sich lieber die Grundlagen der Linux-Administration anzueignen und sie ein Leben lang zu nutzen.

    • Der Kern von Spanner liegt darin, größere, noch größere und immer größere Workloads und Datenbanken zu bewältigen. Wenn man alles auf einen einzelnen Server packen kann, sollte man das natürlich tun.
      Postgres mit Spanner zu vergleichen, ist ungefähr so, als würde man einen Lieferwagen mit einem Zug vergleichen. Ein Zug hat immer höhere Fixkosten.
      Linux-Administration ist eine nützliche Fähigkeit, aber meine Linux-Admin-Fähigkeiten können nicht mit der Zuverlässigkeit, Verfügbarkeit und Skalierbarkeit von Cloud-Systemen wie Dynamo, S3 oder Spanner konkurrieren.
    • Die Aussage „Einmal die Grundlagen der Linux-Administration lernen und ein Leben lang anwenden“ zeigt gut einen unterschätzten Nachteil von AWS-/GCP-nativen Projekten.
      Zu viel Zeit fließt in servicespezifische Konfiguration und Fehlersuche, die anderswo kaum Bedeutung hat.
    • Oder man kann DynamoDB faktisch kostenlos nutzen.
      Wenn man einen Monat lang 1 GB Speicher, 1 KB Item-Größe, 100.000 Schreibvorgänge und 100.000 Lesevorgänge nutzt, kostet das bei DynamoDB On-Demand 0,39 Dollar. Selbst wenn man Schreib- und Lesevorgänge jeweils auf 1 Million erhöht, sind es 1,63 Dollar. Mit stark konsistenten Lesevorgängen werden es 1,75 Dollar, und mit Transaktionsschreibvorgängen 3,00 Dollar.