20 ปีที่ใช้เวลาร่วมกับ AWS และไม่เคยพูดเลยว่า “ไม่ใช่งานของฉัน”

• Colin Percival ผู้ดูแลความปลอดภัยของ FreeBSD และผู้ก่อตั้ง Tarsnap ได้เขียนย้อนทบทวนตามลำดับเวลา ตั้งแต่การสร้างบัญชี AWS แรกในปี 2006 จนถึงปัจจุบัน ตลอดระยะเวลา 20 ปีที่เขามีส่วนร่วมอย่างกว้างขวางต่อการพัฒนา AWS ในฐานะ ผู้มีส่วนร่วมภายนอกที่ไม่ใช่พนักงานอย่างเป็นทางการ ทั้งการสร้างการรองรับ FreeBSD บน EC2 การค้นพบและรายงานช่องโหว่ด้านความปลอดภัยล่วงหน้า ไปจนถึงการให้ข้อเสนอแนะด้านการออกแบบบริการ
• AWS ยุคแรกต้องเปิดใช้งานแต่ละบริการแยกกัน โดยบริการที่เปิดให้ใช้งานพื้นฐานตั้งแต่แรกมีเพียง Amazon SQS และ Amazon E-Commerce Service ที่แทบไม่มีใครรู้จัก
• เพื่อให้ FreeBSD ทำงานบน EC2 ได้ ต้องแก้ปัญหาทางเทคนิคตลอดหลายปี ทั้งเรื่องความเข้ากันได้ของเวอร์ชัน Xen, การรองรับ PAE และการเปลี่ยนผ่านสู่ HVM ก่อนจะสำเร็จเป็นครั้งแรกบน t1.micro ในปี 2010
• เขาค้นพบและรายงานประเด็นความปลอดภัยหลายอย่างล่วงหน้า เช่น ช่องโหว่การชนกันจากการทำ normalization ในระบบลายเซ็นคำขอของ AWS, ความเสี่ยงการเปิดเผย credential ผ่าน IMDS (ซึ่งเกิดขึ้นจริงในเหตุเจาะระบบ Capital One ปี 2019) และปัญหาความปลอดภัยของ Seekable OCI
• ตั้งแต่ปี 2024 เขาได้รับการสนับสนุนผ่าน GitHub Sponsors จาก Amazon เพื่อดูแล FreeBSD/EC2 ต่อไป และเป็นตัวอย่างของการสร้างผลงานร่วมกับวิศวกร Amazon ได้แม้ในฐานะผู้มีส่วนร่วมภายนอกที่ไม่มีสิทธิ์เข้าถึงระบบภายใน

---

การสร้างบัญชี AWS และบริการยุคแรก

• วันที่ 10 เมษายน 2006 เขาสร้างบัญชี AWS แรกหลังเห็นการประกาศ Amazon S3 โดยมีแรงจูงใจจากความสนใจในบริการจัดเก็บข้อมูลออนไลน์ และก่อนหน้านั้นก็มีประสบการณ์สร้าง เว็บเซอร์วิสบน HTTP มาตั้งแต่ปี 1998
• AWS ยุคแรก ผู้ใช้ต้องขอเปิดใช้งานแต่ละบริการแยกในบัญชี และบริการที่ให้มาโดยปริยายมีเพียง Amazon SQS กับ Amazon E-Commerce Service (API แคตตาล็อกสินค้าสำหรับพาร์ตเนอร์ของ Amazon)
  • Amazon E-Commerce Service ถือเป็นบริการ AWS แรกอย่างแท้จริง แต่แทบไม่มีใครรู้จัก และภายหลังก็ถูกลบออกจากประวัติศาสตร์ AWS อย่างเงียบ ๆ

ความสนใจด้านความปลอดภัยในช่วงแรกและข้อเสนอแนะ

• จากประสบการณ์ในฐานะ FreeBSD Security Officer เขาสนใจโครงสร้างความปลอดภัยของ AWS ทันที และชี้ให้เห็นว่าแม้คำขอ AWS จะถูก เซ็นด้วย API key เพื่อรับรองตัวตนและความถูกต้องของข้อมูล แต่ฝั่ง response ไม่มีการเซ็น
• ตอนนั้นการส่งคำขอ AWS ผ่าน HTTP ยังเป็นเรื่องปกติ ทำให้ ความเป็นไปได้ในการแก้ไข response ระหว่างทาง เป็นความเสี่ยงที่เกิดขึ้นได้จริง และแม้หลังจากเปลี่ยนไปใช้ TLS แล้ว เขาก็ยังเห็นว่าการเซ็นแบบ end-to-end เหนือกว่าความปลอดภัยระดับ transport

FreeBSD บน EC2 — ความท้าทายในระยะแรก

• ไม่นานหลัง EC2 เปิดตัว เขาตั้งเป้าให้ FreeBSD รันได้บนแพลตฟอร์มนี้ และได้ติดต่อบุคคลภายใน Amazon ผ่าน Jeff Barr จนเซ็น Amazon NDA ฉบับแรกในต้นปี 2007
  • ตอนนั้น Amazon ยังใช้แฟกซ์อยู่ แต่เพราะเขาไม่มีเครื่องแฟกซ์ จึงต้องส่งเอกสารฉบับที่เซ็นแล้วทางไปรษณีย์ ทำให้การบรีฟครั้งแรกล่าช้าออกไป
• EC2 เปิดตัวในช่วงแรกโดยยังไม่รองรับ custom kernel (ลักษณะคล้าย AWS Lambda ปัจจุบัน) และเมื่อความสามารถนี้ถูกเปิดใช้พร้อมการรองรับ Red Hat ในเดือนพฤศจิกายน 2007 บัญชี FreeBSD ของเขาก็ได้รับสิทธิ์เข้าถึง API ภายในสำหรับ “เผยแพร่ Amazon Kernel Images” ด้วย

การตรวจสอบความปลอดภัยของ Xen และการเตือนเรื่อง side-channel attack

• เดือนมีนาคม 2007 เขาเสนอให้ผู้เกี่ยวข้องใน Amazon ทำ security audit ของ Xen และเมื่ออีกฝ่ายไม่รู้จะหาผู้ตรวจสอบที่เหมาะสมจากที่ใด เขาก็แนะนำ Tavis Ormandy
  • ภายในปีเดียวกัน Tavis รายงานช่องโหว่ Xen 2 รายการ (CVE-2007-1320, CVE-2007-1321) แต่ไม่ชัดเจนว่ามีความเกี่ยวข้องกับคำแนะนำนั้นหรือไม่
• ในงานพบปะผู้ใช้ AWS ภายใน Second Life ที่จัดโดย Jeff Barr เขาเสนอฟีเจอร์ดิสก์รากแบบอ่านอย่างเดียวและการรับประกันว่าหน่วยความจำจะถูกล้างเมื่อรีบูต เพื่อรองรับสถานการณ์รันโค้ดที่ไม่น่าเชื่อถือ เช่น การ build package ของ FreeBSD ซึ่งต่อมา EC2 Instance Attestation เพิ่งเปิดตัวหลังจากนั้นอีก 18 ปี
• ในงาน re:Invent ปี 2012 เขาอธิบายงานวิจัยเรื่อง การขโมยกุญแจ RSA ผ่าน HyperThreading ให้ Principal Engineer ของ EC2 ฟัง และแนะนำอย่างหนักแน่นว่าไม่ควรรันอินสแตนซ์ EC2 แบบขนานบนสองเธรดของคอร์เดียวกัน
  • ว่ากันว่าคำแนะนำนี้เป็นเหตุผลหนึ่งที่หลายตระกูลอินสแตนซ์ EC2 ข้ามขนาด “medium” ไปเริ่มที่ 2 vCPU (“large”) เลย

Eventual Consistency และข้อเสนอเชิงทฤษฎี

• ปลายปี 2007 เขาเขียนบล็อกโพสต์ที่ถูกอ่านอย่างกว้างขวางภายใน Amazon โดยชี้ปัญหาของ Eventual Consistency และเสนอโมเดลที่เข้มกว่าเล็กน้อยชื่อ Eventually Known Consistency
  • เป็นแนวคิดที่ยังคงเดินเส้นทาง “A” (availability) ใน CAP theorem ไว้ แต่สามารถเปิดเผยสถานะภายในเพื่อให้ได้ “C” (consistency) ในเส้นทางปกติด้วย
  • หลังจากนั้น Amazon S3 ก็เปลี่ยนจากการเน้น availability ไปสู่ การเน้น consistency ขณะที่ DynamoDB เปิดให้เลือกอ่านแบบ Eventual หรือ Strongly Consistent ได้

ปัญหาความเข้ากันได้ของ Xen และการบูต FreeBSD ที่ล้มเหลว

• ต้นปี 2008 Kip Macy เขียนเคอร์เนล FreeBSD ที่รองรับ Xen PAE และต้องใช้เวลาหลายสัปดาห์ในการพอร์ตเครื่องมือ AMI ภายในมาเป็น FreeBSD
  • เขายังตั้งข้อสังเกตด้วยว่าโครงสร้างที่ Ruby script ไปสร้างและรัน bash script อีกที เป็นสิ่งที่ควรทบทวนการเลือกภาษา
• แต่ FreeBSD AMI ก็ยังบูตบน EC2 ไม่ได้ เพราะ Xen 3.0 ที่ EC2 ใช้อยู่มีบั๊กไม่รองรับ recursive page tables ที่โค้ด VM ของ FreeBSD ใช้
  • แม้ Xen 3.1 จะแก้แล้ว แต่เพราะไม่มี stable ABI และ Amazon ต้องรักษาความเข้ากันได้กับ AMI เดิม จึงเลือกใช้ Xen 3.0 ต่อ

การค้นพบและแก้ไขช่องโหว่ลายเซ็นของ AWS

• เดือนเมษายน 2008 ระหว่างใช้ Amazon SimpleDB สำหรับ Tarsnap รุ่นเบตา เขาพบ การชนกันจากการทำ normalization ในระบบลายเซ็น
  • ตอนนั้น Amazon ยังไม่มีช่องทางสำหรับรายงานปัญหาความปลอดภัย เขาจึงส่งเรื่องผ่าน Jeff Barr
• Amazon ขอให้เขาช่วยทบทวนการออกแบบ Signature Version 2 และหลังจากแก้ไขความกำกวมในเอกสาร ปรับการตัดสินใจด้านการออกแบบ และเพิ่ม allowlist ของบัญชีบางส่วน ก็แก้เสร็จในเดือนธันวาคม

ปัญหา security hygiene ของ NextToken ใน SimpleDB

• เดือนมิถุนายน 2008 เขาพบว่าค่า NextToken ของ SimpleDB เป็นเพียง Java serialized object ที่เข้ารหัสด้วย base64
  • เขารายงานว่าควรมีการเข้ารหัสเพื่อป้องกันข้อมูลภายในรั่วไหล และควรมีการเซ็นเพื่อป้องกันการแก้ไขข้อมูล แต่ไม่ได้รับการตอบกลับ
  • หกเดือนต่อมาเขารายงานอีกครั้งผ่านวิศวกรอีกคนจนมีการเปิด ticket ภายใน แต่หลังจากนั้นก็ยังไม่มีคำตอบอย่างเป็นทางการ

การทดสอบ EBS ระยะอัลฟาและจังหวะของ feedback ด้านการออกแบบ

• เดือนมีนาคม 2008 Matt Garman จากทีม EC2 เชิญเขาเข้าร่วม private alpha ของ Elastic Block Storage (ปัจจุบันคือ Elastic Block Store)
  • เขามองว่าช่วงเวลาที่ feedback มีประโยชน์ที่สุดสำหรับบริการใหม่คือ ขั้นออกแบบก่อนลงมือสร้าง และด้วยพื้นฐานทางคณิตศาสตร์กับทฤษฎี เขาเห็นว่าการรีวิวเอกสารออกแบบมีประสิทธิภาพกว่าการทดสอบอัลฟา

เกร็ดจากการสัมภาษณ์เข้าทำงานที่ Amazon

• ปี 2008 ตามคำชวนของ Jeff Barr เขาเคยพิจารณาเข้าทำงานกับ Amazon และในการสัมภาษณ์ทางโทรศัพท์กับ Al Vermeulen ใช้เวลา 30 นาทีจากทั้งหมด 45 นาทีไปกับการถกเรื่อง ข้อดีข้อเสียของ exceptions
  • เขายังคงยืนจุดยืนว่า exception handling เป็น แนวทางจัดการข้อผิดพลาดที่ไม่เหมาะสมโดยเนื้อแท้ เพราะทำให้เกิดบั๊กที่ตรวจพบได้ยากในการรีวิวโค้ดแบบทั่วไป

IAM และ access key แบบจำกัดสิทธิ์ — เส้นทางสู่ SigV4

• เดือนพฤศจิกายน 2008 ในงาน Seattle AWS Start-up Tour เขาได้พบวิศวกร Amazon โดยตรงและพูดคุยถึงความจำเป็นของ AWS access key แบบจำกัดสิทธิ์
  • เขาเสนอแนวทาง cryptographic derived keys ที่แฮชกุญแจแยกตามบริการจาก master secret ขณะที่ฝั่ง Amazon ชอบแนวทางออกแบบแบบอิงกฎ
• เดือนมกราคม 2010 เขาได้รับเชิญเข้าร่วม private beta ของ IAM และเมื่อ SigV4 เปิดตัวในปี 2012 แนวทาง derived key ก็ถูกนำมาใช้

ปัญหาไฟร์วอลล์ EC2 และ Path MTU Discovery

• ปี 2009 เขาพบและรายงานว่ากฎไฟร์วอลล์เริ่มต้นของ EC2 บล็อกข้อความ ICMP Destination Unreachable (Fragmentation Required) ทำให้ Path MTU Discovery ใช้งานไม่ได้
  • แม้ผู้จัดการ EC2 จะเห็นชอบกับแนวทางแก้ตั้งแต่เดือนธันวาคม 2009 แต่การแก้จริงเกิดขึ้นหลังจากเขา หยิบยกปัญหานี้ต่อสาธารณะในปี 2012

การอ้อมผ่าน NetBSD และการเปลี่ยนผ่านสู่ HVM

• ต้นปี 2010 เมื่อ EC2 ยังใช้ Xen เวอร์ชันเก่า เขาจึงลองเปลี่ยนไปใช้ NetBSD และภายในหนึ่งสัปดาห์ก็ทำได้ถึงขั้นบูต เมานต์ไฟล์ซิสเต็ม ตั้งค่าเครือข่าย และรัน sshd
• เดือนกรกฎาคม 2010 อินสแตนซ์ Cluster Compute เริ่มรองรับ HVM ทำให้เกิดความหวังกับ FreeBSD อีกครั้ง และชัดเจนว่า PV (paravirtualization) เป็น ทางตันทางเทคนิค

FreeBSD/EC2 รันได้ครั้งแรก — t1.micro

• อินสแตนซ์แฟมิลี t1.micro ที่เปิดตัวในเดือนกันยายน 2010 รัน Xen 3.4.2 ภายใน ทำให้บั๊กที่ขัดขวางการบูต FreeBSD หายไป
• กลางเดือนพฤศจิกายน 2010 เขา SSH เข้าอินสแตนซ์ FreeBSD/EC2 t1.micro ได้สำเร็จ และวันที่ 13 ธันวาคมก็มีการประกาศ การรองรับ FreeBSD EC2 t1.micro อย่างเป็นทางการ

การขยายชนิดอินสแตนซ์และเคล็ดลับ “Defenestration”

• มี Solutions Architect ของ Amazon ช่วยเชื่อมต่อเขากับผู้ใช้ FreeBSD ที่ต้องการอินสแตนซ์ขนาดใหญ่ขึ้น จนสามารถทำการรองรับ Cluster Compute instances ได้
• ด้วยการอาศัยข้อเท็จจริงที่ว่า EC2 ไม่ได้รู้จริงว่ากำลังรัน OS อะไร เขาจึงใช้วิธี defenestration (ปลอมเป็น Windows instance) เพื่อให้ FreeBSD ใช้งานได้บนอินสแตนซ์ 64 บิตทุกชนิด
  • ต้องยอมจ่าย “ภาษี Windows” และ Amazon เองก็ไม่พอใจ แต่มันจำเป็นต่อการตอบสนองความต้องการของลูกค้า จนกระทั่งเดือนกรกฎาคม 2014 เมื่อ T2 instances รองรับ HVM “Linux” ครบถ้วน เคล็ดลับนี้จึงไม่จำเป็นอีกต่อไป

การวินิจฉัยความเสียหายของฮาร์ดแวร์เราเตอร์ S3

• เดือนเมษายน 2012 เกิดคำขอล้มเหลวจำนวนมากที่ S3 endpoint บางแห่ง รวมถึงข้อผิดพลาด SignatureDoesNotMatch
• จากรูปแบบที่ค่า StringToSign ใน response ไม่ตรงกับค่าที่ส่ง เขาระบุได้ว่าเป็นอาการ stuck bit และใช้ traceroute กับการ ping หลายล้านครั้งเพื่อชี้ว่ามี ฮาร์ดแวร์เราเตอร์เสีย อยู่บนเส้นทางเครือข่าย
  • หลังรายงานใน AWS Developer Forums ทาง Amazon ก็ยืนยันปัญหาและเปลี่ยนอุปกรณ์ภายในไม่กี่วัน

re:Invent 2012 และการเตือนเรื่อง side-channel attack

• re:Invent ครั้งแรกมีเนื้อหาทางเทคนิคน้อยและมีผู้ใส่สูทจำนวนมาก แต่ก็เปิดโอกาสให้เขาได้พบปะวิศวกร Amazon จำนวนมากแบบตัวต่อตัว
• หลังจาก VP ผู้บรรยายของ Intel ในหัวข้อ “virtual machine security” ตอบว่าไม่รู้เรื่อง side-channel attack เขาก็ไปอธิบายงานวิจัยที่เกี่ยวข้องให้ Principal Engineer ที่บูธ EC2 ฟังโดยตรง

การทำให้ FreeBSD/EC2 เป็นทางการและงาน release engineering

• เดือนเมษายน 2015 กระบวนการ build AMI ของ FreeBSD/EC2 ถูกรวมเข้าใน src tree ของ FreeBSD และย้ายการสร้างอิมเมจไปยังทีม FreeBSD release engineering ทำให้โครงการนี้เปลี่ยนจากงานส่วนตัวไปเป็นส่วนหนึ่งของ โครงการ FreeBSD อย่างเป็นทางการ
• เดือนกันยายน 2020 ตามคำขอของ Glen Barber ซึ่งเป็น FreeBSD Release Engineering Lead เขารับบทบาท Deputy Release Engineer
  • ปลายปี 2022 Glen ต้องเข้าโรงพยาบาลด้วยอาการปอดอักเสบ และผลกระทบระยะยาวทำให้กลับมาทำงานได้ยาก เขาจึงเข้ารับหน้าที่ FreeBSD Release Engineering Lead เองในวันที่ 17 พฤศจิกายน 2023
  • เขาดูแลการ build snapshot รายสัปดาห์ เพิ่มความเข้มงวดของตารางงาน วางรอบรีลีสที่รวดเร็วและคาดการณ์ได้ และบริหารการออกรุ่นปีละ 4 ครั้ง

คำเตือนด้านความปลอดภัยของ IMDS และเหตุเจาะระบบ Capital One

• เดือนตุลาคม 2016 เขาวิเคราะห์ IAM Roles for Amazon EC2 และเขียนบล็อกเตือนว่าการเปิดเผย credential ผ่าน IMDS ซึ่งทำงานผ่าน HTTP ที่ไม่มีการยืนยันตัวตนและมีคำเตือนในเอกสารว่า “ห้ามเก็บข้อมูลอ่อนไหว” นั้นเป็นความเสี่ยง
• เดือนกรกฎาคม 2019 Capital One ถูกโจมตีด้วยช่องทางนี้พอดี ทำให้ข้อมูลลูกค้า 106 ล้านรายรั่วไหล และหลังจากเขาคุยกับ Amazon ในเดือนพฤศจิกายนปีเดียวกัน อีกสองสัปดาห์ต่อมาก็มีการเปิดตัว IMDSv2
  • เขายังมองว่า IMDSv2 เป็นเพียงการบรรเทา attack path บางแบบ ไม่ใช่การแก้ปัญหารากฐานของการเปิดเผย credential ผ่านอินเทอร์เฟซที่ไม่เหมาะสม

โปรแกรม AWS Heroes

• เดือนพฤษภาคม 2019 เขาได้รับเชิญเข้าร่วม AWS Heroes ซึ่งเป็นโปรแกรมยกย่องบุคคลนอก Amazon ที่สร้างคุณูปการสำคัญต่อ AWS
  • การได้รับเลือกครั้งนี้ถือว่าค่อนข้างผิดปกติ เพราะโปรแกรมมักเน้นผู้มีส่วนร่วมด้านการให้ความรู้แก่นักพัฒนา เช่น บล็อก, YouTube และเวิร์กช็อป และการอนุมัติเกิดจากคำแนะนำของ Distinguished Engineer กับ Senior Principal Engineer

การบูตแบบ UEFI และ BootMode=uefi-preferred

• เดือนมีนาคม 2021 EC2 เพิ่มการรองรับ การบูตแบบ UEFI บนอินสแตนซ์ x86 และเมื่อ FreeBSD เปลี่ยนมาใช้ UEFI ก็ไม่ต้องทำ I/O ในโหมด 16 บิตอีก จึง ลดเวลาบูตลง 7 วินาที
  • เนื่องจากไม่ใช่อินสแตนซ์ทุกชนิดที่รองรับ UEFI เขาจึงขอการตั้งค่า BootMode=polyglot สำหรับอิมเมจที่บูตได้ทั้ง legacy BIOS และ UEFI
  • ต่อมาในเดือนมีนาคม 2023 ฟีเจอร์นี้ถูกนำไปใช้งานในชื่อ BootMode=uefi-preferred

การค้นพบปัญหาความปลอดภัยของ Seekable OCI และความล่าช้าในการแก้ไข

• เดือนสิงหาคม 2023 ในงาน Heroes Summit เขาเห็นการออกแบบ Seekable OCI และพบว่าคำกล่าวอ้างด้านความปลอดภัยใช้ไม่ได้ในบางกรณี จึงรายงานต่อทีม AWS Security
• แม้จะได้รับคำมั่นว่าจะมีการแก้ไขภายใน แต่กลับไม่มีความคืบหน้าจริง และหลังทวงถามอีกครั้งในงาน re:Invent 2024 รวมถึงรายงานซ้ำในเดือนมกราคม 2025 ก็ยืนยันได้ว่า commit ในปี 2023 ป้องกันได้เพียงความเสียหายของข้อมูลโดยไม่ตั้งใจ แต่ไม่สามารถหยุดการโจมตีโดยเจตนาได้
  • หลังมีการชี้ประเด็นอีกครั้ง ทีมงานตอบสนองอย่างรวดเร็ว และภายในปลายเดือนกุมภาพันธ์ 2025 ฟีเจอร์ดังกล่าวก็ถูก ปิดใช้งานสำหรับลูกค้าส่วนใหญ่ ระหว่างรอ “major revision”

การสนับสนุนจาก Amazon และรูปแบบความร่วมมือ

• เดือนเมษายน 2024 เขาแจ้ง Amazon ว่าไม่สามารถทุ่มเวลาให้การดูแล FreeBSD/EC2 ได้มากพอ และขอการสนับสนุนทางการเงิน ซึ่งภายในไม่กี่สัปดาห์ก็ได้รับการยืนยัน การสนับสนุนผ่าน GitHub Sponsors สัปดาห์ละ 10 ชั่วโมง เป็นเวลา 1 ปี
  • หลังจัดการปัญหาค้างจำนวนมากแล้ว เขาหยุดไป 6 เดือน (ส่วนใหญ่เป็นงานไร้ค่าตอบแทนเพื่อทุ่มให้กับ release engineering ของ FreeBSD 15.0) ก่อนเริ่ม การสนับสนุนรอบที่สองอีก 12 เดือน
• เขาเน้นว่าผลงานตลอด 20 ปีนี้ไม่ใช่ความสำเร็จของเขาคนเดียว และแม้ไม่มีสิทธิ์เข้าถึงระบบภายใน AWS แต่วิศวกร Amazon ก็ช่วยทำหน้าที่เป็น “remote hands” เช่น เปิด ticket ค้นหาผู้ติดต่อภายใน ตรวจสอบ API log และหาเอกสารทางเทคนิคให้

[GN⁺]

ความคิดเห็นจาก Hacker News

• ผู้เขียนพูดติดตลกว่า ‘Heroes จริง ๆ แล้วคือ พนักงาน Amazon ที่ไม่ได้รับค่าจ้าง’ แต่ที่จริงมันไม่ใช่มุกตลก มันคือความจริง
  ฉันไม่เผยแพร่งานวิจัยส่วนตัวของตัวเอง เพราะไม่อยากมอบ R&D ฟรีให้กับ เครื่องจักรสกัดมูลค่า ที่มีประสิทธิภาพมากพออยู่แล้ว
  Amazon ทำลายสมมติฐานทางเศรษฐกิจของโอเพนซอร์ส และผลก็คือหลายโปรเจกต์กำลังเปลี่ยนไปใช้ Business Source License
  นักพัฒนาเหล่านี้รู้ดีว่า Amazon โลภแค่ไหน สุดท้ายการมีส่วนร่วมของชุมชนก็กลายเป็นแรงงานฟรีให้บริษัทยักษ์ใหญ่ และ Amazon ก็ใช้บริการแบบ managed service ดูดผู้ใช้ไป ทำให้การสนับสนุนและชุมชนของโปรเจกต์ต้นทางอ่อนแอลง

  • ถ้าคุณไม่ชอบที่ Amazon ใช้โค้ดของคุณ ก็แค่ ระบุยกเว้น Amazon ในไลเซนส์อย่างชัดเจน
    เขียนว่า “ใครก็ใช้ได้อย่างอิสระ ยกเว้น Amazon” แล้ว Amazon จะไม่ใช้เพราะมีความเสี่ยงทางกฎหมาย
    แต่ถ้ามองว่าจำเป็น Amazon ก็อาจสร้างเวอร์ชันของตัวเองขึ้นมาใหม่ได้
  • บริษัท SaaS รายใหญ่ยังสามารถทำ implementation ของ API interface เดิมได้ แม้จะมี Business Source License ก็ตาม
    อย่างกรณี Redis สถานะการคุ้มครองทางกฎหมายของพื้นผิว API ยังไม่ชัดเจน
    จำได้ว่าคดี Google v. Oracle เคยพยายามวางหลักคุ้มครองแบบนั้นแต่สุดท้ายก็ยังไม่เกิดขึ้น
  • คุณยังใช้ไลเซนส์อย่าง AGPL หรือ GPL3 ได้ด้วย ไลเซนส์พวกนี้แทบจะถูก hyperscaler แบนกันหมด
    จริง ๆ แล้วบริษัทที่เลือก BSL อาจไม่ได้สนใจจิตวิญญาณโอเพนซอร์สอย่างแท้จริง แต่แค่เปิดซอร์สเพื่อ บริหารภาพลักษณ์ หรือสร้างความชอบจากนักพัฒนาเท่านั้น
  • “โชคดี” ที่ฉันไม่ได้ฉลาดหรือสำคัญพอจะต้องคิดเรื่องพวกนี้ลึกขนาดนั้น
    แต่ก็เห็นด้วยทั้งหมด ตอนนี้โค้ดที่ฉันจะปล่อยมีแค่สองแบบ คือโอเพนซอร์สจริง ๆ หรือไม่ก็ปิดเป็นความลับทั้งหมด
    ถ้ามีโอกาสที่ใครสักคนจะ เอาไปทำเงินได้ ฉันก็จะไม่ปล่อย

• ฉันเข้าใจมุมมองที่ไม่อยากทุ่มเวลาให้บริษัทใหญ่ แต่ขอเสนออีกมุมหนึ่ง
  ในปี 2006 ฉันทำโปรเจกต์หนึ่งไว้ และปี 2012 มีนักพัฒนาคนอื่นอยากใช้ชื่อนั้น ฉันก็ยกให้ด้วยความยินดี
  โปรเจกต์นั้นก็คือ scrypt และนักพัฒนาคือ Colin
  ความมีน้ำใจในชุมชน แบบนี้จะสะสมเป็น กรรมดี ได้ แม้จะไม่มีความคาดหวังทางการค้าก็ตาม

• ประโยคที่ว่า “งานมีตอัปผู้ใช้ AWS ของ Jeff Barr จัดใน Second Life” น่าสนใจมาก
  Second Life เป็นผู้ใช้ AWS ยุคแรก ๆ และ Jeff Bezos ก็เข้าร่วมรอบการลงทุนปี 2005 ด้วยตัวเอง
  นั่นทำให้ Jeff Barr ไปจัดมีตอัป AWS ภายใน Second Life และตอนนั้นก็เป็นช่วงที่กลุ่มอย่าง Reuters หรือ Jonathan Coulton กำลังบุกเข้าสู่พื้นที่เสมือนเช่นกัน

  • ฉันยังจำตอนเห็น Second Life ครั้งแรกในงานคอนเฟอเรนซ์ราว ๆ ปี 2002~2003 ได้
    ตอนนั้นเราออกบูท Evolution Robotics เพื่อสาธิตหุ่นยนต์ ER1 และ Second Life ก็น่าประทับใจมาก
    เป็นความทรงจำที่ดี
  • ตอนที่ re:Invent 2020 จัดในพื้นที่เสมือน ฉันรู้สึกถึง เดจาวูจากยุค Second Life อย่างแรง
    แน่นอนว่า Second Life บนหน้าจอแล็ปท็อปกับ VR headset เป็นประสบการณ์ที่ต่างกันโดยสิ้นเชิง

• กรอบคิดเรื่อง “แรงงานฟรีให้ Amazon” กำลังพลาดประเด็นสำคัญ
  Colin ไม่ได้ทำการกุศล แต่เขาปรับปรุงสิ่งนั้นเพราะ Tarsnap พึ่งพา FreeBSD/EC2
  นี่คือรูปแบบที่ดีต่อสุขภาพที่สุดของโอเพนซอร์ส — แก้ฐานรากของผลิตภัณฑ์ตัวเอง และผลลัพธ์ก็เป็นประโยชน์กับทุกคน
  การรอให้ Amazon สนใจเองก่อน ก็แทบไม่ต่างจาก รอไปตลอดกาล

• ฉันแปลกใจที่เห็นว่า Amazon สนับสนุนผ่าน GitHub Sponsors เป็นเวลา สัปดาห์ละ 10 ชั่วโมง นาน 1 ปี
  คิดเป็น $300 ต่อชั่วโมง ซึ่งอยู่ระดับเงินเดือนของวิศวกร Google L6 เลย
  ตอนนี้หวังว่าเขาจะได้มากกว่านั้น

  • อัตราค่าจ้างรายชั่วโมง ในวงการไอทีสหรัฐฯ สูงผิดปกติจริง ๆ
    ในยุโรปที่ใช้ภาษาเยอรมัน 120 ยูโรก็จ้างวิศวกรเก่ง ๆ ได้แล้ว ยุโรปตะวันออกยิ่งถูกกว่านั้นอีก

• ฉันไม่เห็นด้วยกับคำวิจารณ์ของผู้เขียนเรื่อง IAM Roles for EC2
  IAM เป็นฟีเจอร์หลักที่ทำให้จัดการ credential แบบ อิงนโยบาย ได้
  มันปลอดภัยกว่า Outlook, Slack, Teams มาก และยังพิสูจน์ในเชิงคณิตศาสตร์ได้ด้วยว่าสมาชิกทีม ไม่มีทางเห็น signing key
  Azure ก็ใช้แนวคิดคล้ายกันเพื่อจัดการการเข้าถึง MSSQL ได้อย่างเรียบร้อย

  • ฉันไม่ได้คัดค้าน IAM Roles เอง แค่คิดว่า อินเทอร์เฟซที่ใช้ส่งมอบ credential ของ role นั้นเป็นตัวเลือกที่แย่ที่สุด
    เมื่อก่อนฉันเคยเสนอให้ส่ง credential ไปยังเคอร์เนลผ่าน XenStore ทุกวันนี้ถ้าเป็นระบบที่ใช้ Nitro ก็น่าจะทำได้ง่ายกว่าเดิม
    ให้เคอร์เนลรับ credential แล้ว expose ออกมาเป็น virtual filesystem ที่ตั้ง ownership และ permission ได้ ก็พอ
  • Scaleway อนุญาตให้ดึง token ได้เฉพาะจากพอร์ตต่ำกว่า 1024
    ความน่ารักคือมีแค่โปรเซสที่มีสิทธิ์ CAP_NET_BIND_SERVICE เท่านั้นที่เข้าถึงได้
    ถ้าใช้ socket แบบ vsock(7) ก็จะเป็น วิธีเชื่อมต่อที่หลอกได้ยาก และปลอดภัยกว่า
    ยิ่งไปกว่านั้น ถ้าใส่ bootstrap credential ไว้ในข้อมูล DMI มันก็จะไปอยู่ในไดเรกทอรี sysfs ที่ root อ่านได้เท่านั้น

• ฉันไปเปิดดูอีเมลปี 2007 แล้วพบว่า ตอนแรกการเข้าถึงบริการ AWS ต้อง ยื่นขอเป็นรายบริการ จริง ๆ
  ตอนแรกฉันได้รับอนุมัติแค่ “Amazon E-Commerce Service” จากนั้นถึงค่อยได้สิทธิ์ S3 และ EC2 beta ตามลำดับ
  ตอนนั้น “Alexa Web Information Service” ไม่ใช่ผู้ช่วยเสียง แต่เป็น เว็บเสิร์ช API เป็นยุคที่น่าสนใจจริง ๆ

• นี่คือ บันทึกประวัติศาสตร์เทคโนโลยี ที่น่าสนใจมาก
  น่าประทับใจที่แม้แต่วิศวกรชื่อดังอย่าง Tavis Ormandy ก็ยังพลาดได้เวลาให้สัมภาษณ์
  ฉันชอบ บล็อกโพสต์เล่าประสบการณ์ แบบนี้มาก

• การที่ไม่มีการพูดถึง Hetzner หรือ OVH เลยในบททบทวน 20 ปีนี้ชวนให้คิด
  ฉันใช้ทั้ง AWS, Hetzner และคลาวด์รายเล็กควบคู่กัน และส่วนต่างด้านราคาก็มหาศาล
  AWS เดือนละ $350 ขณะที่ Hetzner อยู่ที่ 20~25 ยูโร พร้อมสเปกใกล้เคียงกันและทราฟฟิก 20TB รวมอยู่แล้ว
  สิ่งที่ AWS ขายตอนนี้ไม่ใช่ compute อีกต่อไป แต่คือโมเดล IAM, โครงสร้างพื้นฐานระดับโลก และฉันทามติภายในองค์กร
  ความเชื่อที่ว่า “ถ้าเลือก AWS จะไม่มีใครโดนไล่ออก” ต่างหากคือสินค้าจริง
  ฉันอยากถามคนที่เพิ่งย้าย workload ออกจาก AWS เมื่อเร็ว ๆ นี้ — มีส่วนไหนบ้างที่ เจ็บปวดกว่าที่คาดไว้