มองผ่านกระแส Hype: เจาะแก่นจริงของ Microservices และอำนาจซ่อนเร้นของ Information Hiding

ภาพลวงของ Silver Bullet และการตื่นรู้ของทีมหน้างาน

ในช่วงหลายปีที่ผ่านมา กระแสความนิยมของ Microservices ได้พุ่งสู่จุดสูงสุดจนกลายเป็นค่าเริ่มต้น (Default Choice) ขององค์กรหลายแห่ง โดยมักถูกมองว่าเป็นตัวแปรที่จะมาช่วยแก้ปัญหาทั้งหมดของระบบเก่า แต่ความจริงในสนามปฏิบัติการคือ เมื่อทีมพัฒนาลงมือทำจริง พวกเขามักจะพบว่าการแค่ย้ายระบบไปใช้เทคโนโลยีใหม่ๆ อย่าง Kubernetes นั้นไม่ได้ช่วยแก้ปัญหาพื้นฐานทางสถาปัตยกรรมให้หายไป กลับกลายเป็นการเพิ่มความซับซ้อนใหม่เข้ามาแทน ปรากฏการณ์นี้สร้างแรงกดดันอย่างมหาศาลต่อทีมหน้างานที่ต้องดูแลระบบให้ทำงานได้จริง จนในที่สุด พวกเขาต้องลุกขึ้นมาหาแนวทาง Grassroots Innovation ด้วยตนเอง โดยย้อนกลับไปทบทวนพื้นฐานทางวิศวกรรมที่แท้จริง แทนที่จะเดินตามกระแสเทคโนโลยีที่ถูกบิดเบือนจากแรงดึงดูดทางการตลาด

ความลับที่ถูกมองข้าม: Information Hiding สู่การกำหนดขอบเขตอย่างแท้จริง

เมื่อเราลองถอดชั้นของความซับซ้อนออก สิ่งที่ทำให้ Microservices ทำงานได้ดีนั้นไม่ได้มีรากฐานมาจากเครื่องมือ แต่มาจากแนวคิดที่เรียกว่า Information Hiding ซึ่งเป็นหลักการทางวิศวกรรมที่ถูกยกขึ้นมาเป็นรากฐานหลัก (Foundational Concept) โดยทีมสถาปนิกที่เข้าใจภาพรวม หลักการนี้คือการ 'ซ่อน' ข้อมูลและการทำงานภายในให้มากที่สุด และ 'เปิดเผย' เพียงสิ่งที่จำเป็นต้องสื่อสารออกไปทางส่วนต่อประสาน (Network Endpoints) ไม่ว่าจะเป็น REST API หรือ Message Queue ซึ่งหมายความว่าระบบแต่ละส่วนต้องเป็น Black Box ที่สมบูรณ์แบบ โดยมีฐานข้อมูลเป็นของตัวเอง ไม่ใช่การแชร์ฐานข้อมูลร่วมกันแบบ Monolith ดั้งเดิม เมื่อทีมพัฒนาสามารถกำหนดขอบเขต (Boundaries) ของระบบได้ชัดเจนผ่านหลักการนี้ การเปลี่ยนแปลงภายใน Microservice หนึ่งก็จะไม่ส่งผลกระทบต่อระบบอื่นๆ ที่เรียกใช้งานมัน ส่งผลให้เกิด Independent Releasability หรือความสามารถในการปล่อยระบบอัปเดตได้อย่างอิสระ

เมื่อ Bottom-Up Drive ปะทะกับมาตรฐานระดับองค์กร

สิ่งที่น่าสนใจคือ แนวคิดดังกล่าวไม่ได้เกิดขึ้นจากการบัญญัติมาตรฐานจากชั้นบริหาร แต่เกิดจาก Bottom-Up Drive ของทีมวิศวกรและสถาปนิกระบบที่ต้องเผชิญกับปัญหาจริงในการ Splitting the Monolith เมื่อพวกเขานำ Domain-Driven Design และ Information Hiding มาใช้จัดการกับระบบเดิมที่ยุ่งเหยิง ผลลัพธ์ที่ได้คือความยืดหยุ่นในการทำงานที่ดีขึ้นอย่างก้าวกระโดด แรงผลักดันนี้ค่อยๆ ส่งผลกระทบกลับไปยังโครงสร้างขององค์กร เมื่อฝ่ายบริหารเห็นว่าทีมหน้างานสามารถจัดส่งฟีเจอร์ใหม่ๆ ได้เร็วขึ้น ปัญหาด้าน Resiliency และ Security ลดลง มาตรฐานระดับองค์กรจึงเริ่มปรับตัว โดยลดการควบคุมแบบเข้มงวดด้านเทคโนโลยี (Technology Agnostic) และเปิดช่องให้แต่ละทีมเลือกใช้เครื่องมือที่เหมาะสมกับหน้าที่ของตน เช่น การเลือกใช้ Next.js สำหรับสร้างส่วนติดต่อผู้ใช้ที่ต้องการ SEO สูง หรือ Node.js ในส่วนของระบบหลังบ้านที่ต้องการ Asynchronous Processing ที่แข็งแกร่ง

วิวัฒนาการสู่สถาปัตยกรรมที่ยั่งยืนภายใต้บริบทของธุรกิจ

ในท้ายที่สุด สถาปัตยกรรมของระบบไม่ว่าจะในรูปแบบใด ไม่ควรถูกมองเป็นสินค้าที่ซื้อมาติดตั้ง แต่เป็นสิ่งที่ต้อง Evolution ไปพร้อมกับธุรกิจ การรับทำเว็บไซต์หรือพัฒนาระบบในปัจจุบันจึงไม่ใช่แค่เรื่องของการเขียนโค้ด แต่เป็นการออกแบบขอบเขตความรับผิดชอบของระบบให้ตอบโจทย์การทำงานในระยะยาว หากเรากลับไปดูแนวคิดของ Evolutionary Architect ที่เน้นการปรับเปลี่ยนสถาปัตยกรรมอย่างต่อเนื่อง จะพบว่าความสำเร็จของการพัฒนาระบบระดับองค์กรไม่ได้ขึ้นอยู่กับการนำเอาเทรนด์มาใช้ แต่ขึ้นอยู่กับพื้นฐานทางความคิดที่แข็งแกร่ง การปกป้องขอบเขตของข้อมูล และการสร้างทีมที่มีความรู้ความเข้าใจในบริบททางธุรกิจของตัวเอง เพื่อให้ระบบเหล่านั้นเติบโตไปพร้อมกับองค์กรอย่างยั่งยืน

แหล่งข้อมูลอ้างอิง

Sam Newman (2021). Building Microservices. O'Reilly Media. (เนื้อหาบางส่วนเรียบเรียงและอ้างอิงโครงสร้างระบบเทคนิคจากหนังสือ: Building Microservices)