3 คะแนน โดย GN⁺ 2023-09-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความนี้พูดถึงแนวโน้มปัจจุบันในอุตสาหกรรมเทคโนโลยีที่ทำให้ระบบซับซ้อนเกินความจำเป็นด้วยไมโครเซอร์วิส
  • ผู้เขียน Andrei Taranchenko วิจารณ์แนวโน้มของวงการที่พยายามแก้ปัญหาที่ไม่มีอยู่จริง ซึ่งมักขับเคลื่อนด้วยความต้องการที่จะดูนวัตกรรมและล้ำสมัย
  • นักพัฒนา JavaScript ที่นิยามตัวเองว่าเป็น "full-stack" และกระโดดเข้าไปทำงานฝั่งเซิร์ฟเวอร์และโค้ดอะซิงโครนัส ก็ถูกชี้ว่าเป็นปัจจัยหนึ่งที่ส่งเสริมแนวโน้มนี้
  • เหล่าผู้มีประสบการณ์จาก FAANG ที่เข้ามามีอิทธิพลต่อสตาร์ตอัป และผลักดันให้ใช้ระบบซับซ้อนคล้ายกับที่ใช้ในบริษัทขนาดใหญ่ ก็ถูกมองว่าเป็นอีกปัญหาหนึ่ง
  • บทความชี้ให้เห็นว่าบริษัทที่ประสบความสำเร็จมากมาย เช่น Dropbox, Twitter, Facebook, Instagram, Shopify และ Stack Overflow เริ่มต้นด้วยโค้ดเบสเดียวและยังคงใช้งานได้อย่างมีประสิทธิภาพ
  • Taranchenko โต้แย้งว่าการผลักดันไมโครเซอร์วิสมักทำให้สูญเสียทั้งประสิทธิภาพและความเรียบง่าย และทำให้นักพัฒนาต้องคอยรักษาแผนที่ความเข้าใจของระบบทั้งหมดไว้ในหัว พร้อมรับมือกับการสื่อสารอย่างต่อเนื่องเกี่ยวกับการอัปเดตและการเปลี่ยนแปลง
  • ผู้เขียนเสนอว่าแทนที่จะผลักดันไมโครเซอร์วิส บริษัทต่าง ๆ ควรพิจารณาใช้บริการที่สามารถระบุขอบเขตได้ชัดเจนและรองรับโหลดที่ขยายแยกกันได้
  • บทความปิดท้ายด้วยการชี้ถึงการหันกลับไปหาระบบที่เรียบง่ายกว่า ในช่วงที่เงินทุนจาก venture capital ตึงตัวขึ้นและบริษัทต่าง ๆ จำเป็นต้องตัดสินใจอย่างใช้งานได้จริงมากขึ้น
  • Taranchenko แนะนำให้เริ่มต้นด้วยโมโนลิท และค่อยแยกออกเป็นเซอร์วิสเมื่อจำเป็น แทนที่จะกระโดดไปใช้ไมโครเซอร์วิสตั้งแต่แรก

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

 
GN⁺ 2023-09-13
ความคิดเห็นจาก Hacker News
  • บทความเกี่ยวกับข้อดีข้อเสียของการใช้ไมโครเซอร์วิสและโมโนลิทในการพัฒนาซอฟต์แวร์
  • นักวิจารณ์คนหนึ่งซึ่งเคยมีส่วนร่วมในการสร้างแพลตฟอร์มของ Netflix แนะนำให้สตาร์ตอัปเริ่มต้นด้วยโมโนลิท เพราะมีความเรียบง่ายและขยายระบบได้
  • นักวิจารณ์อีกคนชี้ว่าไมโครเซอร์วิสเป็นทางออกของปัญหาทางสังคม ไม่ใช่ปัญหาทางเทคนิค โดยช่วยให้องค์กรขนาดใหญ่แบ่งระบบออกเป็นระบบย่อยเพื่อสร้างและทำซ้ำได้อย่างรวดเร็ว
  • นักวิจารณ์บางคนวิจารณ์แนวโน้มการย้ายไปใช้ไมโครเซอร์วิส โดยเสนอว่าหลายครั้งสิ่งนี้ไม่ได้ขับเคลื่อนด้วยการแก้ปัญหาทางเทคนิคที่ดีที่สุด แต่เป็นความต้องการจะหลีกเลี่ยงปัญหาในโค้ดเดิมหรือทำให้เรื่องเล่าดูสอดคล้องกัน
  • อีกบางคนแย้งว่าไมโครเซอร์วิสอาจนำไปสู่ระบบที่ซับซ้อนและดีบักได้ยาก และอาจต้องการการสนับสนุนด้านโครงสร้างพื้นฐานจำนวนมาก
  • นักวิจารณ์ส่วนน้อยแสดงความไม่พอใจกับความท้าทายในการดูแลรักษาและสังเกตการณ์ไมโครเซอร์วิส โดยเฉพาะในทีมขนาดเล็กที่มีทรัพยากรจำกัด
  • บางคนเสนอว่าการย้ายไปใช้ไมโครเซอร์วิสมักเกิดขึ้นอย่างเร่งรีบเกินไป และการรักษาระบบให้เรียบง่ายอาจให้ผลลัพธ์ที่ดีกว่า
  • นักวิจารณ์คนหนึ่งวิจารณ์ว่าบทความนำเสนอข้อมูลสนับสนุนข้ออ้างไม่เพียงพอ และเสนอว่าเป้าหมายที่ดีกว่าคือการจัดการความซับซ้อนเพื่อลดต้นทุนของการเปลี่ยนแปลงระบบ