ย้ายจาก AWS ไป Hetzner ลดค่าใช้จ่ายคลาวด์ลง 76%

 (digitalsociety.coop)
9 คะแนน โดย GN⁺ 2025-10-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ย้ายจาก AWS และ DigitalOcean ไปยัง Hetzner ทำให้ลดค่าใช้จ่ายคลาวด์ลง 76% และเพิ่มขนาดทรัพยากรได้ 3 เท่า
  • ก่อนหน้านี้ใช้งานคลาวด์สองรายควบคู่กัน โดยอาศัย ความเสถียรของ AWS และความเรียบง่ายของ DigitalOcean
  • หลังเครดิตฟรีหมด ต้องแบกรับค่าใช้จ่ายในการดำเนินงานมากกว่า 449 ดอลลาร์ต่อเดือน จึงเริ่มมองหาทางเลือกอย่าง Hetzner
  • เพื่อลดต้นทุน จึงสร้าง สแตกคลาวด์แบบดูแลเอง ที่ประกอบด้วย Kubernetes บน Talos Linux, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager เป็นต้น
  • ใช้ เซิร์ฟเวอร์ ARM แบบ shared vCPU และ สตอเรจที่เข้ากันได้กับ S3 ของ Hetzner เพื่อคงประสิทธิภาพและความเสถียร พร้อมขยายทรัพยากรได้ในระดับใหญ่
  • แม้ความสะดวกในการดูแลจะลดลงบ้าง แต่ในฐานะ คลาวด์ทางเลือกในยุโรป ก็มีประสิทธิภาพด้านต้นทุนต่อสมรรถนะที่โดดเด่น

พื้นหลัง

  • ซอฟต์แวร์ทั้งหมดที่ DigitalSociety พัฒนาทำงานอยู่บน คลาวด์
  • ก่อนการย้าย ระบบโครงสร้างพื้นฐานหลักถูกใช้งานบนทั้ง AWS (ดูแลบริการหลัก รวมถึงการยืนยันตัวตนและอีเมล) และ DigitalOcean (บริการขนาดเล็ก การมอนิเตอร์ และ Kubernetes)
  • เลือก AWS เพราะคุ้นเคยจากการใช้งานมานานกว่า 15 ปี และมี ความเสถียรของ API สูง
  • เลือก DigitalOcean เพราะมี สภาพแวดล้อม Kubernetes ที่เรียบง่าย มี control plane ฟรี และคุ้มค่าด้านต้นทุน
  • ช่วงแรกใช้เพียง DigitalOcean แต่เมื่อบริการ SaaS ที่ใช้ข้อมูลเข้มข้นอย่าง tap ต้องการ ทรัพยากรจำนวนมาก และเครดิตเพิ่ม จึงหันไปใช้เครดิตสตาร์ตอัปของ AWS (1,000 ดอลลาร์)

เครดิตหมดและภาระค่าใช้จ่าย

  • แม้ Fargate ของ AWS (รันคอนเทนเนอร์แบบ serverless) จะช่วยให้เริ่มต้นได้ในราคาถูก แต่ด้วยลักษณะที่ใช้ข้อมูลเข้มข้นของบริการ tap จึงต้องมีอย่างน้อย 2x CPU และ RAM 4 GiB เพื่อรักษาประสิทธิภาพ
  • หากอิงตามราคา Fargate คอนเทนเนอร์สเปกดังกล่าวมีค่าใช้จ่ายมากกว่า 70 ดอลลาร์ต่อเดือน และเมื่อรวม worker instance สองตัวกับโครงสร้างพื้นฐานอื่น ๆ แล้ว ค่าใช้จ่ายเพิ่มเป็น 449.50 ดอลลาร์ต่อเดือน
  • เครดิตฟรีที่ได้รับหมดลงในเวลาไม่ถึง 6 เดือน และสำหรับสตาร์ตอัปที่ใช้เงินทุนตนเอง นี่กลายเป็นภาระต้นทุนคงที่ที่หนักมาก

กระบวนการค้นหาทางเลือก

  • เพื่อประหยัดค่าใช้จ่ายในการดำเนินงานและเพิ่มความเป็นอิสระทางเทคโนโลยี จึงมองหาผู้ให้บริการคลาวด์ที่ตั้งอยู่ใน สหราชอาณาจักร/สหภาพยุโรป
  • ด้วยความประทับใจในความสามารถในการแข่งขันด้านราคาของ Hetzner จึงตัดสินใจย้ายออกจากทั้ง AWS และ DigitalOcean แม้จะต้องใช้สภาพแวดล้อม VPS แบบดูแลเองและมีความซับซ้อนในการดำเนินงานมากขึ้น
  • เนื่องจากเดิมทีให้บริการส่วนใหญ่บน Kubernetes อยู่แล้ว จึงสร้าง Kubernetes cluster แบบดูแลเองบน Hetzner ได้ โดยอาศัยความสามารถของ Talos Linux ที่ช่วยให้ตั้งค่า cluster ได้ง่าย
  • แม้จะไม่มีบริการ Managed DB แบบที่ AWS หรือ DigitalOcean มี แต่ก็ใช้ CloudNativePG เพื่อจัดการ PostgreSQL cluster ในสภาพแวดล้อม Kubernetes ได้อย่างปลอดภัยแบบรวมศูนย์ ทั้งการมอนิเตอร์ แบ็กอัป และการรับมือเหตุขัดข้อง

สแตกโครงสร้างพื้นฐานใหม่

  • Hetzner: ใช้เซิร์ฟเวอร์ ARM, block storage, load balancer, network, firewall และ object storage ที่เข้ากันได้กับ S3
  • Talos Linux: ทำให้การดูแล Kubernetes node เป็นแบบอัตโนมัติผ่านการตั้งค่าเชิงประกาศ
  • CloudNativePG: รองรับการประกาศ DB cluster ผ่าน Kubernetes manifest รวมถึงการแบ็กอัปอัตโนมัติและการรับมือเหตุขัดข้อง
  • Ingress NGINX Controller: จัดการ HTTP routing ภายใน cluster แบบรวมศูนย์
  • ExternalDNS: เชื่อมโยง DNS กับ ingress resource โดยอัตโนมัติ
  • cert-manager: ออกใบรับรอง TLS สำหรับ HTTPS โดยอัตโนมัติ
  • โครงสร้างพื้นฐานทั้งหมดถูกทำเป็นโค้ดด้วย Terraform และ Helm และทำ DevOps ผ่านการ deploy อัตโนมัติด้วย GitHub Actions

เปรียบเทียบค่าใช้จ่าย

  • ค่าใช้จ่ายต่อเดือนก่อนย้าย: AWS + DigitalOcean = $559.36
  • ค่าใช้จ่ายต่อเดือนหลังย้าย: Hetzner = $132.96 (−76%)
  • การเพิ่มขึ้นของทรัพยากร:
    • CPU: 12 vCPU → 44 vCPU (+367%)
    • RAM: 24 GiB → 88 GiB (+367%)
    • แม้ทรัพยากรจะเพิ่มขึ้น แต่ค่าใช้จ่ายรวมต่อเดือนกลับถูกกว่ามาก

ความท้าทายและการลองผิดลองถูกระหว่างการย้ายระบบ

  • network zone ของ Hetzner ไม่เหมือนกับ Availability Zone ของ AWS ทุกประการ
    • AWS มีหลาย Availability Zone ภายในหนึ่ง region และ private networking เชื่อมต่อกันอย่างกว้างขวางในระดับ region
    • Hetzner มีหลาย location อยู่ภายใต้ network zone เดียว (eu-central) และมี latency ระหว่าง location ค่อนข้างสูง
    • จากการมอนิเตอร์พบว่า การกระจายระบบไปหลาย location จริงทำให้เกิดปัญหา เช่น ประสิทธิภาพลดลง
    • ทางเลือกที่ใช้คือการอาศัย Placement Group ภายใน location เดียว (นูเรมเบิร์ก) เพื่อเพิ่มความทนทานต่อความขัดข้องผ่านการกระจายเซิร์ฟเวอร์จริง
  • แม้จะเป็นบริการที่รันบนคอนเทนเนอร์ การย้ายก็ไม่ได้ง่ายเสมอไป
    • ตอนย้ายจาก AWS ECS ไป Kubernetes งานแก้ไขสคริปต์อัตโนมัติของการตั้งค่าทั้งหมด (โดยเฉพาะการ deploy ไฟล์ config เป็นต้น) ใช้เวลานานกว่าที่คาด
    • สุดท้ายจึงปรับปรุงระบบเชื่อมโยงการตั้งค่าที่อ่อนไหวและการจัดการไฟล์ config ด้วย Kustomize เพื่อให้ติดตามและรีวิวได้สะดวกขึ้น

บทสรุป

  • Hetzner อาจไม่ใช่บริการแบบ managed ที่ดูแลง่าย แต่เป็นตัวเลือกที่มีประสิทธิภาพมากสำหรับทีมที่ดูแลระบบเองได้
  • การดูแลเองช่วยให้ควบคุมรายละเอียดของระบบได้มากขึ้น พร้อมเพิ่มประสิทธิภาพด้านต้นทุนต่อสมรรถนะให้สูงสุด
  • วิธีนี้ช่วยวางรากฐานให้สามารถพัฒนาและดำเนินงาน tap ซึ่งเป็น SaaS ที่ใช้ข้อมูลเข้มข้น ต่อไปได้ด้วยต้นทุนที่เหมาะสมและประสิทธิภาพที่เสถียร

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

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

 
GN⁺ 2025-10-18
ความคิดเห็นจาก Hacker News

  • ผมอยากเน้นว่าการ deploy ลงบน bare metal โดยตรงให้ประสิทธิภาพที่รู้สึกได้ว่าดีขึ้นมหาศาลจริง ๆ สำหรับบริการของเรา ประสิทธิภาพเพิ่มขึ้น 2 เท่า และได้ performance ที่เสถียรคาดเดาได้ เหตุผลมีหลายอย่าง:

    • latency ต่ำ: ถ้าจัดการเครือข่ายเอง ก็ไม่ต้องแชร์เครือข่ายซับซ้อนของดาต้าเซ็นเตอร์ขนาดใหญ่ ทำให้ latency ลดลงมากกว่า 10 เท่า

    • ปรับ cache ได้เหมาะสม: การ deploy ที่จูนให้เข้ากับฮาร์ดแวร์ช่วยดึงประสิทธิภาพจริงของ CPU รุ่นใหม่ออกมาได้เต็มที่

    • ใช้ NVMe แบบเฉพาะเครื่อง: ความเร็ว disk I/O สูงมาก

    • ข้อดีอีกอย่างคือแทบไม่ต้องพึ่ง autoscaler แล้ว ฮาร์ดแวร์ในราคาเท่ากันแรงกว่า 10 เท่า และเร็วกว่า 2 เท่า การรันแบบ full size จึงสมเหตุสมผลกว่า ทั้งระบบเสถียรและดูแลง่ายกว่า

    • ไม่ต้องกังวลเรื่องค่า S3 ด้วย ใส่ไดรฟ์ NVMe 15TB ในแต่ละเซิร์ฟเวอร์แล้วรันคลัสเตอร์ MinIO/garage ก็พอ เรากำลังรันคลัสเตอร์ 10 โหนดที่รองรับ 20GiB ต่อวินาที และ 50,000 API calls ต่อวินาที ถ้าเป็น S3 แค่ค่า API calls ก็อยู่ที่ $20~$250 ต่อวินาทีแล้ว ซึ่งต่างกันแบบน่าตกใจ

    • มีแค่ค่าบริการรายเดือนแบบคงที่

    • ยังได้ storage เร็วราคาถูก รัน PostgreSQL instance ขนาดใหญ่ในต้นทุนต่ำ และลดข้อจำกัดกับงานงมในคลาวด์ลงไปมาก

    • ต่อให้ลงทุนกับโครงสร้างแบบนี้ ก็ยังมีต้นทุนแค่ 1 ใน 10 ของ AWS

    • ถ้าดูแลเองเป็นภาระ เรา(https://lithus.eu) ช่วยดูแลแทนได้ในราคาครึ่งหนึ่งของ AWS พร้อมช่วยเรื่อง DevOps ด้วย ติดต่อได้ที่ adam@ ตามโดเมน

    • พื้นฐานทางเทคนิค: bare metal คือการรันบนเซิร์ฟเวอร์จริงโดยตรง ไม่ใช่แบบ virtualized (VM)

    • ผมอยากให้เราก้าวข้ามยุคเก่าที่เชื่อว่า “แค่เพิ่มเครื่องก็เร็วขึ้น” และ “ค่าใช้จ่ายไม่สำคัญ” จริง ๆ ในช่วงหนึ่งของอาชีพสมัย .NET ผมเคยรองรับผู้ใช้ระดับหลายล้านคนด้วยเซิร์ฟเวอร์แค่ตู้เดียว พอย้ายไปบริษัทที่ใช้คลาวด์ คอนเทนเนอร์ และ Node microservices ผมต้องเจอกับความวุ่นวายทั้งบิลและปัญหาประสิทธิภาพทุกวัน จนทุกวันนี้ยังนึกแล้วสะพรึงเป็นบางครั้ง

    • ความเปลี่ยนแปลงดูเหมือนจะวนซ้ำเสมอ พอมองบริษัทเรา การไม่ขยับตามเทคโนโลยีใหม่กลับทำให้รู้สึกว่าเรายืนอยู่แถวหน้าของกระแส local cloud/edge/IDC ภายในองค์กรเสียอีก

    • ใช้ S3 API ก็เหมือนปอกหัวหอม ยิ่งใช้ไป น้ำตาก็ยิ่งไหล

    • ถ้าใช้ bare metal ก็ต้องมีคนดูแลด้านเครือข่าย ความปลอดภัย การมอนิเตอร์ แพตช์ และการอัปเดตโดยเฉพาะ ค่าแรงของบุคลากรสายนี้คุ้มก็ต่อเมื่อมีสเกลถึงระดับหนึ่ง ดังนั้นถ้าเป็นธุรกิจขนาดเล็กหรือกลาง คลาวด์ก็ยังได้เปรียบกว่าในแง่ความปลอดภัยและต้นทุนการดำเนินงาน

    • แม้แต่ใน AWS เอง เอกสารก็ระบุชัดว่าเกณฑ์การจัดสรร 1 vCPU ของ Lambda นั้น ในทางปฏิบัติให้มาเพียงราว 50% เท่านั้น แม้สัดส่วนจะดีขึ้นเมื่อเพิ่มหน่วยความจำและ CPU แต่ก็ไม่ได้ให้ประสิทธิภาพ 100% ตลอดเวลา

  • ผมคิดมาตลอดว่าถ้าใช้ dedicated server จะรีดประสิทธิภาพได้สูงสุด ตอนนี้รันอยู่หลายโหนดบน Hetzner และแม้จะเป็นเซิร์ฟเวอร์เก่าอายุ 3 ปีที่เช่าจากการประมูล ก็ยังให้ประสิทธิภาพคนละชั้นกับ VM ฮาร์ดแวร์เซิร์ฟเวอร์พวกนี้ถูกปรับให้เหมาะกับจำนวนคอร์และ I/O และคลาวด์ส่วนใหญ่ก็ oversubscribe ฮาร์ดแวร์กันแทบทั้งนั้น แม้แต่ disk I/O ก็ยังมีลูกเล่นสารพัด เช่น รันอยู่บน NAS แล้วจำลองเป็น local disk สตาร์ทอัพส่วนใหญ่ไม่ได้ต้องการ virtualization หนัก ๆ หรือดิสก์บน NAS แบบนั้นด้วยซ้ำ ตรงกันข้าม ถ้าเช่าเซิร์ฟเวอร์จากที่อย่าง Hetzner กลับไปได้ไกลกว่าในราคาถูกกว่ามาก ผมสงสัยว่ามีผู้ให้บริการในอเมริกาเหนือ โดยเฉพาะแคนาดา ที่ให้ราคาและคุณภาพระดับ Hetzner ไหม OVH ผมรู้จักแล้ว ถ้าใครมีที่คล้ายกันก็อยากทราบ

    • ดูเหมือนหลายคนจะคิดว่าต้องรีบลอกโครงสร้างเทคโนโลยีแบบ Google หรือ Facebook ทันที เราใช้ VPS ในยุโรปและดำเนินงานกันแบบเรียบง่าย แต่พนักงานใหม่ทุกคน ทั้งฝั่งธุรกิจและฝั่งพัฒนา มักพูดเสมอว่าต้องเริ่มโปรเจกต์ย้ายขึ้นคลาวด์ ผมเลยต้องอธิบายทุกครั้งว่า “เราก็ใช้งานคลาวด์อยู่แล้ว และจะไม่ทำโปรเจกต์ย้ายขึ้นคลาวด์ไว้ประดับเรซูเม่ของคุณหรอก”

    • ผมมีบันทึก benchmark เปรียบเทียบประสิทธิภาพ CPU ระหว่างคลาวด์กับ bare metal จริง ๆ เผื่อเป็นประโยชน์ https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12

    • ช่วงหลังผมเจอเว็บนี้ที่อาจมีประโยชน์: https://vpspricetracker.com ไอเดียน่าสนใจมาก และผู้ให้บริการส่วนใหญ่ที่อยู่ในนั้นก็มี dedicated server ให้ด้วย

    • ถ้าหมายถึง “คุณภาพระดับ Hetzner ในสหรัฐฯ แต่ไม่จำเป็นต้องเป็นแบรนด์ท้องถิ่น” Hetzner เองก็มีดาต้าเซ็นเตอร์ในสหรัฐฯ อยู่ 2 แห่ง

    • ถ้าอิงจากแคนาดา ผู้ให้บริการที่น่าดูมี https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/ เป็นต้น

  • เราก็เจอเทรนด์เดียวกัน หลายทีมย้ายไป Hetzner แล้วทึ่งกับประสิทธิภาพต่อราคาที่ได้ แต่ก็ตระหนักว่าต้องกลับไปสร้างระบบดูแล Postgres ใหม่ทั้งหมด ทั้ง backup, failover, monitoring ฯลฯ เลยกลายเป็นว่าเราสร้าง managed Postgres ที่รันบน Hetzner ขึ้นมาเอง ได้ทั้งโครงสร้างที่จูนกับฮาร์ดแวร์แบบเดียวกัน และมี high availability (HA), backup, point-in-time recovery (PITR) ครบ เป็นโอเพนซอร์ส รันใกล้กับฮาร์ดแวร์ และไม่มีค่าธรรมเนียม I/O หรือ data outbound แฝงแบบที่เจอบ่อยใน AWS ถ้าสนใจดูได้ที่บล็อก 1, 2

    • ด้วยเหตุนี้ผมเลยรู้สึกถึงเสน่ห์ของ Big Cloud มาก โดยเฉพาะ PaaS กับ managed SQL และทีมพัฒนาที่ผมให้คำปรึกษาก็คิดคล้ายกัน แม้ไม่มีประสบการณ์ปฏิบัติการมากนัก ก็ยังสบายใจที่จะเลือกใช้ เพราะเรื่อง backup/restore ฐานข้อมูล, patch, การจำกัดการเชื่อมต่อ, การจัดการพอร์ต, การตรวจจับความผิดปกติ, การรับมือ DoS attack ถูกจัดการให้อัตโนมัติ อีกทั้งในเชิงการเมืองและเทคนิค การเลือกใช้คลาวด์ยอดนิยมก็ให้ความรู้สึกปลอดภัยทางใจด้วย

    • ถ้ากำลังมีปัญหากับ Postgres แบบตั้งค่าเอง ดูแลเอง อาจลองดู https://www.elephant-shed.io/

  • น่าสนใจดีที่บทความหรือคอมเมนต์แนวนี้มักให้คำแนะนำโดยแทบไม่บอกบริบทเลย ระหว่างคนที่รันจดหมายข่าวโบสถ์ในเวลาว่าง กับ enterprise SaaS ที่ทราฟฟิกสูงและมีลูกค้าทั่วโลก ความต้องการมันต่างกันมาก ถ้าไม่อธิบายสภาพแวดล้อมของตัวเอง คำแนะนำเรื่องราคา ประสิทธิภาพ หรือความพร้อมใช้งานก็แทบไม่มีความหมาย ความซับซ้อนเกินจำเป็นของเว็บอินฟราส่วนหนึ่งก็เกิดจากการที่คนซึ่งมีความต้องการต่างกันพยายามทำตามคำแนะนำของกันและกัน

    • ขอเสริมความคิดของผมว่า “การทำตามคำแนะนำแบบไม่วิจารณญาณ ทั้งที่ความต้องการต่างกัน จะยิ่งทำให้โลกจริงซับซ้อนขึ้น” บางบริษัทถึงขั้นมี account manager ของคลาวด์ไปนั่งร่วมโต๊ะอาหารกลางวันกับผู้บริหารระดับ C และผลักดันให้เลือก AWS จากนั้นสถาปนิกของ AWS ก็ถูกส่งมาช่วยทีมเราโดยตรง และแน่นอนว่าข้อเสนอที่ได้ก็มักเป็นตัวเลือก serverless ที่แพงที่สุด แต่สุดท้ายของจริงก็ยังต้อง deploy Docker OS image ใหม่เรื่อย ๆ และดูแลไม่ต่างจากแพตช์บน bare metal ธรรมดา

    • แม้แต่ Pastebin ส่วนตัวของผมยังอยู่ไม่รอดถ้าไม่ใช้ bare metal (ล้อเล่น)

    • นี่คือตัวอย่างคลาสสิกของวงการ IT เลย

    • เงื่อนไขความต้องการ ระดับทักษะ โครงสร้างต้นทุน และขอบเขตปัญหาต่างกันโดยสิ้นเชิง Hetzner กับ AWS ดูเหมือนคลาวด์คล้ายกันบนผิวเผิน แต่จริง ๆ เป็นบริการคนละแบบเลย ผมพูดในฐานะคนที่ใช้มาทั้งคู่

    • เห็นด้วยอย่างแรง ผมก็เขียนความเห็นไว้ในบล็อกเหมือนกัน https://news.ycombinator.com/item?id=45616366 สรุปคือ “ให้มองผู้ให้บริการโฮสติ้งเป็นช่วงราคา ตั้งแต่ DIY จนถึง enterprise และถ้ายังไม่จำเป็นต้องใช้จริง (YAGNI) ก็ไม่ต้องเลือกมัน”

  • ผมรัน SaaS บน Hetzner มานานกว่า 10 ปีแล้ว ใช้ฮาร์ดแวร์เฉพาะทั้งหมด ตั้งคลัสเตอร์ในดาต้าเซ็นเตอร์ที่เยอรมนีและฟินแลนด์ และจัดการด้วย ansible ส่วน VPN ระหว่างเซิร์ฟเวอร์ใช้ vpncloud ซอฟต์แวร์นี้ดีมากจริง ๆ ค่าโฮสติ้งต่อเดือนต่ำกว่า AWS และเจ้าอื่นมาก และเซิร์ฟเวอร์ก็เร็วกว่าเยอะ โครงสร้างเรียบง่าย ใช้เซิร์ฟเวอร์ไม่กี่เครื่องก็พอ ถ้าจำเป็นก็เพิ่มเครื่องได้ แต่เพราะเป็น bare metal เลยไม่ได้ขยายได้ภายในไม่กี่นาที ต้องวางแผนล่วงหน้าหลายชั่วโมงหรือหลายวัน ฐานข้อมูลใช้ RethinkDB แบบกระจาย และมีแผนจะย้ายไป FoundationDB เพื่อรับมือความขัดข้อง

    • ผมก็รันคล้ายกันด้วยชุด rethinkdb เหมือนกัน แต่อยากรู้จริง ๆ ว่าทำไมถึงเลือก FoundationDB ทั้งที่ RethinkDB ยังมีคนดูแลอยู่ และบางทีก็ยังมีฟีเจอร์ใหม่เพิ่มเข้ามา ชุมชนผู้ใช้ใน Slack ยังมีชีวิตชีวากว่าที่คิด

    • ดีใจที่ยังมีคนใช้ RethinkDB อยู่

    • คุณเชื่อมต่อระหว่างศูนย์ Hetzner DE/FI ด้วย vpncloud โดยตรงเลยหรือ ผมนึกว่า Hetzner เองก็มีฟีเจอร์แบบนี้ให้ใช้ในราคาถูกอยู่แล้ว

  • ช่วงนี้ผมช่วยหลายทีมย้ายจาก AWS ไป Hetzner (รวมถึง Netcup) และสิ่งที่คนประหลาดใจที่สุดไม่ใช่เรื่องต้นทุนหรือประสิทธิภาพโดยตรง แต่เป็นความเรียบง่ายของระบบเมื่อถอดชั้น abstraction แบบ managed service ออกไป 15 ชั้น ความกังวลเรื่อง S3/EFS/FSx, Lambda cold start, EBS burst credit หายไปหมด แค่ deploy Docker ลงบน NVMe ที่เร็วก็ใช้งานได้เลย แน่นอนว่าต้องมีความสามารถด้าน DevOps เพิ่มขึ้นบ้าง เช่น monitoring, backup, patch ฯลฯ แต่พองานพวกนี้ถูกทำเป็น automation แล้ว มันก็ไม่ใช่สิ่งที่เปลี่ยนทุกสัปดาห์ ที่ Elestio เราโฟกัสกับการทำให้เรียบง่ายแบบนี้ โดยให้บริการ fully managed stack สำหรับซอฟต์แวร์โอเพนซอร์สกว่า 400 รายการ บนคลาวด์ใดก็ได้ พร้อม CI/CD และใช้งาน production ได้แม้จะอยู่บน Hetzner หรือที่อื่น https://elest.io (หมายเหตุ: ผมทำงานที่ Elestio และให้บริการโอเพนซอร์สแบบ multi-cloud)

    • ผมสนใจ managed Postgres ของคุณ อยากรู้ว่ารองรับ streaming replica และ streaming backup หรือเปล่า หรือว่าแค่เก็บ dump ลง s3

  • ตอนเริ่มต้นอาชีพ ผมเคยทำงานที่บริษัทที่ดีมากแห่งหนึ่ง ตอนนั้นเราต้องใช้ Postgres เวอร์ชันที่ RDS ยังไม่รองรับ เลยต้องเซ็ตอัป Postgres บน EC2 เองหลายครั้ง สมัยนั้นยังไม่มี Docker ยิ่งทำก็ยิ่งเสียเวลา พอ RDS รองรับเวอร์ชันนั้น ทุกอย่างง่ายขึ้นทันที ผมยังจำภาพตัวเองนั่งติดตั้ง Postgres ตอนตี 3 ได้อยู่เลย บทความนี้ก็ดีนะ แต่สุดท้ายมันคือการประหยัดแค่หลักร้อยดอลลาร์ต่อเดือน วิศวกรคนหนึ่งถ้าใช้เวลาดูแลแค่ 1 ชั่วโมงต่อเดือน เงินที่ประหยัดก็อาจหายไปแล้ว ถ้าเกิดปัญหาขึ้นกะทันหัน เงินที่ประหยัดมาทั้งปีอาจหายไปในวันเดียว สำหรับโปรเจกต์ส่วนตัวที่ไม่ได้ให้ค่ากับเวลาเท่าไรนัก และต้องใช้เซิร์ฟเวอร์ขนาดใหญ่ bare metal อาจดีกว่า แต่สุดท้ายมูลค่าของเวลาตัวเองจะสูงขึ้นเสมอ เช่น ถ้าจะใช้ Ghost blog โฮสติ้งทางการก็แค่ $10 ต่อเดือน หรือจะไปรันหลายตัวบน Hetzner instance ก็ได้ แต่พอมีอะไรพังขึ้นมา คุณก็จะเริ่มคิดว่า ยอมจ่ายเพิ่ม $20 ดีกว่าไหม แทนที่จะเสียเวลา 2~3 ชั่วโมงไปกับการซ่อมมัน

  • ข้อดีสูงสุดของ dedicated server ของ Hetzner (บางรุ่น) คือแบนด์วิดท์ไม่จำกัด ผมโฮสต์เว็บที่เน้นรูปภาพ และตั้งแต่ย้ายมา Hetzner ผมก็จ่ายในราคาเดิมมา 3 ปีเต็มและนอนหลับสบายตอนกลางคืนได้

  • Hetzner มีข้อจำกัดชัดเจนเวลา scale เราก็เคยรัน VM หลายร้อยตัวบน Hetzner ในช่วงแรก และตอนพีคต้องขยายเกินพันตัว แต่พอถึงจุดนั้นก็เริ่มมีปัญหา: บางครั้งได้ IP ที่ติด blacklist ทำให้เชื่อมต่อกับ AWS, Google (โดยเฉพาะ S3) ได้ลำบาก แล้วบางช่วงในรีเจียนที่เราใช้ก็ไม่มี VM เหลือให้จอง จนหยุดการจัดสรรใหม่ไปเลย สุดท้ายแล้ว ถ้าไม่ต้องการ scale ระดับใหญ่ Hetzner ก็ยอดเยี่ยม แต่พอจำเป็นต้องขยายจริง ๆ เราต้องผสมกับบริการอื่น

    • เรื่อง VM หมดในรีเจียนดูจะไม่ใช่ปัญหาเฉพาะคลาวด์เจ้าใดเจ้าหนึ่ง GCP เองเมื่อหลายปีก่อนก็คล้ายกัน ถ้าขอ VM ทีเดียวหลายร้อยเครื่องช่วงพีค ดูเหมือนคลาวด์ไหนก็ลำบากทั้งนั้น

    • เรื่องที่ Microsoft บล็อกบริการจาก Hetzner กับ Scaleway เป็นเรื่องที่รู้กันดี https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/ ผมไม่รู้ว่า AWS หรือ GCP ก็เคยทำแบบนั้นด้วย แต่ก็ไม่ถึงกับน่าแปลกใจ Big Cloud มักอ้างเรื่อง “ปริมาณสแปมที่ไหลเข้า” เพื่อให้เหตุผลกับพฤติกรรมกึ่งผูกขาดแบบนี้ ทั้งที่ความจริงไม่ใช่แบบนั้น

    • ที่คุยกันอยู่อาจเป็นความต่างระหว่างผู้ใช้ฮาร์ดแวร์จริงของ Hetzner (เช่น Server Auction) กับผู้ใช้เซิร์ฟเวอร์เสมือน (VM) ก็ได้ เซิร์ฟเวอร์จริงให้ความคุ้มค่าและความเร็วที่ดีกว่ามาก ส่วน VM แม้ไม่ถึงขั้นปฏิวัติวงการ แต่ก็ยังถูกกว่าคู่แข่ง

    • ประเด็นนี้พูดถึง Hetzner Cloud product (VM) โดยตรง สินค้า Cloud เปิดตัวทีหลังเมื่อเทียบกับ dedicated server และผู้ใช้จำนวนมากก็หันมา Hetzner เพราะคุณค่าของ dedicated server มากกว่า

    • ผมอยากรู้จริง ๆ ว่าต้องเป็นบริการแบบไหนถึงต้องใช้ VM หลักร้อยถึงหลักพัน และทำไมถึงเลือก VM แทน dedicated server เท่าที่เห็น VM สเปกสูงสุดของ Hetzner อยู่ที่ประมาณ 48 คอร์, RAM 192GB, SSD 960GB เลยสงสัยว่าต้องการสเกลแบบไหนกันแน่

  • แม้จะมีเหตุผลให้ใช้ Hetzner แต่ก็มีข้อควรระวังอยู่บ้าง ความพร้อมใช้งานอาจด้อยกว่า AWS เล็กน้อย และความหลากหลายของรีเจียนก็น้อยกว่า ดังนั้นผมแนะนำให้ใช้คู่กับ Cloudflare เสมอ บน Hetzner ให้รันระบบแกนหลัก (K8s) แล้วเอาข้อมูลไปเก็บบน R2/D1/KV และกระจายผ่าน Edge Durable Objects โดย shard ข้อมูลลูกค้าตามแต่ละ DO เพื่อช่วยกระจายโหลดของฐานข้อมูลหลักพร้อมเพิ่มความปลอดภัยไปด้วย

    • AWS เองก็น่าประหลาดใจเหมือนกันว่ามี outage ใหญ่ไม่น้อย สุดท้ายถ้าไม่ได้ออกแบบแบบ multi-region ก็หลีกเลี่ยงปัญหา availability ในเชิงโครงสร้างได้ยากอยู่ดี

    • ผมก็ออกแบบให้แกนหลักและสตอเรจมีความซ้ำซ้อนบน dedicated server ของ Hetzner แล้วเพิ่ม edge node ทั่วโลกบน OVH ให้ทำงานคล้าย CDN ส่วนตัว

    • ถ้าข้อมูลลูกค้าอยู่ที่ edge แล้ว “แกนหลัก” ที่ว่าหมายถึงอะไรโดยเฉพาะ