ฉันกลับไปใช้ AWS แล้วก็ตระหนักอีกครั้งว่าทำไมฉันถึงเลิกใช้มัน

 (fourlightyears.blogspot.com)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะสนับสนุน AWS มาตั้งแต่ช่วงแรก แต่เมื่อมีทั้งช่วงเวลาที่ปล่อยให้ client library เป็นภาระของคอมมูนิตี้, ความล่าช้าในการย้ายไป Python 3, ระบบคิดค่าบริการและ IAM ที่ซับซ้อน, รวมถึงการล็อกอินกับ AWS Lambda สะสมเข้ามา ก็ทำให้ไม่ชอบ AWS อีกต่อไป
  • หลังใช้ DynamoDB ก็เคยเจอบิล 75 ดอลลาร์ ภายในวันเดียว และแม้ค่ารับส่งข้อมูลขาออกจะลดจาก 20 เซนต์ต่อ GB เหลือ 9 เซนต์ แต่ก็ยังมองว่าโครงสร้างที่เก็บเงินแม้แต่การย้ายข้อมูลภายในยังแพงและเข้าใจยากอยู่ดี
  • หลังออกจาก AWS ก็ปิดบัญชีไปเกือบทั้งหมด แต่ยังคงโดเมนบน Route53, แบ็กอัปบางส่วนบน S3 และ AWS WorkMail เอาไว้ ก่อนจะได้รับแจ้งภายหลังว่าบริการ WorkMail จะยุติภายใน 12 เดือน
  • ไม่นานมานี้ได้กลับไปล็อกอิน AWS อีกครั้งเพื่อทดสอบการทำงานของ Claude/Anthropic บน AWS Bedrock และทดสอบ EC2 Spot ขนาด 192 คอร์·RAM 1TB โดยมองว่า Bedrock ให้ผลลัพธ์เหมือนกันแต่ช้ากว่า และแพงกว่าการสมัคร Anthropic มาก
  • ระหว่างทดสอบ EC2 Spot ราว 3 ชั่วโมง ก็ได้รับการแจ้งเตือน Suspected security breach แล้วบัญชีก็ถูกจำกัดสิทธิ์ ทำให้อีเมลธุรกิจบน WorkMail และการสร้างรีซอร์สใช้งานไม่ได้ และแม้จะดำเนินการตามที่แจ้งและคุยกับฝ่ายซัพพอร์ตแล้ว ก็ยังไม่ถูกปลดข้อจำกัดตลอด 4 วัน จึงตัดสินใจย้ายทั้ง AWS WorkMail และ Route53

จากผู้สนับสนุน AWS ยุคแรกสู่การตีตัวออกห่าง

  • สนับสนุน AWS อย่างมากตั้งแต่สมัยที่ยังเป็นบริการขนาดเล็กกว่าในยุคที่มี SQS, S3, EC2 และ SimpleDB เป็นหลัก และยังเป็นผู้จัดงานแรกใน Melbourne ที่เชิญตัวแทน AWS จากสหรัฐฯ มาพูดถึง AWS
  • คลาวด์คอมพิวติงคือความเปลี่ยนแปลงครั้งใหญ่ที่ทำให้สตาร์ทอัพสามารถรันระบบคอมพิวเตอร์ของตัวเองได้ภายในไม่กี่นาที โดยไม่ต้องติดตั้งและดูแลระบบในดาต้าเซ็นเตอร์เอง
  • เชื่อมั่นใน AWS อย่างมากอยู่ราว 15 ปี แต่เมื่อเวลาผ่านไป ปัจจัยที่ชวนอึดอัดก็ค่อย ๆ สะสม จนถึงจุดหนึ่งก็เลิกชอบ AWS ไปในที่สุด

ความไม่พอใจต่อ AWS ที่สะสมตามกาลเวลา

  • Client library และการย้ายผ่าน Python

    • ในช่วง 6 ปีแรก AWS ไม่ได้สร้าง client library ของตัวเอง แต่ปล่อยให้คอมมูนิตี้เป็นผู้ทำไลบรารีสำหรับภาษาอย่าง Python ซึ่งถูกมองว่าเป็นการผลักภาระไปให้โปรแกรมเมอร์ที่ต้องสละเวลาฟรี
    • การที่ AWS ใช้เวลานานเกินไปในการย้ายจาก Python 2 ไป Python 3 ก็ยังคงเป็นข้อไม่พอใจสำคัญ

  • DynamoDB และประสบการณ์ด้านค่าใช้จ่าย

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

  • ค่ารับส่งข้อมูลและโครงสร้างราคาที่ซับซ้อน

    • ค่า data egress ของ AWS ในอดีตอยู่ที่ 20 เซนต์ ต่อ GB และภายหลังก็ลดลงเหลือ 9 เซนต์ต่อ GB แต่ก็ยังมองว่าแพงมากอยู่ดี
    • แม้แต่การย้ายข้อมูลระหว่างระบบภายใน AWS เองก็ยังมีการคิดเงิน และในบางกรณีก็ให้ความรู้สึกเหมือนถูกคิดเงินซ้ำสองซ้ำสาม จนถ้าไม่เข้าใจรายละเอียดลึกพอก็ยากจะเลี่ยงกับดักค่าบริการได้

  • IAM และความซับซ้อนโดยรวม

    • IAM เป็นระบบที่จัดการการยืนยันตัวตนและกฎการเข้าถึง แต่ถูกมองว่ามีโครงสร้างที่ซับซ้อนเกินไป
    • ผู้สนับสนุน AWS มักพูดว่าการดูแล Linux, ฮาร์ดแวร์, เครือข่าย และความปลอดภัยเองนั้นซับซ้อนเกินไปจึงควรใช้ AWS แต่ก็มองว่าแทบทุกส่วนของ AWS เองก็เต็มไปด้วยความซับซ้อนขนาดใหญ่ จนสุดท้ายก็ยังต้องมีทีมผู้เชี่ยวชาญราคาแพงอยู่ดี

  • AWS Lambda และ vendor lock-in

    • AWS Lambda ชูจุดเด่นเรื่องการสเกล แต่ต้องแลกกับเวลาเริ่มต้นที่ช้าและความซับซ้อนในการพัฒนาที่สูง
    • มองว่าเมื่อเทียบกับการรันเว็บเซิร์ฟเวอร์เองแล้ว แทบไม่มีข้อดีจริงแต่มีข้อเสียมาก และตอนออกจาก AWS ส่วนที่ย้อนกลับได้ยากที่สุดก็คือ AWS Lambda
    • การใช้ AWS Lambda กลายเป็นประสบการณ์ที่ทำให้เห็นว่า vendor lock-in มีอยู่จริง และให้ความรู้สึกเหมือนเป็นการตัดสินใจที่ต้องคอยโน้มน้าวตัวเองต่อไปเรื่อย ๆ ว่ามันดีกว่า

  • โครงการโอเพนซอร์สและรายได้จากโฮสติ้ง

    • มองว่า AWS เดินหน้า OpenSearch, Valkey และ DocumentDB ทั้งที่โครงการอย่าง Elasticsearch, Redis และ MongoDB ได้แสดงเจตนาชัดเจนว่าไม่ต้องการให้มีการคัดลอกและนำไปทำเงิน
    • หลังจากที่คอมมูนิตี้และบริษัทเหล่านั้นสร้างตลาดขึ้นมา AWS ก็เข้ามารับรายได้จากบริการโฮสต์ และผลลัพธ์คือการเพิ่มขึ้นของไลเซนส์เชิงป้องกันอย่าง SSPL, Elastic License, RSAL รวมถึงโมเดล source-available

บริการบางอย่างที่ยังคงไว้หลังออกจาก AWS

  • หลังหมดความผูกพันกับ AWS ก็ย้ายทุกอย่างออกไปนอก AWS และปิดบัญชีไปเกือบทั้งหมด
  • อย่างไรก็ตาม ยังเหลือบางบริการไว้เพราะในตอนนั้นมองว่าเป็นทางออกที่เหมาะสมจริง
  • สิ่งที่คงไว้คือโดเมนบน Route53, แบ็กอัปบางส่วนบน S3 และ AWS WorkMail
  • ต่อมามีการแจ้งว่า AWS WorkMail จะถูกยุติภายใน 12 เดือน

เหตุผลที่กลับไปหา AWS ชั่วคราว

  • ช่วงหลังได้กลับไปล็อกอิน AWS อีกครั้งเพื่อการวิจัยและการทดสอบ
  • ต้องการตรวจสอบว่า Claude/Anthropic ทำงานได้ดีแค่ไหนบน AWS Bedrock และในมุมของ Claude Code ก็มองว่าผลลัพธ์เหมือนกันแต่ช้ากว่า และแพงกว่าการสมัคร Anthropic มาก
  • อุปกรณ์ที่บ้านที่เร็วที่สุดมี CPU 20 คอร์และ RAM 32GB จึงต้องการ benchmark ว่าโค้ดจะรันได้เร็วแค่ไหนบนเครื่องที่มี 192 คอร์ และ RAM 1TB
  • การทดสอบ AWS Bedrock เมื่อราวหนึ่งเดือนก่อนจบลงโดยไม่มีปัญหา และหลังทดสอบก็ปิดทุกอย่างเรียบร้อย
  • มองว่า AWS Bedrock อาจมีประโยชน์ถ้าต้องการความเป็นส่วนตัว แต่เพราะเรื่องค่าใช้จ่ายจึงคงไม่กลับไปใช้ Claude ผ่าน AWS Bedrock อีก

บัญชีถูกจำกัดระหว่างทดสอบ EC2 Spot

  • หลังจากนั้นได้รัน EC2 Spot instance แบบ 192 คอร์เพื่อทดสอบอยู่ราว 3 ชั่วโมง แล้วก็ได้รับอีเมลจาก AWS ที่ระบุว่า “Suspected security breach of your account”
  • มองว่าเป็นไปได้ที่ระบบเตือนความปลอดภัยภายในของ AWS จะถูกกระตุ้น เพราะบัญชีที่แทบไม่ได้ใช้งานจู่ ๆ ก็เริ่มใช้ทรัพยากรคอมพิวต์ราคาแพงขึ้นมา
  • เข้าใจและประเมินในทางบวกต่อเจตนาของ AWS ที่ต้องการปกป้องผู้ใช้
  • แต่ AWS ได้ระงับหรือจำกัดบัญชี และผลก็คือบัญชีอีเมลธุรกิจหลักที่ใช้อยู่บน AWS WorkMail ใช้งานไม่ได้
  • ไม่มีใครส่งอีเมลมาได้อีก และก็ไม่สามารถสร้าง AWS resource ใด ๆ ได้ ทำให้การทดสอบที่ตั้งใจจะทำต่อก็เดินหน้าต่อไม่ได้

การตอบสนองจากซัพพอร์ตและความล่าช้า

  • ได้ตอบกลับการแจ้งเตือนจาก AWS Support ว่าบัญชีไม่ได้ถูกแฮ็ก และไม่มีปัญหาหรือความผิดปกติด้านการเรียกเก็บเงิน แต่ก็ไม่ได้รับคำตอบ
  • เนื่องจากไม่ได้ใช้ premium support จึงต้องรอเวลาตอบกลับ 24 ชั่วโมงตามที่ AWS ระบุ และแม้ผ่านไป 3 วันก็ยังไม่มีการตอบกลับจาก AWS Support
  • หลังไปขอความช่วยเหลือในฟอรัมของ AWS ก็ได้รับคำแนะนำให้ทำตามคำสั่งในอีเมล และให้ใช้แชตแทนเว็บ
  • ได้ทำทุกขั้นตอนที่ร้องขอแล้ว ทั้งเปลี่ยนรหัสผ่าน ลบ access token ตรวจสอบประวัติการเรียกเก็บเงิน ฯลฯ และหลังรอเชื่อมต่อแชตราว 30 นาที ก็ได้พูดคุยกับเจ้าหน้าที่ AWS เป็นเวลานาน
  • เจ้าหน้าที่ดูเหมือนจะพอใจและบอกว่าจะส่งเรื่องให้ทีมภายในที่เกี่ยวข้องดำเนินการ แต่แม้ผ่านไป 24 ชั่วโมงแล้ว ข้อจำกัดก็ยังไม่ถูกยกเลิก
  • เมื่อมีการติดตามผลอีกครั้งหลังจากนั้น 8 ชั่วโมง ก็ได้รับเพียงคำตอบว่า “โปรดรอต่อไป”

บทสรุปที่ได้รับการตอกย้ำอีกครั้ง

  • แม้ผ่านไป 4 วันนับจากวันที่บัญชีถูกจำกัด ก็ยังมีงานที่อยากทดสอบบนเครื่องขนาดใหญ่อยู่ และเริ่มกังวลว่าจะต้องยื่นคำขอ “quota” ใหม่อีกเพื่อทำสิ่งนั้น
  • ระบบอีเมลสำหรับธุรกิจก็ยังใช้งานไม่ได้เช่นเดิม
  • ประสบการณ์การกลับมาครั้งนี้ย้ำชัดอีกครั้งว่าทำไมจึงเลิกใช้ AWS และทำให้ตัดสินใจว่าจะย้ายออกจาก AWS WorkMail รวมถึงย้ายโดเมนออกจาก Route53 ด้วย เพื่อจะได้ไม่ต้องกลับมาอีก
  • การที่เคยย้ายออกจาก AWS ไปแล้วส่วนใหญ่ถือเป็นเรื่องที่น่ายินดีมาก แต่การที่ระบบอีเมลซึ่งไว้ใจจนยังคงใช้ต่อกลับหยุดชะงักในกระบวนการกลับมาใช้ AWS ครั้งนี้ ถูกมองว่าเป็นความล้มเหลว
  • แม้ AWS อาจจะปลดข้อจำกัดบัญชีให้ในสักวันหนึ่ง แต่ก็ไม่รู้ว่าเมื่อไรจะเกิดขึ้น

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

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

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News

  • หลายปีก่อนผมเข้าร่วมบริษัทแห่งหนึ่ง รับหน้าทีมพัฒนา และถูกขอให้ออกผลิตภัณฑ์ภายใน 3 เดือน แต่พอจะเพิ่มเครื่องใหม่บน AWS ก็รู้สึกว่า โครงสร้างที่ไม่แสดงราคาใน UI เป็นสัญญาณของความสัมพันธ์ที่เป็นปฏิปักษ์และเอาเปรียบ
    ต้องเปิดตารางสเปกกับตารางราคาแยกกันแล้วเทียบเอง และจากประสบการณ์ที่ผ่านมา ผมมองว่าถ้าเห็นสัญญาณแบบนี้แล้วยังไม่ยอมออกไป ผลลัพธ์หลังจากนั้นก็เป็นความรับผิดชอบของผมเอง
    เลยสร้างบัญชี DigitalOcean แล้วย้ายทั้งหมดไปที่นั่น พร้อมตั้งค่าให้ CI/CD deploy ไปทางนั้นด้วย และใช้เวลาสองเดือนที่เหลือโฟกัสกับตัวผลิตภัณฑ์จนเปิดตัวได้เร็วกว่าที่สัญญาไว้ 1 เดือน
    ผมเคยเห็นวิดีโอขุดหลุมริมแม่น้ำแล้วต่อท่อจากแม่น้ำเข้าหลุม เพื่อให้ปลาว่ายเข้ากับดักเอง ภาพนั้นทำให้ผมจำได้ฝังใจว่า การเลือกทางที่ต้านทานน้อยที่สุดและไม่ยอมย้อนแก้ความผิดพลาด คือเคล็ดลับที่จะจบแบบปลาเหล่านั้น

    • อย่างหนึ่งที่ผมชอบใน Azure คือ เวลาสร้างรายการแต่ละอย่าง มันไม่ได้ยัดเยียดราคาเกินไป แต่กับรายการที่อาจแพงก็มักจะ แสดงราคาอย่างสมดุล
      จนถึงตอนนี้ยังไม่เคยโดนค่าใช้จ่ายทำให้ตกใจ
    • วัฒนธรรมวิศวกรรมของ Amazon ดูจะเป็น วัฒนธรรมผลิตภัณฑ์ที่ขับเคลื่อนโดยวิศวกร ค่อนข้างมาก เลยอาจทำให้นักพัฒนาต้องรับผิดชอบถึงขั้น UX และ flow ด้วย
      ผมเคยจ้างนักพัฒนารุ่นจูเนียร์ที่เพิ่งจบฝึกงาน AWS มา เขาโชว์แดชบอร์ดที่ทำคนเดียวตลอดฤดูร้อนโดยไม่มีผู้จัดการผลิตภัณฑ์หรือดีไซเนอร์ช่วยเลย และมันดูแย่มากจริงๆ
      นักพัฒนาบางคนมีเซนส์ด้านผลิตภัณฑ์/UX ที่ดี แต่คนส่วนใหญ่ค่อนข้างอ่อนเรื่อง UX มาก ดังนั้นมันอาจไม่ใช่ความตั้งใจร้าย แต่เป็นไปได้มากกว่าว่าเป็นวัฒนธรรม UX ที่แย่
    • วิธีที่ถูกต้องคือเลือก ผู้ให้บริการโครงสร้างพื้นฐานที่ช่วยให้คุณออกของได้
      AWS นั้นดี แต่ไม่เหมาะกับทุกคน และมีตำแหน่งบางจุดระหว่างบริการอย่าง Heroku กับ bare metal ที่ช่วย abstract งานดูแลออกไปมาก แต่ยังให้คุณควบคุมสถาปัตยกรรมการขยายระบบได้บางส่วน
      กล่าวคือ ในฐานะผู้ให้บริการคลาวด์ AWS ช่วยเรื่องการขยายระบบได้ แต่ไม่ใช่เครื่องมือสำหรับสร้างระบบที่ถูกและเรียบง่ายที่สุด
      ถ้ามีเงิน VC และชูเรื่องการเติบโต AWS อาจเป็นทางเลือกที่ปลอดภัย และด้วย startup credit 2 ปีจาก accelerator คุณก็โฟกัสกับการสร้างมากกว่างบ infra ได้ในช่วง 18 เดือนแรก
      ถ้าเป็นสาย bootstrap หรือ indie developer ก็เลือกสิ่งที่เรียบง่ายและรับไหวพอ และ Hetzner หรือ DigitalOcean ก็ใช้งานได้ดีมากแล้ว
    • AWS มี เครื่องคำนวณราคา ที่ค่อนข้างดีและมี preset ที่พอใช้ได้ แต่แน่นอนว่ามันเป็นแอปแยกต่างหากโดยสิ้นเชิง
      Amazon คงอยากให้มีแรงเสียดทานเล็กน้อยเวลาจะดูข้อมูลราคาได้ง่ายๆ แต่เหตุผลหลักดูจะเป็นกฎของ Conway มากกว่า
      AWS ยังปล่อยผังองค์กรของตัวเองออกมาในรูปของผลิตภัณฑ์อยู่
    • ผมเห็นด้วยระดับหนึ่ง แต่ราคาของ AWS ไม่ได้ง่ายพอที่จะคำนวณว่าจะจ่ายเท่าไรจากตัวเลขคงที่ตัวเดียวที่แสดงใน UI
      ถ้าการต้องเปิดสองแท็บเพื่อเทียบค่าใช้จ่ายเป็นเรื่องน่ารำคาญ คุณอาจควรหลีกเลี่ยงไม่ใช่แค่ AWS แต่รวมถึงผู้ให้บริการคลาวด์ทั้งหมด
      พอมี NAT Gateway, CloudFront, S3, auto scaling, load balancer เข้ามา การคำนวณต้นทุนก็ใกล้เคียงกับศิลปะมากกว่าวิทยาศาสตร์ที่แม่นยำ
      ถ้าไม่ได้ใช้พวกนี้ ก็แทบไม่มีเหตุผลอะไรให้ใช้ AWS และมีผู้ให้บริการ VPS ราคาถูกอีกมาก

  • ถ้ามองเฉพาะ OpenSearch กับ Valkey คำอธิบายว่า “AWS สร้าง fork เลยทำให้เกิดการเปลี่ยนไลเซนส์” นั้นกลับด้านทั้งหมด
    AWS สร้าง fork หลังจาก upstream project เปลี่ยนไลเซนส์แล้วเท่านั้น และโดยเฉพาะ Valkey นั้นถูกสร้างโดยอดีตสมาชิกทีมพัฒนาหลักของ Redis

    • หลายโปรเจกต์ลักษณะนี้ใช้โมเดลธุรกิจที่เปิดซอร์สผลิตภัณฑ์หลัก แล้วหารายได้จากบริการระดับสูง การติดตั้ง การดูแลรักษา และ fully managed service
      AWS ไปทำ fully managed service เพื่ออ้อมพวกเขา ดังนั้นในกรณีนี้ผมอยู่ข้างคนที่สร้างโปรเจกต์
      โดยพื้นฐานแล้ว AWS แย่งชามข้าวของพวกเขาไป และพวกเขาเลยไม่มีทางเลือกนอกจากต้องเปลี่ยนไลเซนส์
    • การเปลี่ยนไลเซนส์นั้นเองก็เป็นการตอบโต้ต่อวิธีที่ AWS สร้างรายได้จากงานของ upstream project ในแบบที่ไม่ยั่งยืนสำหรับพวกเขา
    • ผมสงสัยว่าถ้า Amazon จ่ายให้ผู้สร้างและผู้ดูแลรักษา ซอฟต์แวร์โอเพนซอร์ส ที่ตัวเองขายอยู่เพียง 1 เซนต์ต่อรอบการเรียกเก็บเงิน จะกระทบแค่ไหน
      และก็สงสัยด้วยว่ามันจะกลายเป็นเงินที่พอมีความหมายกับทีมโอเพนซอร์สหรือไม่ และอาจทำให้พวกเขากล้าร่วมพัฒนาผลิตภัณฑ์โดยไม่ต้องเสี่ยงมากขึ้น
    • ตั้งแต่ครั้งแรกที่ผมส่งแพตช์ให้ Redis แล้วมี committer คนหนึ่งไม่ตอบข้อความผม แต่เอาแพตช์นั้นเข้าไปในชื่อของตัวเอง ความเห็นใจที่ผมมีต่อปรัชญาของโปรเจกต์โอเพนซอร์สหลายแห่งก็หายไปมาก
      พวกเขาสมควรได้เจอ Valkey
      ผมยังจำ JBoss กับ Marc Fleury ได้อยู่
    • เป็นเรื่องปกติอยู่แล้วที่ AWS จะสร้าง fork ก็ต่อเมื่อมีการเปลี่ยนไลเซนส์เพื่อไม่ให้ AWS หาเงินจากโค้ดของโปรเจกต์นั้นได้
      นั่นแหละคือประเด็นสำคัญ

  • ผมสลับไปมาระหว่างบริการคลาวด์กับ self-hosting หลายครั้ง
    ตอนแรกใช้ Vercel และเพราะโปรเจกต์เป็น Next.js ประสบการณ์ก็โอเค แต่ต้องจ่าย 20 ดอลลาร์ต่อเดือนสำหรับโปรเจกต์ที่มีผู้ใช้ไม่ถึง 100 คน เลยรู้สึกว่าแพงเกินไปสำหรับบริการที่ไม่ได้ต้องการประสิทธิภาพสูง
    หลังจากนั้นผมตั้งเซิร์ฟเวอร์เองด้วย Hetzner และ Coolify ซึ่งเพราะ Coolify เป็นโอเพนซอร์ส ผมจ่ายแค่ค่า VPS และเดือนละ 5 ดอลลาร์ก็รัน PostgreSQL instance กับเว็บเซิร์ฟเวอร์ได้แล้ว
    แต่ก็ยังต้องลงมือดูแล PostgreSQL กับ Redis มากอยู่ดี และถึงจะอยู่ใน Docker container การส่ง system variable กับ environment variable ระหว่างบริการก็ยังยุ่งยาก
    เลยย้ายอีกครั้งไปที่ Cloudflare Workers, D1 Database, Cloudflare KV ซึ่งเรียกใช้ได้ตรงจากใน Worker เลย ไม่ต้องส่ง environment variable กันอีก
    ประสบการณ์ฝั่ง local development ก็ดี และราคาก็สมเหตุสมผล ตั้งแต่นั้นมาผมก็ใช้ผลิตภัณฑ์ชุด Cloudflare ต่อมาเรื่อยๆ

    • สิ่งที่ Cloudflare มีให้ตอนนี้ใกล้กับสิ่งที่ผมอยากได้จาก AWS มากกว่า
      แอป full-stack และการ deploy ไฟล์ แบบพื้นฐานนั้นง่ายกว่ามาก และ AWS ตอนนี้ยากกว่าการ self-hosting เสียอีก
    • ผมสงสัยว่า Docker ช่วยให้การดูแล PostgreSQL ง่ายขึ้นหรือเปล่า
      ปัญหาเดียวที่ผมเจอกับ PostgreSQL คือมีงาน migration เล็กน้อยตอนย้ายไป major version ใหม่
      และก็สงสัยเหมือนกันว่าการส่ง system variable กับ environment variable ระหว่างบริการนั้น Docker ทำให้ยากขึ้นหรือไม่
    • ผมอยากจะชอบ Cloudflare Workers และคงมีเหตุผลเชิงเทคนิคดีๆ อยู่ แต่แนวทางที่ต้องใช้ Wrangler project กับงานอย่างการเปิดใช้ email activation ทำให้รู้สึกเหมือนอยู่ก่อนถูก lock-in กับแพลตฟอร์มนิดเดียว
      ถ้าจะอนุญาต email ก็ต้องตั้ง binding ที่จำเป็น แต่ในคอนโซลกลับตั้งค่าไม่ได้ และหลังจาก Wrangler ตั้งค่าให้แล้วก็ดูเหมือนจะมองไม่เห็นมันจากคอนโซลด้วย

  • แปลกใจที่ผู้เขียน เกลียด DynamoDB
    มันเป็นหนึ่งในบริการ AWS ที่ผมชอบที่สุด ใช้งานได้พร้อมสูง ภาระการดูแลต่ำ และทุกครั้งที่ใช้ค่าใช้จ่ายก็ค่อนข้างต่ำ
    เพียงแต่คุณต้องใช้เวลาวาง data model ล่วงหน้า และนั่นก็ต้องอาศัยการอ่านและทำความเข้าใจเอกสารของบริการ

    • DynamoDB นั้นดีมากถ้าใช้ในแบบที่มันถูกออกแบบมา
      โดยพื้นฐานแล้วควรมองมันเป็น key-value store ที่ค่อนข้างเรียบง่าย มีความคงทนที่ดีและขยายขนาดตารางได้แทบไม่จำกัด ไม่ใช่อะไรที่ควรพยายามใช้เหมือนฐานข้อมูล SQL
      วิธีที่ง่ายที่สุดในการสร้างบิล 75 ดอลลาร์จากโค้ดต้นแบบ คือ vibe coding ใส่มันเหมือนเป็นฐานข้อมูล SQL ที่มี JOIN และ GROUP BY
      จุดที่มันเปล่งประกายจริงๆ คือเวลาคุณต้องการตารางเล็กๆ สำหรับเก็บข้อมูลถาวร 1-2 ตาราง แต่ไม่อยากดูแล RDBMS ทั้งชุด หรือเวลาคุณมีตารางใหญ่มากเพียงตารางเดียวที่ต้อง query แบบเรียบง่าย โดยไม่อยากฝืนให้เข้ากับ RDBMS
    • หลายบริการอย่าง DynamoDB และ Lambda มี use case ที่เฉพาะมาก
      อย่าเอา key-value store แสนสนุกไปใช้เป็นฐานข้อมูล
    • หลายปีก่อนตอนทำแอป ผมต้องการ DB สำหรับเก็บเรคคอร์ดประมาณ 50 ล้านรายการ มีการอ่าน+เขียนราว 10,000 ครั้งต่อเดือน และมี index 1 ตัว
      ค่าโหลดข้อมูลครั้งแรกอยู่ที่ประมาณ 50 ดอลลาร์ หลังจากนั้นค่าดูแลอยู่ระดับ 10 เซนต์ต่อเดือนเท่านั้น

  • อ่านบทความแบบนี้ทีไรก็อดขำไม่ได้ทุกที
    มันทั้งถูกและผิดในเวลาเดียวกัน และระบบควรถูกสร้างให้ “เรียบง่ายที่สุดเท่าที่เป็นไปได้ แต่ไม่ง่ายไปกว่านั้น”
    ถ้าคุณคิดว่าจะมองข้ามรายละเอียดได้ สุดท้ายจะเจอความยุ่งยากที่ใหญ่กว่าในภายหลัง
    IAM มันซับซ้อนอยู่แล้ว
    ผมนึกตัวอย่างของการทำ user, group, role, policy, identity provider, OIDC ให้เรียบง่ายจริงๆ ไม่ออกเลย
    ผมเคยเห็นคนที่คัดค้านการนำ Kubernetes มาใช้เพราะว่า “ซับซ้อนเกินไป” สุดท้ายกลับไปประดิษฐ์ Kubernetes ใหม่แบบหยาบๆ และชั่วคราวด้วย Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash และน้ำลายกับหญ้าแห้ง พร้อมทำพลาดไปมากมาย
    บางฟีเจอร์คุณอาจคิดว่าไม่จำเป็น แต่สุดท้ายก็ต้องใช้
    จากมุมมองของคนที่เคยทำหน้าที่ infra คนเดียวในสตาร์ตอัป AWS ยังอยู่ในขอบเขตที่คนส่วนใหญ่เรียนรู้ได้ และส่วนที่ห่วยจริงๆ ก็มักหลบเลี่ยงได้
    ถ้าไม่ชอบ Lambda ก็ไม่ต้องใช้ แค่ใช้ EKS, ECS, EC2 ก็พอ

    • ถ้ามองจากข้างใน IAM มีตัวเลือกเป็นพันๆ อย่าง แต่แก่นจริงๆ คือ “role นี้เข้าถึงอะไรและทำอะไรได้บ้าง (action + resource)” กับ “ใครเข้าถึง role นี้ได้บ้าง”
      ถ้ามองจากระดับสูง นั่นคือทั้งหมด
      เหตุผลที่ IAM ดีคือมันใช้ได้เหมือนกันทั้งภายนอกและภายใน
      ทีมภายใน AWS ไม่ได้มีสิทธิ์เข้าถึงมากกว่าเป็นพิเศษ และถ้าเกิดมีสิทธิ์ทำอะไรในบัญชีของลูกค้าเพื่อให้บริการบางอย่างได้ ก็เป็นเพราะลูกค้าใส่ service principal ไว้ใน trust relationship ของ IAM เพื่ออนุญาตการเข้าถึง และลูกค้าก็ตรวจสอบเรื่องนี้ได้
      ตัวอย่างเช่น Lambda มี Lambda role เพราะเราไม่อยากให้บริการ Lambda อ่าน S3 bucket ได้เพียงเพราะ “เราเป็น AWS เลยเข้าถึงได้อัตโนมัติ”
      ต่อให้เป็นการเข้าถึงภายใน AWS ลูกค้าก็มองเห็นและควบคุมได้อย่างชัดเจน
    • รูปแบบ “X ซับซ้อนเกินไป” แล้วสุดท้ายก็ไปสร้าง X ใหม่แบบหยาบๆ เอง เป็นเรื่องที่พบได้บ่อยอย่างน่าทึ่งในโลกเทคโนโลยีและซอฟต์แวร์
      บางอย่างตอนนี้ชัดเจนแล้วว่าเป็น มาตรฐาน แต่หลายคนก็ยังไม่ยอมใช้เวลาเรียนรู้มันให้ถูกต้อง
    • AWS อาจแพงกว่า self-hosting แต่เงินที่ประหยัดได้นั้นเล็กน้อยเมื่อเทียบกับต้นทุนด้านวิศวกรรม
      ถ้าวิศวกร infra ที่ดีใช้เวลา 2 เดือนกับระบบ OVH เพื่อ “ประหยัดเงิน” มันจะแพงกว่าการประหยัดที่คุณได้จากการไม่ใช้ Fargate หรือ RDS เสียอีก

  • ผมสงสัยว่าเมื่อไรเราจะเริ่มได้ยินเรื่องแบบเดียวกันกับ Anthropic หรือ OpenAI บ้าง
    กระแส AI ตอนนี้มีกลิ่นคล้าย AWS ยุคแรกๆ และดูเหมือนทุกคนกำลังขึ้นขี่มัน ก่อนจะมารู้ทีหลังว่าตัวเองสร้าง การพึ่งพาขนาดใหญ่ ที่ดึงออกได้ยาก

  • Lambda เจ๋งมากจริงๆ และผมคิดว่ามันเป็นวิธีที่ดีที่สุดในการรันบริการ deploy ด้วยรอบการทำซ้ำที่เร็วโดยไม่ปวดหัว
    ไม่จำเป็นต้องไปทาง microservices หรือแยกโค้ดออกเป็น repository เล็กๆ นับพันล้านอัน
    ตราบใดที่คุณไม่คาดหวังว่าจะแชร์ state ภายในเซิร์ฟเวอร์ข้ามระหว่าง request ได้ คุณก็ย้ายเว็บเซิร์ฟเวอร์มาตรฐานไปไว้บน Lambda ได้

  • ผมไม่ได้ทำงานในสายนี้ เลยแตะ AWS แค่ในโปรเจกต์สนุกๆ ส่วนตัวเป็นครั้งคราว และทุกครั้งมันเหมือนฝันร้าย
    ผมแค่อยากทำเซิร์ฟเวอร์เกมการ์ดทดลอง ไม่ได้จะตั้งสถาบันการเงินใหม่ แต่ทุกอย่างดูเหมือนถูกออกแบบโดยตั้งสมมติฐานว่าพรุ่งนี้ต้องขยายได้ไม่จำกัด และมีองค์กรพันคนกับงบ VC รองรับ
    โชคดีที่มีบริการอย่าง Netlify มาครอบด้านนอกไว้ เลยไม่ต้องต้มทะเลทั้งมหาสมุทร
    สักวันหนึ่งผมอาจต้องเรียนรู้ IAM, VPN และสิ่งที่ไม่รู้จักอื่นๆ จริงจัง แต่จนกว่าจะถึงตอนนั้น ทุกครั้งที่แตะ AWS ผมรู้สึกเหมือนตาจะถลน

    • ก็แค่เปิด raw VPS บน EC2 หรือ Lightsail แล้วผูก public IP ก็จบ
      คุณไม่จำเป็นต้องทำตาม enterprise pattern ทุกอย่าง
    • น่าทึ่งที่ Heroku จับสิ่งที่เว็บแอปส่วนใหญ่ต้องการได้ตรงเป๊ะตั้งแต่เกือบ 20 ปีก่อน
    • ถ้ายังไม่เคยแตะ Azure คุณอาจรู้สึกว่า AWS คนเดียวที่เหมือนฝันร้าย
    • ผมย้ายไป Cloudflare แล้ว รู้สึกหายใจโล่งขึ้นมาก
      มีทุกอย่างที่ต้องใช้ และราคาก็สมเหตุสมผล
    • AWS ไม่ได้เล็งไปที่โปรเจกต์ส่วนตัว แต่เล็งที่ enterprise
      โปรเจกต์ส่วนตัวสุดท้ายแล้วมีแต่เรื่องต้นทุน จึงสร้างรายได้ที่มีนัยสำคัญให้ AWS ไม่ได้

  • ตั้งแต่ปี 2023 เป็นต้นมา AWS มีการดึงคนสายเทคนิคออกจากระบบอย่างเป็นระบบ
    ผ่านทั้งการปลดคนครั้งใหญ่และแผนปรับปรุงผลงานสองรอบ และเพื่อนร่วมงานที่เก่งๆ ฝั่ง presales หรือ support หลายคนก็ไม่ได้อยู่กับ AWS แล้ว
    ในทางกลับกัน ผมเห็นบ่อยว่าคนที่มีประวัติผลงานคลุมเครือที่สุดกลับอยู่ต่อและได้เลื่อนตำแหน่ง
    ใครจะใช้ AWS ก็ต้องยอมรับความเสี่ยงกันเอง และ Paul Vixie จะไม่โผล่มาช่วยกู้สถานการณ์

  • ElastiCache เป็นสิ่งที่กวนใจผมมานานแล้ว
    RDS ยังพอมีคุณค่าเพิ่ม เช่น scalability, การตั้งค่าที่ปรับให้เหมาะมาในระดับหนึ่ง, backup ที่ไม่ต้องคอยกังวล เลยพอทำใจจ่ายได้
    แต่ ElastiCache แทบไม่มีมูลค่าเพิ่มอะไรเลย ขณะที่ราคากลับให้ความรู้สึกเหมือนถูกรีดไถ
    เมื่อเทียบกับการติดตั้ง Redis แบบพื้นฐาน มันทั้งช้ากว่า ปรับแต่งแย่กว่า เสถียรน้อยกว่า และ Redis ที่ไม่ตั้งค่าอะไรเลยรองรับหลาย DB แต่ ElastiCache รองรับแค่หนึ่งเดียว
    มันมีการปรับปรุงด้าน scalability อยู่บ้าง แต่ Redis พื้นฐานบน instance ใกล้เคียงกันทิ้งห่าง ElastiCache มากจนแทบไม่มีกรณีไหนที่การปรับปรุงนั้นจำเป็นจริงๆ

    • ElastiCache เป็นหนึ่งในบริการที่ควรพิจารณา self-hosting อย่างแน่นอน
      AWS ไม่ได้เพิ่มอะไรให้มากนักทั้งในแง่ API หรือความสมบูรณ์ของบริการ ในทางกลับกัน Redis/Valkey ก็เป็นหนึ่งในบริการที่โฮสต์เองได้ง่ายที่สุดอยู่แล้ว