ผมกำลังสร้างคลาวด์อยู่
(crawshaw.io)- นามธรรมของคลาวด์แบบเดิม ทำให้การนำ CPU, หน่วยความจำ, และดิสก์มาประกอบใช้ในแบบที่ต้องการทำได้ยาก และทั้ง VM กับ PaaS ก็สร้างข้อจำกัดมากกว่าคอมพิวเตอร์ทั่วไป
- remote block storage และ ค่า egress ที่สูง ทำให้โครงสร้างที่ยังยึดติดกับสมมติฐานยุค HDD ยังคงอยู่ และยิ่งขยายปัญหาทั้งด้านประสิทธิภาพและต้นทุนในสภาพแวดล้อม SSD และเครือข่ายสมัยใหม่
- Kubernetes ช่วยครอบทับ API คลาวด์ที่ใช้งานยาก แต่ไม่สามารถเปลี่ยนนามธรรมตั้งต้นที่ผิดได้ จึงยังต้องแบกข้อจำกัดของ VM, ดิสก์, และเครือข่ายเหมือนเดิม
- เมื่อ agents ทำให้ซอฟต์แวร์และความต้องการในการรันเพิ่มขึ้น พื้นที่ประมวลผลแบบส่วนตัว การแชร์ที่ง่าย และโอเวอร์เฮดในการดูแลที่ต่ำก็ยิ่งสำคัญขึ้น พร้อมกับคอขวดเชิงโครงสร้างของคลาวด์เดิมที่ยิ่งขยายตาม
- exe.dev พยายามทำให้ใกล้เคียงกับคลาวด์ที่อยากใช้งานจริงมากขึ้น โดยให้จอง CPU และหน่วยความจำก่อนแล้วค่อยรัน VM เองบนทรัพยากรนั้น พร้อมผสาน TLS proxy, auth proxy, local NVMe, asynchronous replication และการจัดวางแบบ anycast
ทำไมต้องสร้างคลาวด์ใหม่อีกครั้ง
- นามธรรมของคลาวด์แบบเดิม ทำให้การใช้คอมพิวเตอร์ในแบบที่ต้องการเป็นเรื่องยาก และนี่คือเหตุผลตรง ๆ ที่ทำให้เริ่มบริษัทใหม่
- ตัวคอมพิวเตอร์เองนั้นดีอยู่แล้ว แต่คลาวด์ในปัจจุบันแทบทุกผลิตภัณฑ์ต่างก็ทำซ้ำข้อจำกัดเดิม ๆ และแก่นของปัญหาก็ใกล้กับเรื่องของ รูปแบบของหน่วยประกอบพื้นฐาน มากกว่าจะเป็นแค่ UX หรือการออกแบบ API ที่พลาด
- VM ถูกให้มาในรูปอินสแตนซ์แยกที่ผูกกับ CPU และหน่วยความจำ แต่สิ่งที่ต้องการจริง ๆ คือโครงสร้างที่จองทรัพยากร CPU, หน่วยความจำ, และดิสก์ก่อน แล้วค่อยวาง VM ลงไปบนทรัพยากรนั้นได้ตามจำนวนที่ต้องการ
- Linux VM ก็คือโปรเซสที่รันอยู่ใน cgroup ของ Linux อีกชั้นหนึ่ง แต่ในคลาวด์ปัจจุบันกลับจัดการสิ่งนี้ได้ไม่ง่าย
- หากจะเลี่ยงข้อจำกัดนี้ ก็ต้องวาง gVisor หรือ nested virtualization บนคลาวด์ VM เดี่ยวอีกที และต้องแลกกับ การสูญเสียประสิทธิภาพ พร้อมรับภาระดูแลอย่างน้อยก็ reverse proxy เอง
- PaaS ก็แก้ปัญหานี้ไม่ได้ และยิ่งบังคับให้ยอมรับ นามธรรมแบบผูกติดกับผู้ให้บริการ ที่มีความสามารถน้อยกว่าคอมพิวเตอร์ทั่วไป
- ต้องเรียนรู้วิธีพัฒนาแบบใหม่สำหรับผู้ให้บริการคอมพิวต์แต่ละราย
- บางครั้งพอทำโปรเจกต์ไปได้ระดับหนึ่งแล้วจึงค่อยพบว่า งานที่ทำได้ง่ายบนคอมพิวเตอร์ทั่วไปกลับแทบเป็นไปไม่ได้เลยเพราะข้อจำกัดลึก ๆ ของแพลตฟอร์ม
- หลายครั้งเหมือนจะ “คราวนี้ได้แล้ว” แต่สุดท้ายก็ไปติดกับนามธรรมที่ถูกทำมาแค่ครึ่ง ๆ กลาง ๆ
ข้อจำกัดเชิงโครงสร้างที่เห็นชัดในดิสก์และเครือข่าย
- ในด้านดิสก์ ผู้ให้บริการคลาวด์มักชอบ remote block storage หรือวิธีที่จำกัดและช้ากว่านั้นอย่าง S3 ซึ่งในยุค HDD ก็ถือว่าสมเหตุสมผลอยู่บ้าง
- สตอเรจระยะไกลแทบไม่เสียเปรียบมากนักกับการอ่านเขียนแบบลำดับ และการ seek แบบสุ่มของ HDD อยู่ราว 10ms ทำให้ RTT 1ms ของการเชื่อมต่อ Ethernet ยังเป็นต้นทุนที่พอยอมรับได้
- สำหรับผู้ให้บริการ การตัดหนึ่งแกนออกจากประเภทอินสแตนซ์มาตรฐานก็ทำให้การปฏิบัติการง่ายขึ้น
- แต่เมื่อเปลี่ยนมาเป็น SSD สมมติฐานนี้ก็พังลง
- เวลา seek ลดจาก 10ms เหลือ 20 ไมโครวินาที
- แม้ RTT ของระบบบล็อกระยะไกลจะดีขึ้น แต่โอเวอร์เฮดด้าน IOPS ที่เคยอยู่ราว 10% ในยุค HDD กลับเพิ่มเป็น มากกว่า 10 เท่า ในยุค SSD
- ถ้าจะจัดคอนฟิก 200k IOPS บน EC2 ต้องตั้งค่าซับซ้อนและจ่าย 10,000 ดอลลาร์ต่อเดือน ขณะที่ MacBook ให้ 500k IOPS มาเลย
- เทคโนโลยีเครือข่ายเองนั้นดีพออยู่แล้ว แต่ ค่า egress และโครงสร้างธุรกิจกลับทำงานไปในทิศทางที่ขัดขวางการใช้งาน
- เครือข่ายของ hyperscaler นั้นยอดเยี่ยม แต่ราคาแพงมากและยังทำให้การเชื่อมต่อกับผู้ขายรายอื่นไม่สะดวก
- ค่า egress ของผู้ให้บริการคลาวด์ถูกตั้งไว้สูงกว่าการเอาเซิร์ฟเวอร์ไปแร็กในดาต้าเซ็นเตอร์ทั่วไปประมาณ 10 เท่าต่อ GB
- เมื่อปริมาณใช้งานเพิ่มขึ้นเพียงระดับหนึ่ง ตัวคูณนี้ก็ยิ่งแย่ลงอีก
- ลูกค้าที่จ่ายหลายสิบล้านดอลลาร์ต่อเดือนอาจได้ราคาที่ดีกว่า แต่ก็ไม่เหมาะกับโปรเจกต์ขนาดหลายสิบหรือหลายร้อยดอลลาร์ต่อเดือน
- ในช่วงขนาดนี้ ไม่ว่าจะสร้างอะไรขึ้นมาก็มักถูกขัดขวางให้ ดำเนินงานในต้นทุนต่ำได้ยาก
Kubernetes และ API ช่วยกลบปัญหา แต่ไม่ได้แก้มัน
- API ของคลาวด์ใช้งานอย่างทรมาน และ Kubernetes ก็เกิดขึ้นมาเพื่อครอบทับสิ่งนั้นเพื่อลดความเจ็บปวดของวิศวกร
- แต่ VM ก็ยังจัดการยากอยู่ดีแม้อยู่บน Kubernetes เพราะคลาวด์ผลักภาระ nested virtualization มาให้โดยตรง
- ด้านดิสก์เอง ตอนที่ Kubernetes ถูกออกแบบนั้นฝั่ง Google ก็แทบไม่มี remote block device ที่ใช้งานได้จริง และต่อให้วันนี้จะฝืนให้เข้ากับแพตเทิร์นร่วมได้ สุดท้ายก็มักลงเอยด้วยการถูกผูกกับสตอเรจที่ช้า
- ด้านเครือข่ายก็เช่นกัน หากเปิดให้ง่ายเกินไป ก็จะสามารถเชื่อมบางระบบในดาต้าเซ็นเตอร์เปิดที่อยู่ใกล้กันเข้ามาด้วย private link เพื่อ ลบเลข 0 ออกจากต้นทุนคลาวด์ได้หนึ่งหลัก ดังนั้นจึงแทบไม่มีแรงจูงใจให้ทำให้ง่าย
- แทนที่จะมอง Kubernetes ว่าเป็นเพียงงานลวงโลกที่สร้างขึ้นมาเอง ควรมองว่าเป็นผลผลิตจากการต่อสู้กับปัญหาที่แทบเป็นไปไม่ได้ นั่นคือการสร้าง คลาวด์ที่พกพาได้และ usable
- โดยพื้นฐานแล้ว ปัญหานี้แก้ไม่ได้ด้วยการเอานามธรรมใหม่ไปวางบนยอดของนามธรรมคลาวด์ที่ผิดตั้งแต่ต้น และการพยายามทำให้ Kubernetes ดีขึ้นก็มาถึงขีดจำกัดที่ชัดเจน
- เวลาที่อยู่กับคลาวด์อันชวนอึดอัดแบบนี้ก็ยาวนานถึง 15 ปี แล้ว และตลอดเวลานั้นก็อยู่กับมันแบบเดียวกับส่วนอื่น ๆ ของซอฟต์แวร์สแตกที่ไม่น่าพอใจ คืออดทนและพยายามแตะต้องมันให้น้อยที่สุด
ตอนนี้คือเวลาที่ต้องแก้
- เหตุผลที่ตอนนี้เป็นจุดเปลี่ยน ก็คือการมาถึงของ agents
- เช่นเดียวกับ Jevons paradox ยิ่งการเขียนโค้ดง่ายขึ้น ปริมาณซอฟต์แวร์โดยรวมก็ยิ่งเพิ่มขึ้น และแต่ละคนก็จะใช้โปรแกรมมากขึ้นทั้งในงานและงานอดิเรก
- หากจะรันโปรแกรมที่เพิ่มขึ้นเหล่านั้น ก็ต้องการ พื้นที่ประมวลผลแบบส่วนตัว การแชร์ที่ง่าย และโอเวอร์เฮดในการดูแลที่ต่ำ
- ยิ่งปริมาณซอฟต์แวร์รวมเพิ่มขึ้น ปัญหาคลาวด์ที่เมื่อก่อนแค่น่ารำคาญ ก็ยิ่งขยายกลายเป็นคอขวดที่ใหญ่กว่าเดิมมาก
- ต้องใช้คอมพิวต์มากขึ้น และต้องจัดการได้ง่ายขึ้นด้วย
- agents ช่วยแทนการกดใช้ AWS API ได้ก็จริง แต่ก็ต้องมอบหมาย credential ให้ และบางครั้งอาจลบ production DB ได้ด้วย
- ที่สำคัญ agents เองก็ยังชนกำแพงเดียวกับมนุษย์เมื่อเจอกับข้อจำกัดพื้นฐานของนามธรรมคลาวด์เดิม
- มันทำให้ต้องใช้โทเคนมากเกินความจำเป็น และผลลัพธ์ก็แย่กว่าที่คาด
- ยิ่ง context window ของ agent ถูกใช้ไปกับการฝืนให้เข้ากับคลาวด์แบบดั้งเดิมมากเท่าไร พื้นที่สำหรับแก้ปัญหาจริงก็ยิ่งเหลือน้อยลงเท่านั้น
สิ่งที่ exe.dev เริ่มลงมือแก้ก่อน
- สิ่งแรกที่ exe.dev เปิดตัว คือคำตอบต่อ ปัญหาการแยกทรัพยากรของ VM
- แทนที่จะ provision VM แต่ละตัวแยกกัน ระบบจะให้ CPU และหน่วยความจำมาก่อน แล้วให้รัน VM ที่ต้องการเองบนทรัพยากรนั้น
- ภายใต้สมมติฐานว่าไม่อยากเปิด VM ใหม่ออกสู่อินเทอร์เน็ตโดยตรง จึงจัดการทั้ง TLS proxy และ auth proxy ให้พร้อมกัน
- ดิสก์ใช้ NVMe ภายในเครื่อง และทำ asynchronous replication ของบล็อกออกนอกเครื่อง
- ทำให้สามารถวางเครื่องไว้ในหลายภูมิภาคทั่วโลก เพื่อให้รันได้จากตำแหน่งที่อยู่ใกล้ผู้ใช้
- เครื่องเหล่านี้ถูกวางไว้หลังเครือข่าย anycast เพื่อให้ผู้ใช้ทั่วโลกมีจุดเข้าใช้งานที่มี latency ต่ำ
- และยังออกแบบมาเพื่อให้ต่อยอดฟีเจอร์ใหม่ ๆ ได้อีกในเร็ว ๆ นี้บนฐานเดียวกันนี้
- ยังมีอีกหลายอย่างที่ต้องสร้าง
- ยังมีรายการที่ค่อนข้างชัดเจนอย่าง static IP ที่ยังขาดอยู่
- และยังมีโจทย์อย่าง UX สำหรับเข้าถึง snapshot ดิสก์ย้อนหลังที่ระบบสร้างให้อัตโนมัติ
- ขณะเดียวกันก็กลับไปสู่ขั้นตอนของการนำคอมพิวเตอร์ไปแร็กในดาต้าเซ็นเตอร์โดยตรงอีกครั้ง และกำลังทบทวน ทุกชั้นของซอฟต์แวร์สแตก ใหม่ รวมถึงวิธีเชื่อมต่อเครือข่ายด้วย
- เป้าหมายสุดท้ายคือการสร้างคลาวด์ที่อยากใช้งานจริง
6 ความคิดเห็น
ตอนแรกก็แอบคิดว่า ทำไมเพิ่งมาทำตอนนี้นะ..
พอเห็นว่าผู้เขียนเป็นผู้ร่วมก่อตั้ง Tailscale ก็รู้สึกว่าอยากเอาใจช่วยขึ้นมาเฉยเลย
ช่วยทำออกมาให้ดีนะครับ!
ตารางราคาทำให้งงมาก เพราะเขียนประมาณว่า 2 คอร์ 8GB, VM 50 ตัว อะไรแบบนี้ ผมเลยคิดว่าน่าจะต้องเข้าใจว่าให้ VM มา 1 ตัว แล้วสามารถรันคอนเทนเนอร์ได้ 50 ตัว
คลาวด์ซับซ้อนก็มีเหตุผลของมัน
ไม่เห็นฟีเจอร์ยกเลิกสมาชิกเลย มีใครหาเจอบ้างไหม?
ถ้าสามารถเชื่อมต่อบริการต่าง ๆ เข้าด้วยกันได้ด้วยการลากแล้ววางเพียงอย่างเดียวก็คงดีนะ
ความคิดเห็นจาก Hacker News
ตอนแรก Kubernetes อาจดูเหมาะกับการรันคอนเทนเนอร์เว็บแอปไม่กี่ตัว แต่ไม่นานก็จะมี SDN และบริการสารพัดอย่างเข้ามาพอกพูนจนขยายใหญ่เกินควบคุม
ยิ่ง "ปรับให้เหมาะสม" และ "ทำให้แข็งแรง" กับคลัสเตอร์มากเท่าไร ค่าใช้จ่ายคลาวด์ ปัญหาขัดข้อง เวลาหยุดทำงาน และแรงที่ใช้ดีบักก็พุ่งขึ้น 2~3 เท่าทั้งหมด
สุดท้ายพอเลิกยึดติดกับแนวคิด DevOps แบบนั้นแล้วลบคลัสเตอร์ทิ้ง จากนั้นเปิดไฟร์วอลล์บน Debian VM เดี่ยว แล้ว deploy Docker ด้วย Kamal ก็พบว่าเสถียรภาพและความน่าเชื่อถือของอินฟราดีที่สุด แถมค่าใช้จ่ายลดลงมาก
แอปธุรกิจส่วนใหญ่มีผู้ใช้ระดับหลักร้อยถึงหลักพัน ดังนั้น VM ใหญ่เครื่องเดียวก็มักพอแล้ว และเพราะคลาวด์อย่าง Google จัดการความเสียหายของฮาร์ดแวร์ให้ได้ ถ้าจำเป็นค่อยเปิด VM ตัวที่สองแล้วสลับ IP ที่ Cloudflare ก็พอ
เป็นเรื่องปกติที่คนจะยัด k8s เข้าไปทั้งที่ระบบเล็กเกินไป และถ้าเป็นแบบนั้นก็ดูเหมือนไม่ได้อยู่ในสเกลที่ต้องใช้ k8s ตั้งแต่แรก
เพราะงั้นจึงต้องมีเลเยอร์ด้านบนที่ช่วยทำให้แพตเทิร์นการ deploy ทั่วไปง่ายขึ้น และ Knative ก็เป็นตัวอย่างหนึ่ง
วิธีแก้ที่พยายามเปิดเผย primitive พื้นฐานทั้งหมด สุดท้ายก็หนีไม่พ้นที่จะซับซ้อนพอ ๆ กับ Kubernetes
https://github.com/openrundev/openrun ที่ฉันทำขึ้นมาจัดการ deployment ของเว็บแอปภายในทีมแบบ declarative และมี SAML/OAuth กับ RBAC ให้ด้วย พร้อมรองรับทั้ง Docker เครื่องเดียวและ Kubernetes
วิธีคิดที่ซับซ้อนเกินจำเป็น ดีบักยาก และเปลืองเงิน สามารถถูกทำซ้ำบน VM ได้เหมือนกัน
เพียงแต่ตอนนี้ Debian VM เดี่ยวอาจยังอยู่นอกเรดาร์ด้านนโยบายของพวกเขาเลยยังมีอิสระ
พอมีใครเริ่มเข้ามายุ่ง ก็มีโอกาสสูงที่จะพยายามยัด HA, rollout/rollback, VM 3~5 เครื่อง, นโยบาย virtual network, security scanner 4 ตัว, log processor 2 ตัว, watchdog, network monitor, mTLS และอุปกรณ์ตรวจสอบทราฟฟิกเข้ามาต่อกันเป็นพรวน
ถ้ามีอีกเครื่อง เวลามีปัญหาระหว่างอัปเกรดหรือแก้ไขระบบก็อุ่นใจกว่า
https://github.com/psviderski/uncloud ที่ฉันกำลังทำซึ่งได้แรงบันดาลใจจาก Kamal ทำให้การตั้งค่าแบบหลายเครื่องง่ายพอ ๆ กับ VM เดี่ยว และ deploy ไปหลาย VM ด้วย zero-config WireGuard overlay กับ Docker Compose มาตรฐาน
เริ่มจากเครื่องเดียวได้โดยไม่มีความซับซ้อนของ orchestrator หรือ control plane และเมื่อจำเป็นก็ค่อยขยายโดยผสมทั้ง cloud VM และ on-prem ได้
ตอนใช้ใน production มันดีทุกช่วงเวลา และดูเหมือนเป็นสิ่งที่นิยามการประมวลผลขึ้นมาใหม่ด้วยซ้ำ
เลยรู้สึกว่าฉันน่าจะกำลังพลาดมุมมองของฝั่งที่เกลียดมันขนาดนี้อยู่
OP เป็นหนึ่งใน ผู้ร่วมก่อตั้ง Tailscale เลยยิ่งน่าสนใจขึ้นในเชิงบริบท
ประเด็นที่ว่าบริษัท Cloud 1.0 แบบดั้งเดิมให้ค่าเริ่มต้นแค่ประมาณ 3000 IOPS บน VM แต่โน้ตบุ๊กกลับทำได้ 500,000 IOPS นั้นดูตรงมาก
วิสัยทัศน์ดีมากและฉันก็ดูเหมือนจะเป็นลูกค้าเป้าหมายพอดี แต่ก็กลัวว่าจะลงเอยตามเส้นทางคุ้นเคยที่ยิ่งประสบความสำเร็จมากเท่าไร แรงกดดันด้านรายได้ก็จะชนะอุดมคติมากขึ้นเท่านั้น
ราคาคลาวด์มักไม่ได้ตั้งตามต้นทุน และมักถูกออกแบบให้ทำกำไรหนักจากรายการอย่าง bandwidth หรือ NAT gateway ที่จะพุ่งขึ้นแรงหลังจากลูกค้าถูกผูกติดลึกแล้วโดยเฉพาะ
ฉันไม่คิดว่า OP จะไม่รู้โครงสร้างแบบนี้
แต่ storage แบบนี้โดยพื้นฐานแล้วเป็น ephemeral และก็ไม่มี redundancy มากพอ
แม้ RAID1 จะช่วยลดความเสี่ยงจากฮาร์ดแวร์เสียได้ แต่ก็ทำให้จำนวน NVMe ที่ต่อได้ลดลง และเวลาต้องย้าย VM เพราะปัญหาอย่าง RAM/CPU ของโฮสต์ ก็ไม่มีวิธีที่สวยนัก
สุดท้าย VM แบบนี้แทบต้องดูแลเหมือน bare metal และต้องมี redundancy ระดับแอปพลิเคชัน อย่าง replication ของฐานข้อมูล
กับ Azure ต้องสมมติว่าเขาสามารถย้าย VM เมื่อไรก็ได้และลบข้อมูล ephemeral ทิ้ง แต่ใน OpenStack เราสามารถปิด VM ไว้ก่อนแล้วคัดลอกข้อมูล NVMe ไปยังโฮสต์อื่นด้วย local block-level migration ได้เมื่อจำเป็น
ถึงอย่างนั้น ถ้าโฮสต์ crash VM นั้นก็ยังต้องล่มอยู่จนกว่าโฮสต์จะกลับมา ดังนั้นความซ้ำซ้อนระดับแอปจึงเป็นสิ่งที่ต้องมีอยู่ดี
แต่ latency ที่เปอร์เซ็นไทล์ 99.9 ของ Hetzner อยู่ราว 5ms ขณะที่ DO อยู่ราว 18ms และ latency สูงสุดคือ Hetzner 7ms เทียบกับ DO 85ms ซึ่งต่างกันพอสมควร
ในการทดสอบ dd แบบ sequential นั้น Hetzner ได้ 1.9GB/s ส่วน DO ได้ 850MB/s
ด้านราคา Hetzner 4 ยูโร แต่ instance ของ DO ราคา 18 ดอลลาร์ จึงต่างกันมาก
ฉันเขียนความเห็นนี้ก่อนอ่านจบ และ OP ก็ชี้ตรงไปที่สองอย่างนั้นพอดี
เหมือนทำให้แม้แต่เซิร์ฟเวอร์ธรรมดาก็ใช้ DB ภายในเครื่องได้ยาก เพื่อสร้าง lock-in
แนวคิดว่าทำของชิ้นหนึ่งต้นทุน X แล้วตั้งราคาเป็น 1.y*X นั้นห่างไกลจากการตั้งราคาจริงในตลาด
วิธีคิดแบบ top-down ใช้งานได้จริงกว่า bottom-up มาก
เหมือนกับที่การถกเถียงเรื่อง AI มักไปสุดทาง Kubernetes ก็ดูแบ่งขั้วไม่ต่างกัน
ฉันดูแลคลัสเตอร์หลายขนาดมาหลายปี แต่ไม่เคยมีครั้งไหนที่สาเหตุของปัญหาคือ k8s เอง
ครั้งหนึ่งเคยมี outage รุนแรงระดับไฟดับทั้งระบบนานหนึ่งชั่วโมง และฝั่งที่ไม่ชอบ k8s ก็พยายามโทษ "ระบบ k8s เวรนี่" กันหมด
แต่ต้นเหตุจริงคือ service ตัวหนึ่งเปิดพอร์ตนับหมื่นอย่างฉับพลันในบางสถานการณ์จนเกิด DOS ใส่ตัวเอง
ฉันไม่ได้คิดว่า k8s คืออนาคตทั้งหมด หรือเป็นขยะ แต่คิดว่ามันเป็นระบบที่ดีเมื่อมีความจำเป็นต้องใช้จริง ๆ
อย่างแรกคือมันซับซ้อนเกินไป ต้องเรียนรู้เยอะ ทั้งที่ปัญหาของฉันไม่ได้ต้องใช้และวิธี deploy เดิมก็เพียงพอแล้ว อีกอย่างคือมันมี ประสิทธิภาพด้านต้นทุน/พลังงาน แย่กว่า bare metal
โดยมากสองอย่างนี้มาคู่กัน
ท่าทีที่ค่อนข้างกลาง ๆ หรือไม่ค่อยสนใจกลับกลายเป็นของหายาก และนึกถึงการเมืองอเมริกันขึ้นมาทันที
ฉันเองก็ไม่ค่อยรู้เรื่อง k8s พอ staff engineer พูดเรื่อง pod กับ cluster ทีไรก็ลอยทุกที แต่กับทีมเรามันเหมาะและใช้งานได้จริง
คนที่มีแต่ค้อนก็จะมองทุกอย่างเป็นตะปู ส่วนคนถือขวานก็สงสัยว่าทำไมทุกคนถึงจะเอาค้อนมาผ่าฟืน
ยิ่งถ้างานนั้นจริง ๆ ควรใช้ขวาน แต่คนถือค้อนกลับมาแย่งงานไปได้ ก็ยิ่งง่ายที่จะเกลียดค้อน
สำหรับ k8s แนวทาง best practice ในหลาย use case เริ่มตกผลึกมาบ้างแล้ว แต่ฝั่ง LLM เรายังแทบไม่รู้เลยด้วยซ้ำว่าอะไรคือ best practice
ฉันเห็นด้วยมากกับข้อสังเกตที่ว่า VM ผูกอยู่กับ CPU/หน่วยความจำ จึงทำให้ เราจ่ายตามเวลาแทนที่จะจ่ายตามงาน
เพราะแบบนั้นฉันเลยซื้อเซิร์ฟเวอร์ประมูลราคาถูกของ Hetzner มาเครื่องหนึ่ง แล้วใช้บน Firecracker orchestrator ที่ self-host ได้ ที่ฉันทำเอง
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
สิ่งที่ฉันต้องการคือซื้อฮาร์ดแวร์มาแล้วแบ่งเป็น VM ได้ตามใจ โดยไม่ต้องกังวลเรื่อง provisioning หรือ lifecycle
VM ที่ไม่ได้ใช้งานจะ snapshot สถานะหน่วยความจำลงดิสก์และคืน RAM ทั้งหมด ทำให้ฮาร์ดแวร์เป็นของฉันเอง VM เป็นของใช้แล้วทิ้ง และแทบไม่มีต้นทุนตอนว่างงาน
โดยเฉพาะพอมี memory-state snapshot แล้ว ทุกอย่างก็กลายเป็นสิ่งที่ resume กลับมาได้ ซึ่งทรงพลังกว่าที่คิดมาก
ฉันสามารถ snapshot Chromium ที่ล็อกอินอยู่ไว้ แล้วเปิดสำเนา session ได้ทันทีเมื่อจำเป็น ส่วน agent ก็ทำงานใน sandbox และยังรัน docker compose สำหรับ preview environment ในนั้นด้วย
ตอนที่ไม่มีอะไรทำงาน เซิร์ฟเวอร์แทบจะ idle และเครื่องราคา 100 ดอลลาร์ต่อเดือนเครื่องเดียวก็จัดการทั้งหมดนี้ได้
รายละเอียดอยู่ที่ https://shellbox.dev/blog/race-to-the-bottom.html
เอกสารครบถ้วนและมีประโยชน์ แต่หลายส่วนให้ความรู้สึกว่า เขียนโดย AI ค่อนข้างชัด เลยอยากให้กระชับขึ้นอีกหน่อย
ถึงอย่างนั้นส่วน "design decisions" ดีมากเป็นพิเศษ และฉันก็ได้เรียนรู้อะไรใหม่ ๆ จากตรงนั้น
ถ้ายังไม่ได้ทำ ก็น่าลองโพสต์บน Show HN
ทุกวันนี้มีซอฟต์แวร์ที่ไม่มีใครใช้อยู่แล้วล้นโลก ฉันเลยไม่ค่อยเข้าใจว่าทำไมเราถึงหมกมุ่นกับ การปั่นโค้ดเพิ่มขึ้นเรื่อย ๆ
แค่ดูใน app store ก็มีซอฟต์แวร์ที่ไม่มีใครใช้อยู่เต็มไปหมด
สำหรับฉัน การใช้งาน LLM ที่ชัดเจนกว่าคือไม่ใช่การสร้างซอฟต์แวร์ให้มากขึ้น แต่คือการสร้าง ซอฟต์แวร์ที่ดีกว่าเดิม
อยากให้จุดสนใจย้ายออกจากการสร้างโค้ดอย่างเดียวไปสู่ทิศทางอื่น และก็มีหลายวิธีที่ LLM จะช่วยให้เขียนโค้ดได้ดีขึ้น
ภาพของระบบเชิงกำหนดที่ถูกออกแบบอย่างประณีต บำรุงรักษา และอัปเดต จะยังคงอยู่ แต่ AI กำลังเปลี่ยนวิธีที่ผู้ใช้โต้ตอบกับคอมพิวเตอร์อยู่แล้ว
ผลลัพธ์คืออาจเกิด ซอฟต์แวร์ที่ใช้แล้วทิ้งมากขึ้น
ตอนนี้เรายังอยู่ในช่วง "AI จะช่วยวิศวกรเขียนซอฟต์แวร์อย่างไร" แต่ฉันคิดว่าเรากำลังค่อย ๆ ขยับไปสู่ "วิศวกรจะทำอะไรเพื่อให้ AI เขียนซอฟต์แวร์ได้ดีขึ้น"
แล้วก็จะมีวิศวกรกลุ่มใหม่ที่มีมุมมองต่อความหมายของซอฟต์แวร์และการออกแบบปฏิสัมพันธ์กับคอมพิวเตอร์แบบต่างออกไปโดยสิ้นเชิงเข้ามา
ฉันคิดว่าจะมีซอฟต์แวร์แบบสั่งทำที่ไม่มีวันขึ้น app store เพิ่มขึ้นมาก
จะเรียกว่า Jevons paradox ได้ก็ต่อเมื่อ ต้นทุนการผลิตซอฟต์แวร์ลดลง แต่ความต้องการเพิ่มขึ้นจนมากพอจะหักล้างผลประหยัด และทำให้การใช้จ่ายรวมสูงขึ้น
แนวคิดนี้เกิดขึ้นได้ในตลาดที่ความต้องการตอบสนองต่อการเปลี่ยนแปลงของราคาแรง หรือก็คือมี elasticity ของอุปสงค์ สูง
ถ้าไม่นับเกม วันหนึ่งเราอาจหันกลับมามองว่าวิธีสร้างซอฟต์แวร์ตัวเดียวให้คนหลักล้านถึงหลักพันล้านใช้ร่วมกันนั้นแปลกแค่ไหน
ต่อไปคนจะถูกบิดเบือนด้วยลำดับความสำคัญที่ขัดกันหรือโมเดลรายได้เพี้ยน ๆ น้อยลง และจะสร้างซอฟต์แวร์ที่ทำสิ่งที่พวกเขาต้องการจริง ๆ ได้อย่างแม่นยำ
ตามนิยามแล้วซอฟต์แวร์แบบนั้นก็อาจถือว่า คุณภาพสูงกว่า ด้วย
นั่นทำให้ทั้งสองฝ่ายคาดการณ์ต้นทุนและรายได้ง่ายขึ้น แต่แก่นหลักคือการสร้างซอฟต์แวร์ที่ ใช้ได้กว้างที่สุดเท่าที่จะเป็นไปได้
ผลคือ UX หรือฟีเจอร์ที่สำคัญกับผู้ใช้แค่บางกลุ่มมักถูกตัดทิ้งเรื่อย ๆ
Vibe coding และการพัฒนาที่ LLM เร่งความเร็วให้ อาจพลิกสิ่งนี้ได้
ตอนนี้ทุกคนอาจจะสามารถมีซอฟต์แวร์ที่ปรับตามความต้องการและความชอบของตัวเองได้ และเราก็อาจจินตนาการถึงโลกที่ลูกค้า Salesforce 150,000 ราย ไม่ได้ใช้ CRM เดียวกัน แต่ใช้ CRM ที่ปรับแต่งเฉพาะของตัวเอง 150,000 แบบ
ตอนนี้พื้นที่ให้ซอฟต์แวร์ขยายตัวนั้นมหาศาลมาก
ถ้าไม่เข้าใจ วงจรการบวมของซอฟต์แวร์ ก็จะพลาดซ้ำเดิมไปเรื่อย ๆ
มันเริ่มจาก lean software จากนั้นฟีเจอร์ที่ผู้ใช้ต้องการก็สะสมเข้ามา ค่อย ๆ กลายเป็น bloated mess แล้วสุดท้ายก็ต้องมีการเขียนใหม่ให้เล็กลง ก่อนจะกลับไปเป็น lean software อีกครั้ง
การรีบูตใหม่ส่วนใหญ่มักล้มเหลว ไม่ก็เดินหน้าไปได้เพราะจับบางแก่นสำคัญได้ถูก จนถึงขั้นคุกคามเจ้าตลาดเดิม
มุมมองที่ลดค่า DevOps ว่าเป็นแค่ของไว้เติมเรซูเม่หรือเป็นต้นตอของความซับซ้อนเกินจำเป็นนั้น ฟังดูใกล้กับวิธีคิดแบบสตาร์ตอัปมากกว่า
ในบริษัทเล็ก DevOps คนหนึ่งอาจดูแลอินฟราทั้งหมด แต่โดยเฉพาะในวงการการเงิน คนที่กำหนดทิศทางจริงมักเป็น MD ฝั่ง platform engineering
คนกลุ่มนี้ชอบแบ่งวิศวกรซอฟต์แวร์ออกเป็นกลุ่มเล็ก ๆ มากมาย และอยากให้แต่ละทีมควบคุม repo ของตัวเอง deployment ของตัวเอง และทุกอย่างของตัวเอง โดยเชื่อว่า microservices จะมอบอำนาจนั้นให้
ฉันกล้าพูดเลยว่าฝั่ง DevOps เกลียดความซับซ้อน
เพราะคนที่ต้องโดนตามตอนกลางคืนและวันหยุดก็คือพวกเขา และเรื่องก็มักเริ่มจากสมมติฐานว่า "อินฟรามีปัญหา" อยู่แล้ว
ทั้งที่ log ของการ deploy ก็เข้าไปอยู่ในระบบรวม log หมด แต่พอเป็นปัญหาจาก deployment ของตัวเอง นักพัฒนากลับไม่ค่อยไปเปิด log ดูแก้เอง และกลายเป็น Incident ทันที
ถึงเวลาหรือยังที่เราจะมองว่าไมโครเซอร์วิสเป็นแฟชั่นเก่าไปแล้ว
ฉันมอง exe.dev ในแง่ดี และคิดว่ามีโอกาสชัดเจนสำหรับสิ่งที่ทำให้ workflow การพัฒนาด้วย LLM ลื่นขึ้น พร้อมยังให้ความยืดหยุ่นของเครื่อง Linux ที่มีสิทธิ์ root
แต่พออ่านประโยคที่ว่า "โดน abstraction ที่ทำมาแค่ครึ่งเดียวและคิดมาแค่ครึ่งเดียวหักหลังซ้ำแล้วซ้ำเล่า" มันก็ย้อนแย้งดี เพราะนั่นแหละคือประสบการณ์ที่ฉันมีกับ Tailscale เหมือนกัน
บอกว่าจะทำให้ networking ง่ายขึ้น แต่ทำไมแบตเตอรี่หมดเร็วขนาดนี้ ทำไมถึงไปแก้กฎไฟร์วอลล์ให้ชนกับเครื่องมืออื่น และทำไม bug tracker ถึงเงียบจนฉันต้องไปทำความเข้าใจ implementation ภายในเอง
มันเลยทำให้เผลอพูดว่า "No thank you"
ตัวบริการเองดูยอดเยี่ยมจริง ๆ
ฉันไม่ได้พยายามเขียน router ACL แต่กำลังพยายามจัดชั้นเครือข่ายแบบ peer-to-peer ซึ่งเป็นจุดที่น่าเสียดาย
ฉันก็ใช้ Hetzner นี่แหละ
ทุกอย่างที่บริษัทคลาวด์ขายมันแพงเกินไปหมด และ Postgres HA กับ backup ที่ฉันดูแลเองทำงานแบบไม่เคยล่มมา 10 ปีแล้ว แต่ค่าใช้จ่ายอยู่ที่ประมาณ หนึ่งในสิบ ของ RDS หรือ CloudSQL production เท่านั้น
ฉันทำ autoscale ของ instance เองจาก metrics ที่เก็บใน Grafana และ autoscaler แบบ webhook ก็เรียบง่ายมาก แถมไม่เคยก่อปัญหาเลย
เลยไม่ค่อยเข้าใจแล้วว่าทำไมต้องใช้ GCP หรือ AWS
ทุก service เป็น HA และ backup รายวันก็ทำได้ดีมาก
ตอนนั้นเป้าหมายคือทำซ้ำประสบการณ์ dedicated server ที่ยืดหยุ่นที่สุดให้ได้ในราคาถูก และ UML ก็ทำสิ่งนั้นได้
แต่ตลอดช่วงปี 2010 ฉันเดาผิดสนิทว่าคนส่วนใหญ่จะไม่ยอมแลก convenience เพียงเล็กน้อยกับการถูกคิดเงินแบบแยกทุกชิ้นของสแตก
ทุกวันนี้ฉันสงสัยว่าวิศวกรซอฟต์แวร์วัยยี่สิบกว่ายุคนี้ยังรู้ไหมว่าจะใช้เซิร์ฟเวอร์กับเราเตอร์ที่ซื้อมาจาก eBay มาประกอบเป็น แพลตฟอร์มเว็บแอปทราฟฟิกสูง ได้อย่างไร
ปีที่แล้วฉันก็เพิ่งทำแบบนั้นเพื่อสร้าง datastore ขนาด 50PiB+ และอยากรู้จริง ๆ ว่าแนวทางแบบนี้ยังถูกใช้ในโปรเจกต์ขนาดกลางถึงใหญ่แค่ไหน
Hetzner ช่วยลดความยุ่งยากทางกายภาพออกไปเยอะ ในขณะที่ยังคงข้อได้เปรียบด้านเศรษฐศาสตร์ไว้เกือบทั้งหมด เลยแปลกใจว่าทำไมมันถึงยังไม่ใช่ราชาแห่งโลกโฮสติ้ง และในปี 2021 ยังมีรายได้แค่ 367 ล้านยูโร
ฉันไม่ค่อยเชื่อว่าความรู้ในการจัดการ dedicated server หลายเครื่องจะกลายเป็นเรื่องเฉพาะทางถึงขนาดที่ผู้คนจะเมินการประหยัดระดับนี้
แต่ถ้าหาคนที่ใช่ได้ การทำเองก็มักถูกกว่ามากจริง
ทุก ๆ นาที cron จะรัน docker pull เพื่อดึง image ล่าสุด และจะสลับไปใช้เวอร์ชันใหม่ด้วย docker up -d เฉพาะตอนที่มีเวอร์ชันใหม่เท่านั้น
ด้านหน้าใช้ caddy สำหรับ HTTPS และระบบแบบนี้ก็ทำงานได้ถูกและเสถียรมาหลายปีแล้ว
ดูเหมือนบริษัทจากสหราชอาณาจักรที่มีแนวคิดคล้ายกัน ยังไม่ได้ลองใช้ แต่ก็สมัครบัญชีไว้เป็นตัวเลือกสำหรับ VPS เครื่องถัดไปแล้ว
เพราะเริ่มต้นด้วยเซิร์ฟเวอร์ที่เร็วกว่า 5 เท่าได้ จึงบ่อยครั้งที่ไม่จำเป็นต้องมี autoscaling เลย
มีทางเลือกอื่นอยู่แล้วมากมาย และฉันสร้าง https://shellbox.dev ขึ้นมา
ต่างจาก exe ตรงที่ คิดเงินตามที่ใช้จริง และ scale-to-zero ได้ พร้อมเปิด VM ผ่าน SSH ได้ทันที
มันเป็น Linux ปกติ จึงรองรับ VSCode และ Zed remote ด้วย และยังทำ nested virtualization ได้
ถ้าอยากลงทุน 5 ล้านดอลลาร์ก็พอแล้ว
ไม่มีพอร์ตไหนเปิดออกสู่ภายนอก และทุกเว็บฟรอนต์เอนด์ก็มีรหัสผ่านป้องกันไว้
ฉันไม่ได้คิดจะปล่อยสู่สาธารณะ มันคือ สภาพแวดล้อมพัฒนาแบบแยกขาด ของฉันเองที่รันอยู่บน Raspberry Pi หลังทีวี
แทบไม่มีค่าใช้จ่ายเลย
ขอให้บริการไปได้สวยนะ
ยังไม่ชัดเจนว่าจริง ๆ แล้วอินฟราพื้นฐานอยู่ที่ไหน หรือมีหลักประกันด้านความปลอดภัยอะไรบ้าง จึงยากที่จะฝาก workload ไว้