การอ้างของบริษัทหนึ่งที่ประหยัดเงินได้มากกว่า 500,000 ดอลลาร์สหรัฐ ต่อปี โดยการแทนที่ Amazon S3 ด้วยโซลูชันจัดเก็บวัตถุของตนเอง ได้จุดประเด็นการถกเถียงอย่างร้อนแรงในชุมชนเทคโนโลยี แม้ความสำเร็จด้านเทคนิคจะน่าประทับใจ แต่วิศวกรจำนวนมากกำลังตั้งคำถามว่าต้นทุนจริงของการสร้างและบำรุงรักษาโครงสร้างพื้นฐานแบบกำหนดเองนั้น มีค่ามากกว่าการประหยัดที่เห็นชัดเจนหรือไม่
กรณีศึกษาเดิมอธิบายถึงไปป์ไลน์การประมวลผลวิดีโอที่ประสบความสำเร็จในการลดต้นทุนการจัดเก็บวัตถุลง 60 เท่า และได้ประสิทธิภาพเพิ่มขึ้น 10 เท่า โดยการพัฒนา Nebari ซึ่งเป็นทางเลือกแทน S3 ภายในของพวกเขา ระบบนี้จัดการกับกล้องหลายพันตัวที่มีสตรีมข้อมูลที่มีปริมาณเพิ่มขึ้นสองเท่าทุกไม่กี่เดือน สร้างความต้องการพื้นที่เก็บข้อมูลมหาศาลที่กลายเป็นค่าใช้จ่ายที่สูงลิ่วด้วยการจัดเก็บข้อมูลบนคลาวด์แบบดั้งเดิม
ผลประโยชน์ที่รายงานจากโซลูชันจัดเก็บข้อมูล "Nebari" แบบกำหนดเอง:
- ลดต้นทุนการจัดเก็บข้อมูลแบบ object storage ลงได้ 60 เท่า
- ปรับปรุงประสิทธิภาพได้ 10 เท่า
- ประหยัดค่าใช้จ่ายมากกว่า $500,000 USD ต่อปี
- ออกแบบมาสำหรับไปป์ไลน์การประมวลผลวิดีโอที่มีกล้องหลายพันตัว
- จัดการสตรีมข้อมูลที่เพิ่มปริมาณเป็นสองเท่าทุกๆ ไม่กี่เดือน
คำถามเรื่องการประหยัด: จริงหรือแค่ทฤษฎี?
ปฏิกิริยาแรกสุดจากชุมชนวิศวกรรมมุ่งเน้นไปที่ว่าการอ้างการประหยัด 500,000 ดอลลาร์สหรัฐ นั้นแสดงถึงประโยชน์สุทธิที่แท้จริงหรือไม่ ผู้แสดงความคิดเห็นหลายคนชี้ให้เห็นว่าต้นทุนในการพัฒนานั้นไม่ได้ถูกนำมาคิดรวมในสมการด้วย
แค่อ่านบล็อกโพสต์ก็ทำให้ฉันสงสัยว่าพวกเขาประหยัดจริงๆ ถึง 500,000 ดอลลาร์สหรัฐ หรือไม่ พวกเขาใช้เวลาสร้างโซลูชันนานแค่ไหน ใช้คนกี่คนในการสร้าง บริการใหม่มีค่าใช้จ่ายเท่าไรขณะที่มันกำลังทำงาน? บริการใหม่ต้องการชั่วโมงการดำเนินงานเท่าไร?
ความรู้สึกนี้สะท้อนไปทั่วทั้งการสนทนา โดยวิศวกรระบุว่า 500,000 ดอลลาร์สหรัฐ นั้นแสดงถึงเงินเดือนวิศวกรหนึ่งถึงสองคนแบบเต็มอัตราในสหรัฐอเมริกา หากการพัฒนาต้องใช้วิศวกรหลายคนเป็นเวลาหลายเดือน การประหยัดที่แท้จริงอาจต้องใช้เวลาหลายปีกว่าจะเกิดขึ้น ค่าใช้จ่ายในการดำเนินงานต่อเนื่องและภาระการบำรุงรักษายังทำให้การคำนวณซับซ้อนยิ่งขึ้น
ความกังวลของชุมชนเกี่ยวกับโซลูชันการจัดเก็บข้อมูลแบบกำหนดเอง:
- ต้นทุนการพัฒนาไม่ได้ถูกนำมาคำนวณในการประหยัดค่าใช้จ่าย
- ค่าใช้จ่ายในการบำรุงรักษาและการดำเนินงานอย่างต่อเนื่อง
- อาจมีโซลูชันทางเลือกอื่นที่ถูกมองข้าม
- ผลกระทบด้านความปลอดภัยของผู้ให้บริการคลาวด์รายใหญ่
- จำเป็นต้องมีการคำนวณต้นทุนการเป็นเจ้าของโดยรวมที่แท้จริง
โซลูชันทางเลือกที่ถูกมองข้าม
ผู้แสดงความคิดเห็นหลายคนตั้งคำถามว่าทำไมบริษัทจึงไม่ได้สำรวจทางเลือกที่ง่ายกว่าก่อนที่จะมุ่งมั่นสร้างโครงสร้างพื้นฐานแบบกำหนดเอง ข้อเสนอแนะรวมถึงการต่อรองราคาที่ต่ำลงกับ AWS การใช้ระดับการจัดเก็บที่แตกต่างกัน การนำกระบวนการทำความสะอาดอัตโนมัติมาใช้ หรือการเปลี่ยนไปใช้ผู้ให้บริการอื่นเช่น Cloudflare
การสนทนาเปิดเผยว่าวิศวกรจำนวนมากชอบการปรับแต่งโซลูชันที่มีอยู่ให้ดีขึ้นมากกว่าการสร้างตั้งแต่เริ่มต้น ผู้แสดงความคิดเห็นหนึ่งคนระบุว่าการเติบโตของต้นทุนแบบทวีคูณมักทำให้บริษัทต่างประหลาดใจ ทำให้โซลูชันที่รุนแรงดูเหมือนจำเป็น ในขณะที่การปรับแต่งให้เหมาะสมที่เรียบง่ายกว่าอาจเพียงพอแล้วในวงจรการเติบโตก่อนหน้านี้
ความกังวลด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด
นอกเหนือจากการคำนวณต้นทุน การสนทนาหันไปสู่ความหมายที่กว้างขึ้นของการพึ่งพาการจัดเก็บข้อมูลบนคลาวด์ วิศวกรบางคนแสดงความประหลาดใจว่าบริษัทต่างๆ ไว้วางใจข้อมูลที่ละเอียดอ่อนให้กับผู้ให้บริการคลาวด์รายใหญ่ได้อย่างไรง่ายดายเช่นนี้
ความกังวลนี้ขยายไปไกลกว่าการรั่วไหลของข้อมูลที่อาจเกิดขึ้น เพื่อรวมถึงคำขอข้อมูลจากรัฐบาลและความเข้มข้นของข้อมูลในสิ่งที่ผู้แสดงความคิดเห็นหนึ่งคนเรียกว่าเป้าหมายที่ใหญ่ที่สุดในโลก นี่เน้นย้ำถึงแง่มุมของการตัดสินใจจัดเก็บข้อมูลบนคลาวด์ที่มักถูกมองข้าม: การแลกเปลี่ยนระหว่างความสะดวกสบายและการควบคุมข้อมูลที่ละเอียดอ่อน
ธุรกิจของการกำหนดราคาบนคลาวด์
การสนทนารองที่น่าสนใจเกิดขึ้นเกี่ยวกับเศรษฐศาสตร์ของผู้ให้บริการคลาวด์ บางคนสงสัยว่า AWS อาจลดราคาในที่สุดเพื่อรักษาลูกค้าที่ขยายขนาดถึงจุดหนึ่ง ในขณะที่คนอื่นๆ ตั้งข้อสังเกตว่าด้วยส่วนแบ่งการตลาด 40% แล้ว Amazon มีแรงจูงใจน้อยที่จะแข่งขันด้านราคาสำหรับลูกค้ารายใหญ่
เรื่องนี้สัมผัสกับความเป็นจริงพื้นฐานของการประมวลผลบนคลาวด์: รูปแบบการกำหนดราคาที่ใช้ได้ผลสำหรับสตาร์ทอัปกลับมีค่าใช้จ่ายเพิ่มขึ้นเรื่อยๆ เมื่อบริษัทขยายขนาด สร้างโอกาสสำหรับโซลูชันเฉพาะทางที่ปรับให้เหมาะสมสำหรับกรณีการใช้งานเฉพาะ
คำตัดสินเกี่ยวกับโซลูชันแบบกำหนดเอง
การตอบสนองจากชุมชนชี้ให้เห็นว่าในขณะที่โซลูชันโครงสร้างพื้นฐานแบบกำหนดเองสามารถส่งผลลัพธ์ที่น่าประทับใจได้ แต่พวกมันไม่ใช่ทางเลือกที่ถูกต้องเสมอไป ฉันทามติดูเหมือนจะเห็นว่าการลงทุนดังกล่าวสมเหตุสมผลเฉพาะในระดับที่สำคัญเท่านั้น และแม้กระทั่งในเวลานั้น บริษัทควรใช้ตัวเลือกการปรับให้เหมาะสมทั้งหมดกับผู้ให้บริการที่มีอยู่ก่อนแล้ว
กรณีศึกษานี้ทำหน้าที่เป็นทั้งแรงบันดาลใจและบทเรียนเตือนใจ - สาธิตสิ่งที่ทำได้ในทางเทคนิค ในขณะที่เตือนใจวิศวกรให้คำนวณต้นทุนรวมจริงทั้งหมดอย่างรอบคอบก่อนเริ่มต้นโครงการโครงสร้างพื้นฐานขนาดใหญ่
อ้างอิง: How We Saved $500,000 Per Year by Rolling Our Own “S3”