ปี 2568 ลูกตุ้มสถาปัตยกรรมเหวี่ยงมาหาแนวทางที่ใช้งานได้จริงอย่างไร
ช่วงกลางทศวรรษนี้ วงการพัฒนาซอฟต์แวร์เจอเรื่องที่เมื่อไม่กี่ปีก่อนยังดูเป็นไปไม่ได้: ไมโครเซอร์วิส สไตล์สถาปัตยกรรมที่ถูกมองมานานว่าเป็นอนาคตที่ไม่มีทางเลือกอื่น เริ่มถูกทบทวนบ่อยขึ้นเรื่อย ๆ เพราะเคสดัง ๆ ที่หันกลับไปใช้โมโนลิธทำให้วงการต้องคำนวณต้นทุนของความซับซ้อนกันใหม่ บริษัทที่เดินทางจากโมโนลิธ (monolith) ไปจนถึงการแตกระบบเป็นเซอร์วิสแบบสุดทาง พูดถึงความซับซ้อน ต้นทุน และการที่ระบบเริ่มคุมไม่อยู่บ่อยขึ้นเรื่อย ๆ แทนที่จะพูดถึงการขยายระบบ (scalability) และความยืดหยุ่น
ลูกตุ้มสถาปัตยกรรมเหวี่ยงกลับแล้ว แต่ไม่ได้กลับไปหาโมโนลิธแบบเก่า มันเหวี่ยงไปหาทางออกที่สุกงอมและใช้งานได้จริงกว่า
ยุคโมโนลิธ: ง่าย จนกระทั่งมันซับซ้อนเกินไป
ช่วงราวปี 2543–2547 สถาปัตยกรรมแบบโมโนลิธคือมาตรฐานของวงการ แอปเดียว โค้ดชุดเดียว ฐานข้อมูลร่วมกัน ทุกอย่างอยู่ในโปรเซสเดียว วิธีนี้ทำให้เริ่มต้นได้เร็ว และทีมส่วนใหญ่ก็เข้าใจได้ง่าย
ปัญหาเริ่มมาเมื่อระบบโตขึ้น ทุกการแก้ไขเสี่ยงไปกระทบส่วนของแอปที่ไม่คาดคิด การดีพลอยเวอร์ชันใหม่กลายเป็นงานที่ชวนเครียด ส่วนการขยายระบบก็หมายถึงการขยายทั้งแอปทั้งก้อน ไม่ว่าส่วนไหนจะเป็นส่วนที่รับโหลดอยู่จริง
ถึงอย่างนั้น เป็นเวลาหลายปีที่คนมองว่านี่คือการแลกที่เลี่ยงไม่ได้ จนกระทั่งมีไม่กี่บริษัทที่ตัดสินใจว่ามันทำแบบอื่นได้
การมาของสถาปัตยกรรมแบบเซอร์วิสและคำสัญญาถึงอนาคตใหม่
จุดเปลี่ยนสำคัญจุดหนึ่งคือการปรับโครงสร้างภายในของ Amazon ช่วงราวปี 2540–2546 บริษัทเลิกให้คอมโพเนนต์เชื่อมกันตรง ๆ และกำหนดให้การสื่อสารทั้งหมดต้องผ่านอินเทอร์เฟซของเซอร์วิสเท่านั้น Amazon จึงกลายเป็นตัวอย่างที่ดังที่สุดของสถาปัตยกรรมเชิงบริการ (SOA) ซึ่งเป็นแนวทางที่นักวิเคราะห์ของ Gartner อธิบายไว้ตั้งแต่ปี 2539
อีกเคสที่เป็นหมุดหมายคือ Netflix หลังระบบล่มครั้งใหญ่ในปี 2551 บริษัทรื้อระบบสร้างใหม่ทั้งหมด ย้ายขึ้นคลาวด์และแยกฟังก์ชันออกเป็นเซอร์วิสอิสระจำนวนมาก ทำให้ขยายระบบเป็นส่วน ๆ ได้ พัฒนาได้เร็วขึ้น และทนต่อความล้มเหลวได้ดีขึ้น
ตัวอย่างเหล่านี้กลายเป็นต้นแบบอย่างรวดเร็ว วงการได้ข้อสรุปว่า ไมโครเซอร์วิสคือคำตอบของทุกปัญหาที่มากับการเติบโต
ไมโครเซอร์วิสกลายเป็นหลักความเชื่อ และรอยร้าวแรก ๆ
สถาปัตยกรรมไมโครเซอร์วิสสัญญาไว้หลายอย่าง:
- ทีมที่ทำงานอิสระต่อกัน
- ดีพลอยได้บ่อย
- ขยายระบบได้อย่างยืดหยุ่น
- อิสระในการเลือกเทคโนโลยี
บริษัทต่าง ๆ เริ่มหั่นระบบเป็นชิ้น ๆ กันยกใหญ่ บางครั้งก็ไม่ได้เข้าใจชัดว่าทำไมคอมโพเนนต์นั้น ๆ ต้องแยกเป็นเซอร์วิสต่างหาก ผลคือแทนที่จะมีแอปซับซ้อนตัวเดียว ก็มีชิ้นส่วนอิสระเป็นสิบ ๆ แล้วก็เป็นร้อย ๆ
เมื่อเวลาผ่านไปก็เห็นชัดว่า ปัญหาไม่ได้หายไปไหน มันแค่เปลี่ยนรูป
การเรียกฟังก์ชันกลายเป็นการเรียกผ่านเครือข่าย ตามมาด้วย latency การ serialize ข้อมูล และภาระต้องดูแลให้ API เข้ากันได้ การมอนิเตอร์และการเก็บล็อกกลายเป็นแบบกระจาย การดีบักทั้งยากและช้า ส่วนการรันทั้งระบบบนเครื่องตัวเองก็แทบจะเป็นไปไม่ได้
สิ่งที่เคยเป็นแค่รายละเอียดภายในโค้ด กลายเป็นปัญหาระดับโครงสร้างพื้นฐาน
เมื่อเซอร์วิสเยอะเกินไป
ต้นทุนของไมโครเซอร์วิสแบบสุดโต่งเห็นได้ชัดที่สุดในบริษัทใหญ่
Uber กับ “ดาวมรณะ”
Uber ที่โตเร็วมาก แตกระบบออกเป็นไมโครเซอร์วิสหลายพันตัว ในปี 2563 เฉพาะตัวที่สำคัญต่อระบบก็มีราว 2,200 ตัวแล้ว แผนผังการเชื่อมต่อระหว่างเซอร์วิสจึงดูเหมือนสิ่งที่วิศวกรเรียกกันว่า “ดาวมรณะ” (Death Star) คือมีโหนดมหาศาลและเส้นเรียกหากันไปมาเหมือนใยแมงมุม
การกระทำเดียวของผู้ใช้ อย่างการเรียกรถ ต้องให้เซอร์วิสหลายสิบตัวทำงานประสานกัน ทั้งตำแหน่งที่ตั้ง ค่าโดยสาร การจับคู่คนขับ และการแจ้งเตือน ความผิดพลาดจุดไหนก็สะท้อนไปถึงประสบการณ์ของผู้ใช้ทันที
Uber ตอบโจทย์นี้ด้วยแนวทาง Domain-Oriented Microservice Architecture โดยจัดกลุ่มเซอร์วิสเป็นโดเมน คือหน่วยเชิงตรรกะที่ดูแลฟังก์ชันทางธุรกิจแต่ละด้าน โดยเนื้อแท้แล้ว นี่คือความพยายามดึงการควบคุมกลับมาและลดจุดที่เซอร์วิสต้องคุยกัน
Twitter กับความพยายาม “ลดให้ง่ายแบบฉับพลัน”
Twitter ก็มาถึงขีดจำกัดเหมือนกัน ระบบประกอบด้วยเซอร์วิสแบ็กเอนด์จำนวนมากที่ดูแลฟีเจอร์แต่ละอย่าง เดือนพฤศจิกายน 2565 ไม่นานหลังซื้อบริษัท Elon Musk ประกาศว่าจะปิดไมโครเซอร์วิสส่วนใหญ่เพราะมองว่าเกินจำเป็น วันเดียวกันนั้น ผู้ใช้บางส่วนไม่ได้รับรหัส SMS สำหรับการยืนยันตัวตนสองขั้นตอน อดีตพนักงานและสื่อหลายสำนักโยงเหตุขัดข้องนี้กับการปิดเซอร์วิส แต่ Twitter ไม่เคยยืนยันสาเหตุอย่างเป็นทางการ
ถ้าความเชื่อมโยงนี้เป็นจริง เหตุการณ์นี้ก็แสดงสองเรื่องพร้อมกัน: สถาปัตยกรรมซับซ้อนจนแม้แต่คนในบริษัทก็เข้าใจได้ยาก และการถอยกลับแบบฉับพลันโดยไม่วิเคราะห์ให้ลึกเป็นเรื่องอันตราย ถึงอย่างนั้น แค่การที่ต้องลดความซับซ้อนก็เป็นสัญญาณบอกอะไรบางอย่างแล้ว
โมโนลิธกลับมา แต่ไม่ใช่ตัวเดิม
ในวงการค่อย ๆ เกิดแนวทางสายกลางขึ้น นั่นคือ โมดูลาร์โมโนลิธ
นี่ไม่ใช่การกลับไปหาระบบไร้โครงสร้างแบบในอดีต โมดูลาร์โมโนลิธคือแอปขนาดใหญ่หนึ่งหรือไม่กี่ตัว ที่ข้างในแบ่งโค้ดเป็นโมดูลอิสระอย่างชัดเจน แต่ละโมดูลมีขอบเขตความรับผิดชอบชัด โมดูลเหล่านี้ดีพลอยไปพร้อมกัน แต่ออกแบบให้แยกออกไปเป็นเซอร์วิสต่างหากได้เมื่อจำเป็น
ไอเดียง่าย ๆ: ถ้าส่วนต่าง ๆ ของระบบเปลี่ยนและขยายไปพร้อมกัน ก็ไม่มีเหตุผลที่จะฝืนแยกมันด้วยเส้นแบ่งของเครือข่าย
เศรษฐศาสตร์แรงกว่าอุดมการณ์
เคสที่เห็นภาพชัดที่สุดเคสหนึ่งคือ Amazon Prime Video ทีมสร้างระบบมอนิเตอร์คุณภาพวิดีโอบนสถาปัตยกรรมแบบ serverless ที่มีฟังก์ชันเล็ก ๆ จำนวนมาก
พอขยายระบบก็พบว่า ค่าใช้จ่ายก้อนใหญ่ไม่ได้หมดไปกับการประมวลผล แต่หมดไปกับการสื่อสารระหว่างคอมโพเนนต์ หลังวิเคราะห์แล้ว ทีมจึงเขียนระบบใหม่เป็นแอปแบบโมโนลิธ
ผลลัพธ์เหนือความคาดหมาย ค่าโครงสร้างพื้นฐานลดลงมากกว่า 90% และการขยายระบบก็ดีขึ้น ในปี 2566 เคสนี้กลายเป็นการยอมรับต่อสาธารณะที่ดังที่สุดว่าไมโครเซอร์วิสไม่ใช่ทางออกสำหรับทุกงาน แต่ไม่ใช่ครั้งแรก ตั้งแต่ปี 2561 Segment ก็เล่าแล้วว่ารวมไมโครเซอร์วิสกว่า 140 ตัวกลับเป็นเซอร์วิสเดียวได้อย่างไร
Shopify ได้ข้อสรุปคล้ายกัน แทนที่จะหั่นโมโนลิธ Rails ของตัวเองเป็นไมโครเซอร์วิส ก็แบ่งมันเป็นคอมโพเนนต์ที่มีขอบเขตเข้มงวดภายในแอปเดียว ส่วน Dropbox เลือกทางสายกลาง แพลตฟอร์ม Atlas ของบริษัทหั่นโมโนลิธออกเป็นคลัสเตอร์กว่า 200 คลัสเตอร์ที่ดีพลอยแยกกันได้ และบริษัทเองเรียกแนวทางนี้ว่าแบบไฮบริด
เลือกสถาปัตยกรรมอย่างไรในปี 2568
แนวทางสมัยนี้พึ่งกระแสน้อยลง และพึ่งบริบทมากขึ้น
คำถามหลักมีประมาณนี้:
- ขนาดทีม ทีมเล็กแทบไม่ค่อยได้ประโยชน์จากไมโครเซอร์วิส
- ลักษณะของโหลด มีส่วนไหนของระบบที่ต้องขยายแยกกันจริง ๆ ไหม
- Non-functional requirement (ข้อกำหนดที่ไม่ใช่เชิงฟังก์ชัน) latency สำคัญมากไหม ต้องการความสอดคล้องของข้อมูล (consistency) แบบเข้มงวดหรือเปล่า
- งบประมาณและความเชี่ยวชาญ ทีมพร้อมดูแลโครงสร้างพื้นฐานที่ซับซ้อนหรือยัง
สำหรับสตาร์ทอัปและโปรดักต์เล็ก ๆ โมโนลิธมักยังเป็นตัวเลือกที่ดีที่สุด: เร็วกว่า ประหยัดกว่า เข้าใจง่ายกว่า ไมโครเซอร์วิสคุ้มค่าเมื่อมันแก้ปัญหาที่ชัดเจนและวัดผลได้
อีกเรื่องที่สำคัญคือ สถาปัตยกรรมไม่ใช่การตัดสินใจครั้งสุดท้าย เริ่มจากโมโนลิธแล้วค่อย ๆ แยกเซอร์วิสออกไปตามการเติบโตก็ได้ ทางกลับกันก็ทำได้ แต่ยากและแพงกว่ามาก
แทนบทสรุป: ลูกตุ้มหยุดที่จุดสมดุล
ประวัติศาสตร์ของแนวทางสถาปัตยกรรมแสดงให้เห็นว่า ความสุดโต่งไม่ค่อยอยู่ได้นาน โมโนลิธหนักเกินไป ไมโครเซอร์วิสซับซ้อนเกินไป สุดท้ายวงการก็มาถึงมุมมองที่สุกงอมและเน้นใช้งานจริงมากขึ้น
วันนี้สถาปัตยกรรมไม่ใช่เรื่องของความเชื่อ และไม่ใช่การวิ่งตามเทรนด์ มันคือการคำนวณเชิงวิศวกรรม และการตอบคำถามอย่างตรงไปตรงมาว่า เรากำลังแก้ปัญหาอะไรอยู่ตอนนี้
และแนวทางนี้แหละ ไม่ใช่ตัวย่อเท่ ๆ ตัวใหม่ ที่กำหนดสถาปัตยกรรมของระบบในปี 2568
เกณฑ์เลือกแบบเร็ว
ในทีมเล็ก โมโนลิธแก้ไข ทดสอบ และดีพลอยได้ง่ายกว่า ไมโครเซอร์วิสคุ้มค่าเมื่อการขยายระบบแยกส่วน ความเป็นอิสระของทีม หรือการกันไม่ให้ความล้มเหลวลามถึงกัน สำคัญกว่าต้นทุนของระบบแบบกระจายจริง ๆ ควรเริ่มจากขอบเขตของโดเมน ไม่ใช่จากจำนวนเซอร์วิส
บทความที่มีประโยชน์และการพูดคุยอยู่ที่นี่ (ภาษารัสเซีย)
