Google Cloud Spanner ใช้งานได้แล้วในราคาครึ่งหนึ่งของ Amazon DynamoDB

 (cloud.google.com)
1 คะแนน โดย GN⁺ 2023-10-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google Cloud ระบุว่าแม้จะคงราคา Cloud Spanner เดิมไว้ แต่ได้เพิ่ม throughput สูงสุด 50% และเพิ่มความจุ storage ต่อโหนดเป็น 2.5 เท่า ทำให้สำหรับเวิร์กโหลดส่วนใหญ่มีต้นทุนเหลือเพียงครึ่งเดียวเมื่อเทียบกับ Amazon DynamoDB
  • หลังการปรับปรุง Spanner ยังคงรักษา strong external consistency, latency ระดับ single-digit millisecond, การขยายระบบได้แทบไม่จำกัด และ SLA ความพร้อมใช้งาน 99.999%
  • ความจุ storage ต่อโหนดเพิ่มจาก 4TB เป็น 10TB และผู้ใช้ยังคงจ่ายเฉพาะพื้นที่จัดเก็บที่ใช้งานจริงเท่านั้น โดยไม่ขึ้นกับเพดานความจุที่เพิ่มขึ้น
  • อัปเดตนี้เริ่มให้ใช้งานก่อนในบาง การตั้งค่าอินสแตนซ์แบบ region และ multi-region ส่วนการตั้งค่าอื่น ๆ และการอัปเกรดความจุ storage จะทยอยตามมาในช่วงหลายเดือนข้างหน้า
  • ลูกค้าจะได้รับประโยชน์จากการปรับปรุงนี้ที่ราคาเดิม โดยไม่ต้อง reprovision, ไม่มี downtime และไม่ต้องดำเนินการใด ๆ เพิ่มเติม สามารถเริ่มอินสแตนซ์สำหรับ production ได้ตั้งแต่ 65 ดอลลาร์ต่อเดือน หรือใช้ทดลองใช้ฟรี 90 วัน

การปรับปรุงความคุ้มค่าด้านราคาต่อประสิทธิภาพของ Cloud Spanner

  • Google Cloud เพิ่ม throughput ได้สูงสุด 50% และขยายความจุ storage ต่อโหนด 2.5 เท่า โดยไม่เปลี่ยนราคา Cloud Spanner
  • บริษัทระบุว่าด้วยการปรับปรุงนี้ Spanner สามารถใช้งานได้ที่ ครึ่งหนึ่งของต้นทุน ของ Amazon DynamoDB สำหรับเวิร์กโหลดส่วนใหญ่
  • Spanner มอบทั้ง throughput สูง, การขยายระบบได้แทบไม่จำกัด, latency ระดับ single-digit millisecond, SLA ความพร้อมใช้งาน 99.999% และ semantic ของ strong external consistency
  • จะทยอยใช้กับลูกค้า Spanner ทุกคนภายในไม่กี่เดือนข้างหน้า โดยไม่ต้อง reprovision, ไม่มี downtime และไม่ต้องมีการดำเนินการจากผู้ใช้

การเปลี่ยนแปลงด้านคอมพิวต์และพื้นที่จัดเก็บ

  • ในด้าน compute มีการปรับปรุง throughput 50% ทำให้เวิร์กโหลดแบบ relational และ key-value มีความคุ้มค่ามากขึ้น
  • ในด้าน storage ความจุที่โหนด Spanner หนึ่งโหนดรองรับได้เพิ่มจาก 4TB เป็น 10TB
    • แม้เพดานความจุจะเพิ่มขึ้น ผู้ใช้ก็ยังจ่ายเฉพาะพื้นที่จัดเก็บที่ใช้งานจริงเท่านั้น
    • ทำให้มีความยืดหยุ่นมากขึ้นในการปรับแต่งสภาพแวดล้อมของ Spanner ให้เหมาะสม
  • บริษัทระบุว่าเมื่อเทียบเวิร์กโหลดลักษณะใกล้เคียงกัน Spanner ให้ read throughput ต่อดอลลาร์สูงกว่า Amazon DynamoDB ได้สูงสุด 2 เท่า

คุณสมบัติด้านประสิทธิภาพและเวิร์กโหลดที่เหมาะสม

  • Spanner ให้ latency ระดับ single-digit millisecond ที่คาดการณ์ได้ สำหรับการอ่านและเขียนแบบ strong consistency ข้ามหลาย availability zone ภายใน region เดียวกัน
  • ด้วย SQL ที่คุ้นเคย, ไม่มี downtime เพื่อบำรุงรักษา, และ SLA ความพร้อมใช้งาน 99.999% จึงเหมาะทั้งกับข้อมูลเชิงสัมพันธ์และเวิร์กโหลด key-value ที่เน้นการอ่าน
  • ภายใน Google เองมีการใช้ Spanner กับบริการอย่าง Ads, Gmail และ Photos
  • ตาม บล็อกโพสต์ Prime Day ของ Amazon DynamoDB รองรับคำขอได้ 126 ล้านคิวรีต่อวินาทีในช่วงพีค
  • Google ระบุว่า Spanner รองรับได้ 3 พันล้านคิวรีต่อวินาที ในช่วงพีค และมีข้อมูลภายใต้การดูแลมากกว่า 12 exabyte

กรณีลูกค้าและกำหนดการเปิดให้ใช้งาน

  • Uber ระบุว่า Spanner เป็นองค์ประกอบสำคัญของงานปฏิบัติการหลัก และมีคุณค่าในด้านการขยายระบบและต้นทุนการดำเนินงานที่ต่ำ
    • ก่อนใช้ Spanner เฟรมเวิร์กจัดการข้อมูลต้องอาศัยการกำกับดูแลและความพยายามในการปฏิบัติการจำนวนมาก ทำให้ความซับซ้อนและค่าใช้จ่ายเพิ่มขึ้น
    • วิธีแก้แบบดั้งเดิมอย่าง sharding และ eventual consistency เป็นอุปสรรคต่อความเร็วในการพัฒนา
    • หลังนำ Spanner มาใช้ ต้นทุนการดำเนินงานลดความซับซ้อนลง ความเสถียรดีขึ้น และได้ throughput กับประสิทธิภาพที่ดีกว่าในราคาเท่าเดิม
  • CERC ปรับปรุง ประสิทธิภาพการดำเนินงาน ได้จากการเพิ่ม throughput และความจุ storage ต่อโหนด
  • การปรับปรุงด้านราคาต่อประสิทธิภาพเปิดใช้งานแล้วในบาง การตั้งค่าอินสแตนซ์แบบ region และ multi-region โดยการตั้งค่าอื่นจะทยอยตามมา
  • การอัปเกรด storage จะทยอยปล่อยในช่วงหลายเดือนข้างหน้า
  • ผู้ใช้สามารถใช้ ทดลองใช้ฟรี 90 วัน หรือเริ่มอินสแตนซ์ที่พร้อมสำหรับ production ได้ตั้งแต่ 65 ดอลลาร์ต่อเดือน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-13
ความคิดเห็นบน Hacker News

  • เมื่อไม่นานมานี้เรา ย้ายอินฟราจาก GCP ไป AWS แล้ว ย้ายหมดทั้ง Kubernetes cluster, load balancer, storage, Lambda, KMS
    Google ให้ความรู้สึกเหมือนสตาร์ทอัพที่บริหาร tech stack เพื่อเอาไปใส่เรซูเม่ตัวเอง มีส่วนที่ยังไม่สุกงอม hack และฟีเจอร์ที่ไม่มีเอกสารเยอะเกินไป เวลาใช้ GKE จะมีเวอร์ชันใหม่กับฟีเจอร์ใหม่ออกมาตลอด ทำให้ต้องคอยกลับไปแก้ workaround สำคัญ ๆ ที่ใส่ไว้ในอินฟราเพราะข้อบกพร่องฝั่ง Google อยู่เรื่อย ๆ
    เวลาของทีมอินฟรากลายเป็นครึ่งหนึ่งใช้ไปกับการเตรียมรับมือปัญหาของ Google อีกครึ่งใช้กับงานอินฟราที่วางแผนไว้เดิม และมันไม่มีวันจบ หลังย้ายไป AWS แล้ว ค่าใช้จ่ายสำหรับ Kubernetes cluster 3 ชุดเหลือประมาณ 60% ของตอนใช้ GCP
    ซัพพอร์ตของ AWS ดีจนน่าเหลือเชื่อ ส่วนซัพพอร์ตของ Google แย่มาก บั๊กที่รายงานไว้ตั้งแต่ปี 2020 เพิ่งถูกปิดเป็น stale โดยไม่มีการแก้ไขใด ๆ ประมาณว่า API เปลี่ยนไปมากจนตอนนี้มันไม่มีความหมายแล้ว ทุกเดือนในวันออกบิล มันทำให้นึกขึ้นได้ว่าเรากำลังจ่ายเงินให้กับนักพัฒนาที่ทำงานซึ่งบริษัทอื่นทำได้ดีกว่ามากไม่ได้ และไม่คิดถึงเลยสักนิด

    • น่าสนใจที่ถ้าในข้อความนี้ สลับ GCP กับ AWS ก็ตรงกับประสบการณ์ของผมพอดี
      ผมทำงานด้านวิดีโอเกมในยุโรป ตอนอยู่ Ubisoft ความประทับใจที่ AWS ทิ้งไว้แย่มาก หลังย้ายไป Tencent/Sharkmob ผมพยายามจะชอบ AWS เพราะเป็นมาตรฐานอุตสาหกรรม แต่ส่วนใหญ่ให้ความรู้สึกเหมือนขยะที่ไม่สอดคล้องกันซึ่งถูกคลุมทับด้วย Lambda function
      เราเรียกกับดักแปลก ๆ แบบนี้ว่า หัวข้อเวลาตี 3 เพราะเป็นปัญหาที่ไม่มีสติพอจะรับมือได้ตอนตี 3 ผมเลยโน้มน้าวสตูดิโอให้เปลี่ยนไปใช้ GCP และจนถึงตอนนี้ก็ยังรู้สึกขอบคุณการตัดสินใจนั้นมาก
    • แปลกใจที่มีคำบ่นเกี่ยวกับ GCP เยอะขนาดนี้ เราดูแล deployment ขนาดใหญ่ที่ใช้ทั้ง GCP, Azure และ AWS ครอบคลุมมากกว่า 100 region และ ถ้าเป็นลูกค้ารายใหญ่พอ ซัพพอร์ตของ GCP ก็ใช้ได้
      ในทางกลับกัน Azure ซึ่งมีส่วนแบ่งตลาดใหญ่กว่า GCP มากนั้นแย่มาก และโดยรวมเละเทะสุด ๆ ต่อให้จ่ายค่าซัพพอร์ตก็ยังติดต่อกับฝ่ายวิศวกรรมได้ยาก ส่วน AWS นั้นยอดเยี่ยม
      เราใช้ Enterprise Support อยู่ เลยมีคนดูแลเข้ามาอยู่ในช่อง Slack และ TAM ก็ทำงานดี ถ้าต้องการคนดูแล Route53 ก็จัดสายคุยได้ในสัปดาห์นั้น หรือถ้ามี feature request ของ EKS ก็ได้คุยกับ product manager บ่ายวันเดียวกันเลย Azure นั้นเป็นความวุ่นวายตั้งแต่รากฐาน
    • ประโยคที่ว่า “ซัพพอร์ตของ AWS ดีจนน่าเหลือเชื่อ” ทำให้นึกถึงการโทรประจำสัปดาห์กับลูกค้าสมัยก่อน
      ตอนพัฒนา service ของ AWS ผมรับสายซัพพอร์ตลูกค้าเองโดยตรง ไม่มีคนกลาง วิศวกรคุยกับวิศวกรโดยตรง บางทีก็ให้คำมั่นกับลูกค้าตรงนั้นเลย และบางครั้งลูกค้าก็เป็นฝ่าย project manage งานของเราเองด้วย
    • มีเรื่องของบริษัทหนึ่งในอดีตที่ “พูดสิ่งที่ควรพูดเบา ๆ ออกมาดัง ๆ” แผนกหนึ่งของ Google ใช้บริการของเราแล้วถามว่าทำไม downtime เยอะขนาดนี้ เราชี้ไปทาง GAE แล้วตอบว่า “ถ้าฝั่งนั้นล่ม เราก็ล่มด้วย”
      พอพวกเขาไปคุยกับ GAE ก็พบว่า downtime ที่ตัวเองเห็นนั้นมีความสัมพันธ์กับ downtime ของ GAE จริง ๆ ช่วงหนึ่ง uptime ของ GAE ดีขึ้น แต่ตอนนี้เราก็ใช้ AWS แล้ว
    • เห็นด้วยกับที่ว่า “ซัพพอร์ตของ AWS ดีจนน่าเหลือเชื่อ” แม้แต่ support portal ก็ให้ความรู้สึกว่าทำเองได้ดีกว่าผลิตภัณฑ์สำเร็จรูปจาก vendor อย่าง Zendesk เสียอีก พูดในฐานะลูกค้าที่จ่ายเงินให้ Zendesk
      ส่วน ซัพพอร์ตของ GCP ได้เกรด F และถ้าจะให้ได้ความช่วยเหลือแม้แต่นิดเดียว ก็รู้สึกเหมือนต้องแทบจะอ้อนวอน

  • การเปรียบเทียบที่ว่า “ตามบล็อก Amazon Prime Day นั้น DynamoDB รองรับคิวรีได้ 126 ล้านครั้งต่อวินาทีในช่วงพีก ขณะที่ Spanner รองรับได้ 3 พันล้านคิวรีต่อวินาทีในช่วงพีก สูงกว่ากว่า 20 เท่า และจัดการข้อมูลมากกว่า 12 เอกซะไบต์” ดูจะไม่ยุติธรรมเสียทีเดียว
    ตัวเลข 126 ล้านคิวรีต่อวินาทีของ Amazon อ่านแล้วเหมือนเป็นโหลดที่บริการต่าง ๆ ที่เกี่ยวข้องกับ Amazon ซึ่งรองรับ Prime Day สร้างขึ้นบน DynamoDB ไม่ใช่ทั้ง AWS ทั้งหมด
    ถ้าจะเปรียบเทียบให้ยุติธรรมกว่านี้ ก็ควรแชร์โหลดพีกที่บริการของ Google สร้างบน Cloud Spanner ไม่ใช่นำบริการ Spanner ทั้งหมดที่รันอยู่บน GCP ทั้งหมดและโครงสร้างพื้นฐานภายในของ Google ที่ไม่ใช่ GCP มารวมกัน
    ถ้าบอกว่า Photos, Gmail, Ads พึ่งพาโครงสร้างพื้นฐาน GCP อย่างมาก นั่นจะเป็นสัญญาณความเชื่อมั่นที่แรง แต่สำหรับผมนั่นเป็นข้อมูลใหม่ โดยเฉพาะในบทความนี้ ปกติเรียกว่า “Cloud Spanner” แต่พอพูดถึง Gmail, Ads, Photos กลับเรียกแค่ “Spanner” ทำให้สับสนว่าพวกเขาใช้โครงสร้างพื้นฐาน Cloud Spanner หรือรัน Spanner บนโครงสร้างพื้นฐานของตัวเอง
    ที่ Amazon แทบทุกบริการสร้างอยู่บน AWS จึงดูเหมือนเป็นการลงคะแนนความเชื่อมั่นที่ชัดเจน แต่กับ GCP ผมเคยมีภาพจำว่าในอดีตบริการภายในของ Google ใช้กันน้อยกว่ามาก

    • ต้นฉบับบล็อก AWS เขียนไว้แบบนี้:
      “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 ระบุประเด็นนี้ไว้อย่างชัดเจนมาก หาก Google ใช้ตัวเลขนี้โดยไม่มีบริบทเช่นนั้น ก็เป็นการเปรียบเทียบที่ต่ำช้าและไม่ซื่อสัตย์อย่างสิ้นเชิง คนเขียนบทความนี้ดูเหมือนจะขาด ความซื่อสัตย์
    • ใน คีย์โน้ตนักพัฒนา Google Cloud Next ปีนี้ มีการแชร์รายละเอียดบางส่วนเกี่ยวกับการย้าย Gmail ไปใช้ Spanner เท่าที่ผมรู้ นั่นเป็นครั้งแรกที่เรื่องนี้ถูกเปิดเผยต่อสาธารณะ
      https://www.youtube.com/watch?v=268jdNwH6AM
    • ผมไม่ค่อยแน่ใจว่าการที่ Photos, Gmail, Ads ใช้โครงสร้างพื้นฐาน GCP นั้นเป็นสัญญาณความเชื่อมั่นหรือไม่ เพราะคำว่า “โครงสร้างพื้นฐาน GCP” ในที่นี้หมายถึงอะไรก็ยังคลุมเครือ
      ในบล็อกเขียนว่า “Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos.” แต่ Spanner ภายในของ Google กับ GCP Spanner นั้นแยกกัน การที่บริการของ Google ใช้ Spanner ไม่ได้แปลว่าต้องใช้ GCP เสมอไป
      แต่ตามที่ผมเข้าใจ Spanner กับ GCP Spanner นั้นคล้ายกันมากกว่าความสัมพันธ์ระหว่าง Borg กับ Kubernetes อยู่มาก
    • ก็ไม่มีสัญญาณว่า Google กำลังพูดถึง Spanner ทั้งหมดเช่นกัน ตัวอย่างที่ยกมาล้วนเป็นบริการภายในของ Google และระบุชัดว่า “inside Google”
      ต่อให้รวมปริมาณการใช้งานของ AWS ทั้งหมด ถ้าการใช้งานของ Amazon เองใน Prime Day อยู่ที่ 126 ล้านคิวรีต่อวินาที ก็ยังน่าสงสัยอยู่พอสมควรว่า DynamoDB จะเหนือกว่า Spanner หรือไม่
    • ที่ Amazon แทบทุกบริการของ AWS ใช้ DynamoDB และยังใช้กับกรณีอย่างคิวงานแบบ multi-tenant ที่ปกติไม่ได้คิดว่าเป็นงานฐานข้อมูลด้วย
      ลองค้นคำว่า “Database as a Queue” ก็จะพอเห็นบรรยากาศ ที่จริงแล้วใน AWS การใช้ฐานข้อมูลเชิงสัมพันธ์นั้นยากมาก และถ้าทีมจะขอข้อยกเว้นต้องผ่านการอนุมัติถึงระดับ CEO เลยทีเดียว ซึ่งแสดงให้เห็นถึงความแข็งแกร่งของ DDB

  • สำหรับหลายโปรเจกต์ Postgres ยังถูกกว่าทั้งสองตัวอยู่ดี ผมเคยใช้ทั้งคู่มาแล้ว แต่ถ้าให้เลือก ผมชอบปรับโปรเจกต์ให้เข้ากับ Postgres/CockroachDB มากกว่าใช้ Spanner หรือ DynamoDB มาก
    Spanner กับ DynamoDB มีหลุมพรางมากกว่าเยอะ ทั้งค่าใช้จ่ายที่พุ่งขึ้นแบบไม่ทันตั้งตัว การผูกติดกับผู้ขาย และปัญหาอื่น ๆ อีก AWS, GCP, Azure, Oracle Cloud ไปจนถึงการดีพลอยผ่าน Kubernetes operator ต่างก็รองรับ Postgres ได้ดีมาก ดังนั้นใช้ Postgres ไปเถอะ

    • ถ้าตรรกะนั้น sqlite3 ในหน่วยความจำก็ถูกกว่า Postgres อีก
      ถ้าคุณดูแล Postgres ได้อย่างถูกต้อง ก็แน่นอนว่าควรใช้มัน ถ้าคุณใส่ข้อมูลทั้งหมดลงใน Postgres บนเครื่องเดียวได้ ก็ไม่มีเหตุผลต้องใช้ฐานข้อมูลระดับ P ที่ขยายได้ทั่วโลก
    • ไม่มีโปรเจกต์ที่ NoSQL เหมาะกว่าฐานข้อมูลเชิงสัมพันธ์บ้างหรือ?
      ถ้าจะทำแอปแชตที่มีข้อความหลายล้านข้อความและแทบไม่มี “ความสัมพันธ์” เลย ผมสงสัยจริง ๆ ว่าควรใช้ Postgres หรือควรใช้ตระกูล NoSQL แบบไหน
    • ผมเพิ่งย้ายฐานข้อมูลหลักของแอปจาก PG ไปเป็น DynamoDB ส่วนงานวิเคราะห์ข้อมูลยังคงคัดลอกไปไว้ใน SQL
      พอจัดการกับฟังก์ชันแบบกระจายและโค้ดที่รันบน Lambda การจัดการการเชื่อมต่อ SQL กลายเป็นฝันร้าย และมีคำขอหลุดหายไปทั่ว
    • นั่นออกนอกประเด็นไปนิด ถ้ากำลังพิจารณา DynamoDB หรือ Spanner โดยปกติก็เพราะต้องการ สเกล ของเอนจินเหล่านั้น
      PostgreSQL นั้นยอดเยี่ยม และแม้ผมทำงานที่ Google ผมก็เห็นด้วย 100% ใช้ PG ไปเถอะจนกว่ามันจะไม่ไหวจริง ๆ การถกเถียงแบบนี้จึงจะมีความหมายเมื่อคุณเข้าสู่ขอบเขตของ Spanner และ DynamoDB แล้วเท่านั้น
    • Postgres กับ Spanner จัดการงานคนละแบบ ด้วยวิธี ต้นทุน ความเสี่ยง และนัยที่ต่างกัน
      ถ้าเป็นสิ่งที่แตกต่างโดยสิ้นเชิงแต่ถูกกว่านิดหน่อย ก็อาจบอกให้ “ใช้ไปเถอะ” ได้กับอะไรก็ได้ เช่น เก็บเรคอร์ดเป็นคอมมิตใน GitHub repository ก็ฟรีและถูกพอสำหรับโปรเจกต์เล็ก ๆ แต่ไม่ใช่สิ่งเดียวกัน

  • GCP Spanner เริ่มต้นที่ “65 ดอลลาร์ต่อเดือน” ขณะที่ AWS Free Tier ให้ “พื้นที่เก็บข้อมูล 25GB, คำขออ่านสตรีม 2.5 ล้านครั้ง” เป็นต้น
    https://aws.amazon.com/dynamodb/pricing/
    ในกราฟ สักวันหนึ่งเส้นคงตัดกัน แต่ชื่อเรื่องของ Google ดูเหมือนจะทำให้เข้าใจผิด

    • ตรงนี้ Free Tier ไม่เกี่ยวข้องเลย เหตุผลที่ใช้ Spanner คือความสามารถในการขยายตัวที่ยอดเยี่ยม
      ถ้าไม่ใช่เพื่อการศึกษา แทบไม่มีเหตุผลที่จะใช้กับโปรเจกต์เล็ก ๆ และลูกค้า Spanner คือที่ที่แม้แต่ CockroachDB ก็ยังไม่พอ เป็นต้น ถ้าฐานข้อมูลไม่ได้ใหญ่ขนาดนั้น PostgreSQL ก็เพียงพอแล้ว
    • นี่แค่ 50 QPS เอง ถ้าอยู่ระดับ 50 คิวรีต่อวินาที แน่นอนว่าคงไม่ต้องคิดถึงการขยายตัวขนาดใหญ่และความพร้อมใช้งานของ Cloud Spanner
      ทุกวันนี้มีแอปมากมายที่แตะผู้ใช้มากกว่า 100 ล้านคนภายในเดือนเดียว จึงไม่ใช่สถานการณ์ที่รับมือกับ 50 QPS อีกทั้งยังละเรื่องขอบเขตไบต์ของ DynamoDB ไปด้วย ถ้าเกิน 1KB แม้เพียง 1 ไบต์ ก็จะถูกคิดค่าอ่าน 2 ยูนิต
    • รู้สึกเหมือนจับผิดเกินไปหน่อย Free Tier เป็น โปรแกรมการตลาด ไม่ใช่ผลิตภัณฑ์
      คำพูดที่ว่า “Google ก็ควรมีส่วนลดสำหรับผู้เริ่มต้น” นั้นสมเหตุสมผลมาก แต่ไม่ได้บอกว่าผลิตภัณฑ์จริงแพงกว่าหรือถูกกว่า

  • อยากลองเล่น Spanner ในโปรเจกต์ส่วนตัวหรือไซด์โปรเจกต์ แต่อินสแตนซ์ที่พร้อมใช้งานจริงเริ่มต้นที่ 65 ดอลลาร์ ต่อเดือน DynamoDB คิดค่าตามคำขอ จึงรันได้ด้วยค่าใช้จ่ายต่อเดือนแทบเป็น 0 ดอลลาร์

    • ทำได้ Spanner มีทดลองใช้ฟรี: https://cloud.google.com/spanner/docs/free-trial-instance
      แต่การคิดค่าตามคำขอก็ฟรีเฉพาะตอนที่ยังอยู่ใน Free Tier เท่านั้น ต้องตรวจสอบโควตา และถ้าเกินก็ไม่ฟรีอีกต่อไป
    • นั่นแหละเหตุผลที่ DynamoDB ดี สามารถรันไซด์โปรเจกต์ได้แทบจะ 0 ดอลลาร์ต่อเดือน แบบไม่มีกำหนด
    • ถ้าสนใจ Spanner ก็น่าดู CockroachDB โดยเฉพาะมีผลิตภัณฑ์ serverless ที่พร้อมใช้งานจริงและคิดเงินตามการใช้งานเท่านั้น
      สถาปัตยกรรมของ CRDB โดยเนื้อแท้แล้วภายในคล้าย Spanner
      https://www.cockroachlabs.com/get-started-cockroachdb/

  • เมื่อก่อนค่อนข้างชอบผลิตภัณฑ์ของ Google หลายอย่าง เลยรู้สึกลังเลใจ ผูกกับ Gmail พอสมควร และรันหลายอย่างบน GCP อยู่แล้ว
    แต่ก็รู้สึกมากขึ้นเรื่อย ๆ ว่าโดน Google ปิดบริการกะทันหัน ทุกโดเมนเคยอยู่กับ Google Domains และใช้งานได้ดี แต่เมื่อไม่นานมานี้จู่ ๆ ก็ถูกขายให้ Squarespace ซึ่งเป็นบริษัทที่ไม่อยากทำธุรกรรมด้วย
    ใช้ Google Pixel และเคยใช้แอป Google Podcasts ด้วย แต่ได้ยินว่าอันนี้ก็จะปิดและย้ายไป YouTube Music เคยลอง YouTube Music แล้วแต่เกลียดจริง ๆ เลยต้องหาตัวแทน
    ในระยะยาวสิ่งเหล่านี้อาจเป็นบริการเล็ก ๆ แต่ก็ทำให้ไม่สบายใจที่จะฝาก บริการสำคัญ ไว้กับ Google อีก ก่อนจะทุ่มเวลาเข้าไป ก็ต้องถามว่า “ถ้าสักวัน Google ขายหรือปิด Cloud Spanner จะเกิดอะไรขึ้น? ตอนนั้นจะลำบากไหม?”

    • กำลังย้ายองค์กรไป GKE และ การปิด Google Domains เป็นการปิดบริการครั้งแรกที่รู้สึกน่ากลัวจริง ๆ เท่าที่รู้ นี่เป็นกรณีแรกที่ผลิตภัณฑ์ IT แบบ B2B จริง ๆ ถูกปิดโดยไม่มีสัญญาณเตือนที่เหมาะสม
      การจดทะเบียนโดเมนอาจเป็นดงกับระเบิดทั้งด้านกฎระเบียบและชื่อเสียง แต่ผลิตภัณฑ์คลาวด์อื่น ๆ รวมถึงการส่งมอบคอนเทนต์ก็เช่นกัน ยังถือไม่ได้ว่าเป็นแพตเทิร์นใหญ่ของการปิดบริการ Google Cloud แต่ อย่างน้อยก็มีไฟเหลืองติดขึ้นแล้ว
    • “Google” ในฐานะบริษัทค้นหาที่ออกผลิตภัณฑ์และบริการ กับ “Google Cloud” นั้นต่างกัน
      การยุติผลิตภัณฑ์ของ Google น่ารำคาญก็จริง แต่ไม่เกี่ยวกับผลิตภัณฑ์และบริการของ Google Cloud Google Cloud มีลูกค้าที่จ่ายเงินอยู่ จึงไม่คิดว่าจะประกาศปิดผลิตภัณฑ์หรือบริการแบบกะทันหัน
      Google Domains เป็นผลิตภัณฑ์ของ Google ส่วนผลิตภัณฑ์ฝั่ง Google ที่สอดคล้องกันคือ Google Cloud Domains ซึ่งให้บริการแก่ลูกค้า Google Cloud

  • “องค์กรทุกขนาดและทุกอุตสาหกรรมมีความต้องการมากขึ้นในการเร่งการเปลี่ยนผ่านสู่ดิจิทัลและผลักดันนวัตกรรมที่ขับเคลื่อนด้วย AI” อะไรแบบนี้ Google กลายมาเป็นแบบนี้ได้อย่างไร

    • เพราะจ้างคนจาก VMWare, Dell, Oracle เข้ามา
    • คุณไม่ใช่ผู้อ่านเป้าหมาย และมีความเป็นไปได้ว่าผู้บริหารบางคนต่างหากคือเป้าหมาย
    • CEO คนปัจจุบันของ Google Cloud ใช้เวลา 22 ปีที่ Oracle ก่อนมารับบทบาทนี้
    • เพราะผู้นำใหม่ของ Cloud ที่ไล่ตาม buzzword
    • ที่ดูเป็นองค์กรใหญ่ ก็เพราะมันกลายเป็นบริษัทใหญ่แล้ว

  • ถ้า Spanner ไม่มี เวอร์ชัน on-demand ที่คิดค่าตามหน่วยงานแทนการคิดตามโหนด ก็เทียบกับ DynamoDB ได้ยากในหลาย use case

    • ใช่ ใน Spanner ต้อง provision ให้พอรับ peak throughput
      throughput เฉลี่ยต่ำกว่า peak มาก เลยสงสัยว่าจะเห็นการประหยัดต้นทุนจาก Spanner ได้หรือไม่
      แต่การพัฒนาน่าจะง่ายกว่าบน DynamoDB มาก

  • Google มีประวัติขึ้นค่าบริการอย่างมาก Vendor lock-in เป็นความเสี่ยง

    • ใน Google Maps เคยเกิดเรื่องแบบนั้นจริง ๆ และ Google ก็เป็นผู้เล่นที่ครองตลาดอย่างชัดเจน
      สงสัยเหมือนกันว่ามีในบริการอื่นไหม สำหรับบริการคลาวด์ธุรกิจที่เป็นอันดับ 2 หรือ 3 ซึ่งตามหลัง AWS อยู่มาก ดูเป็นไปได้น้อยกว่ามาก
      แม้จะเป็นตัวอย่างเก่า แต่ก็รู้จักกรณีที่ลดค่าใช้จ่ายลงด้วย: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
    • สงสัยว่าเคยขึ้นราคาของ บริการ Google Cloud ที่มีอยู่หรือไม่
      เท่าที่รู้ AWS มีแต่ลดราคาบริการ เช่นนั้น
    • ต้องมีหลักฐาน
    • มีหลักฐานไหมว่า vendor lock-in เป็นปัญหาที่แพร่หลายจริง ๆ?

  • ถ้ารัน Postgres DB บน Droplet ก็แทบจะเหมือนใช้ฟรี และประสิทธิภาพก็ค่อนข้างดี
    จ่ายเดือนละ 65 ดอลลาร์ก็ได้เซิร์ฟเวอร์ที่ทรงพลังมากจาก Hetzner แล้ว ต้องฝ่าพุ่มหนามบ้าคลั่งที่เรียกว่าเมนูสินค้า Cloud ไปให้ได้ แต่พอดูครั้งเดียวแล้วก็ตัดสินใจว่า สู้ไปเรียน พื้นฐานการดูแล Linux แล้วใช้ไปตลอดชีวิตจะดีกว่า

    • แก่นของ Spanner คือการรองรับเวิร์กโหลดและฐานข้อมูลที่ใหญ่ขึ้น ใหญ่ขึ้น และใหญ่ขึ้นอีก ถ้าใส่ทุกอย่างไว้ในเซิร์ฟเวอร์เครื่องเดียวได้ ก็แน่นอนว่าควรทำแบบนั้น
      การเทียบ Postgres กับ Spanner ก็คล้ายกับการเทียบรถตู้ส่งของกับรถไฟ รถไฟมีต้นทุนคงที่สูงกว่าเสมอ
      การดูแล Linux เป็นทักษะที่มีประโยชน์ แต่ความสามารถในการดูแล Linux ของผมแข่งขันกับความน่าเชื่อถือ ความพร้อมใช้งาน และความสามารถในการขยายของระบบ Cloud อย่าง Dynamo, S3, Spanner ไม่ได้
    • คำพูดที่ว่า “เรียนพื้นฐานการดูแล Linux ครั้งเดียว แล้วเอาไปใช้ได้ตลอดชีวิต” สะท้อนข้อเสียที่ถูกประเมินต่ำเกินไปของโปรเจกต์แบบ AWS/GCP native ได้ดี
      เวลามากเกินไปถูกใช้ไปกับ การตั้งค่าและการแก้ปัญหาเฉพาะบริการ ซึ่งแทบไม่มีความหมายในที่อื่น
    • หรือไม่ก็อาจใช้ DynamoDB ได้แทบฟรี
      ถ้าใช้พื้นที่จัดเก็บ 1GB, ขนาดรายการ 1KB, เขียน 100,000 ครั้ง และอ่าน 100,000 ครั้งในหนึ่งเดือน บน DynamoDB On-Demand จะอยู่ที่ 0.39 ดอลลาร์ เท่านั้น ต่อให้เพิ่มการเขียนและการอ่านเป็นอย่างละ 1 ล้านครั้ง ก็ยังอยู่ที่ 1.63 ดอลลาร์ ถ้าใช้การอ่านแบบ strongly consistent จะเป็น 1.75 ดอลลาร์ และถ้าใช้การเขียนแบบ transaction ด้วยก็จะเป็น 3.00 ดอลลาร์