ชุมชนเทคโนโลยีกำลังตอบโต้ข้อกล่าวอ้างที่ว่าการ self-hosting ซอฟต์แวร์นั้นยากโดยธรรมชาติ ก่อให้เกิดการถกเถียงอย่างร้อนแรงเกี่ยวกับความซับซ้อนที่แท้จริงของการจัดการโครงสร้างพื้นฐานด้วยตนเองเทียบกับการพึ่งพาบริการคลาวด์ การอภิปรายนี้มุ่งเน้นไปที่คำถามพื้นฐานเกี่ยวกับการย้ายฐานข้อมูล แนวปฏิบัติด้านความปลอดภัย และว่าเครื่องมือสมัยใหม่ได้ทำให้การ self-hosting ง่ายขึ้นกว่าที่เคย
 |
|---|
| ความยากลำบากของการ self-hosting ซอฟต์แวร์: การจัดการโครงสร้างพื้นฐานและเครื่องมือที่ซับซ้อน |
ความท้าทายในการย้ายฐานข้อมูลจุดประกายความขัดแย้งทางเทคนิค
ข้อโต้แย้งทางเทคนิคหลักหมุนรอบการเปลี่ยนชื่อคอลัมน์ฐานข้อมูลและกลยุทธ์การย้ายข้อมูล ในขณะที่บางคนโต้แย้งว่าการดำเนินการดังกล่าวมีความเสี่ยงโดยธรรมชาติในสภาพแวดล้อม self-hosted นักพัฒนาที่มีประสบการณ์กำลังตั้งคำถามกับสมมติฐานนี้โดยสิ้นเชิง ชุมชนชี้ไปที่รูปแบบที่ได้รับการยอมรับ เช่น การสร้างคอลัมน์ใหม่ควบคู่ไปกับคอลัมน์เก่า การใช้ intermediate updatable views และการใช้ proxy layers เพื่อจัดการการเปลี่ยนแปลง schema อย่างราบรื่น
นักพัฒนาหลายคนเน้นย้ำว่าเทคนิคการย้ายข้อมูลที่เหมาะสมได้รับการยอมรับมาหลายทศวรรษแล้ว แนวทางนี้เกี่ยวข้องกับการอัปเดตโค้ดเพื่อใช้คอลัมน์ใหม่ในขณะที่รักษาความเข้ากันได้แบบย้อนหลัง จากนั้นค่อยๆ เลิกใช้โครงสร้างเก่าเมื่อระบบทั้งหมดได้ย้ายข้อมูลแล้ว
เทคนิคการย้ายฐานข้อมูลที่กล่าวถึง:
- สร้างคอลัมน์ใหม่โดยไม่ลบคอลัมน์เก่า
- อัปเดตโค้ดเพื่อใช้คอลัมน์ใหม่พร้อมรักษาความเข้ากันได้แบบย้อนหลัง
- ใช้ intermediate updatable views (คุณสมบัติของ PostgreSQL )
- ใช้ proxy layers เช่น ProxySQL สำหรับการเขียน query ใหม่
- ใช้ rolling updates ร่วมกับเครื่องมือ orchestration
ความซับซ้อนของ Self-Hosting ถูกตั้งคำถามโดยผู้ปฏิบัติงาน
ผู้ปฏิบัติงานจำนวนมากโต้แย้งว่าการ self-hosting ได้กลายเป็นเรื่องง่ายขึ้นอย่างมากด้วยเครื่องมือสมัยใหม่ การผสมผสานของ containerization แพลตฟอร์ม orchestration อย่าง Docker Swarm และฐานข้อมูลแบบคลัสเตอร์เช่น TiDB หรือ CockroachDB ได้ทำให้การ deployment และการบำรุงรักษาง่ายขึ้น เครื่องมือเหล่านี้ให้ automatic load balancing, rolling updates และโซลูชันสำรองข้อมูลในตัว
ผมมี SaaS อายุ 20 ปีที่ทำงานในแร็คกับเซิร์ฟเวอร์อายุ 10-20 ปี ผมหวังว่าลูกค้าทุกคนจะทำงานแบบนั้นเพราะมันเสถียร ไม่มี modern blergh stacks มันทำงานได้และเร็ว
ชุมชนเน้นย้ำว่าการหยุดทำงานที่ประสานงานกันเพื่อการบำรุงรักษาอาจเป็นที่ต้องการมากกว่าการย้ายข้อมูลแบบ zero-downtime ที่ซับซ้อน โดยเฉพาะสำหรับลูกค้าองค์กรที่สามารถวางแผนรอบช่วงเวลาบำรุงรักษาที่กำหนดไว้
สแต็กเทคโนโลยี Self-Hosting สมัยใหม่:
- Containerization: Docker สำหรับการแพ็กเกจแอปพลิเคชัน
- Orchestration: Docker Swarm สำหรับการกระจายโหลดและการอัปเดตแบบ rolling
- ฐานข้อมูล: TiDB , CockroachDB สำหรับการจัดกลุ่มและการสำรองข้อมูลอัตโนมัติ
- CDN: Cloudflare สำหรับการจัดการทราฟฟิก
- โครงสร้างพื้นฐาน: Hetzner และผู้ให้บริการที่คล้ายกันสำหรับการโฮสต์ที่คุ้มค่า
ข้อสมมติด้านความปลอดภัยของคลาวด์ถูกตรวจสอบอย่างละเอียด
การถกเถียงขยายไปถึงการพิจารณาด้านความปลอดภัย โดยนักพัฒนาท้าทายข้อสมมติที่ว่าการโฮสต์บนคลาวด์มีความปลอดภัยโดยธรรมชาติมากกว่าการ self-hosting สมาชิกชุมชนชี้ให้เห็นว่าบริการคลาวด์ที่กำหนดค่าผิด โดยเฉพาะ AWS RDS instances และการตั้งค่า IAM มักสร้างช่องโหว่ด้านความปลอดภัยที่ไม่มีอยู่ในสภาพแวดล้อม self-hosted ที่จัดการอย่างเหมาะสม
การอภิปรายเผยให้เห็นว่าปัญหาความปลอดภัยหลายอย่างเกิดจากความซับซ้อนมากกว่าตำแหน่งการโฮสต์ แพลตฟอร์มคลาวด์สามารถสร้างความท้าทายด้านความปลอดภัยของตัวเองผ่านการกำหนดค่าที่ผิดพลาด ในขณะที่โซลูชัน self-hosted ให้การควบคุมโดยตรงมากขึ้นเหนือการใช้งานความปลอดภัย
ความต้องการขององค์กรขับเคลื่อนความต้องการ Self-Hosting
แม้จะมีแนวโน้ม cloud-first ลูกค้าองค์กรยังคงต้องการตัวเลือก self-hosted สำหรับระบบที่สำคัญเช่นโครงสร้างพื้นฐานการเรียกเก็บเงิน ชุมชนสังเกตว่า 42% ของผู้นำ IT ได้ย้าย workloads ออกจากแพลตฟอร์มคลาวด์ โดยขับเคลื่อนด้วยความต้องการในการปรับแต่ง การควบคุมข้อมูล และความสามารถในการรวมระบบที่ขยายเกินข้อจำกัดของ API
สำหรับลูกค้าองค์กร ความสามารถในการรวมระบบอย่างลึกซึ้งกับระบบที่มีอยู่และรักษาการควบคุมอย่างสมบูรณ์เหนือข้อมูลที่ละเอียดอ่อนมักจะมีน้ำหนักมากกว่าความสะดวกสบายของการโฮสต์บนคลาวด์ สิ่งนี้เป็นจริงโดยเฉพาะสำหรับระบบเรียกเก็บเงินที่การหยุดทำงานหรือการละเมิดข้อมูลสามารถส่งผลกระทบทางธุรกิจอย่างรุนแรง
การถกเถียงที่กำลังดำเนินอยู่สะท้อนความตึงเครียดในอุตสาหกรรมที่กว้างขึ้นระหว่างความสะดวกสบายของบริการคลาวด์และการควบคุมที่เสนอโดยโซลูชัน self-hosted ขณะที่เครื่องมือต่างๆ ยังคงพัฒนาต่อไป อุปสรรคทางเทคนิคต่อการ self-hosting ยังคงลดลง ทำให้ทางเลือกขึ้นอยู่กับความต้องการทางธุรกิจมากกว่าข้อจำกัดทางเทคนิค
Reference: Why building a self-hosted SaaS is a headache (and how we make it easier)