จาก Monolith สู่ Microservices: วิวัฒนาการของสถาปัตยกรรมที่เริ่มต้นจากความเจ็บปวดของทีมหน้างาน

เมื่อระบบเดิมกลายเป็นคอขวด: จุดเริ่มต้นที่ทีมปฏิบัติการต้องเผชิญหน้ากับความจริง

ทุกครั้งที่เราเปิดประตูเข้าสู่โปรเจกต์ใหญ่ๆ สิ่งที่พบเจอบ่อยที่สุดคือระบบที่ถูกสร้างมาแบบเดียวจบในก้อนเดียว — โค้ดทั้งหมดอยู่ใน Repository เดียวกัน, ฐานข้อมูลใช้ร่วมกัน, และทุกการ Deploy ต้องให้ทุกฝ่ายประสานงานกันแบบ Lockstep แนวคิดเรื่อง Microservices ที่ Sam Newman ถ่ายทอดไว้ในหนังสือ Building Microservices (Second Edition) ไม่ได้เริ่มต้นจากการนั่งวางแผนบนกระดานขาวในห้องประชุม แต่มันเกิดขึ้นจากความเจ็บปวดจริงของทีมนักพัฒนาที่ต้องดิ้นรนกับ Delivery Contention — ปัญหาที่ทุกครั้งที่จะอัปเดตฟีเจอร์เล็กๆ น้อยๆ กลับต้องรอให้ทั้งระบบผ่านกระบวนการทดสอบและปล่อยร่วมกัน

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

การแตกแยกจากฐานราก: เมื่อทีมหน้างานเริ่มนิยามขอบเขตด้วย Domain-Driven Design

Newman เน้นย้ำอย่างชัดเจนว่า ปัญหาที่ยากที่สุดในการเปลี่ยนผ่านสู่ Microservices ไม่ใช่เรื่องเทคโนโลยี แต่เป็นเรื่องของการ "นิยามขอบเขต" หรือที่เรียกกันว่า Bounded Context ในโลกของ Domain-Driven Design (DDD) ลองจินตนาการภาพทีม Engineers ที่นั่งทำ Event Storming กันหน้ากระดานขาวขนาดใหญ่ เขียน Sticky Notes สีต่างๆ แทน Event ที่เกิดขึ้นในระบบจริงของธุรกิจลูกค้า จากนั้นค่อยๆ จัดกลุ่ม หาขอบเขต และระบุ Aggregate ที่ควรอยู่ด้วยกัน — นี่คือ Grassroots Innovation ที่เกิดขึ้นจากความเข้าใจถึงโดเมนจริง ไม่ใช่การตัดสินใจจากกระดานขาวในมุมมองของผู้บริหาร

แนวคิดเรื่อง Information Hiding, Cohesion และ Coupling ที่ Newman อธิบายไว้ลึกซึ้งมาก ไม่ใช่แค่ทฤษฎีวิศวกรรมซอฟต์แวร์แบบเก่าๆ แต่เป็นเครื่องมือในการตัดสินใจว่า Service ใดควรแยกตัวออกมา และ Service ใดควรอยู่รวมกัน การหลีกเรียนรู้เรื่อง Domain Coupling, Pass-Through Coupling, และ Common Coupling ทำให้ทีมปฏิบัติการสามารถออกแบบระบบที่แต่ละส่วนสามารถ Deploy ได้แยกกันโดยอิสระ (Independent Deployability) ซึ่งนี่คือจุดที่ทำให้ Tech Stack สมัยใหม่อย่าง Next.js, Node.js หรือ Redis ที่ Customix ใช้ในการพัฒนาเว็บไซต์สามารถแสดงศักยภาพสูงสุดได้

เสียงกรีดร้องของระบบกระจาย: เมื่อ Trade-off ทางเทคนิคท้าทายมาตรฐานระดับองค์กร

เมื่อระบบเริ่มแตกออกเป็นหลาย Service พร้อมกัน นั่นคือช่วงเวลาที่ความซับซ้อนเริ่มทวีคูณ หนังสือเล่มนี้ไม่ได้ปิดบังความจริงอันโหดร้ายนี้ เรื่องของ Data Consistency ที่เคยได้มาฟรีจาก ACID Transaction ในฐานข้อมูลเดียว กลายเป็นปัญหาใหญ่ที่ต้องแก้ด้วย Saga Pattern การทดสอบระบบ (Testing) ที่เคยเขียน Unit Test และ End-to-End Test แบบเดิมๆ ไม่เพียงพอต่อความซับซ้อนของระบบกระจาย จนต้องใช้ Contract Tests และ Consumer-Driven Contracts (CDCs) เข้ามาช่วย รวมถึงเรื่องของ Observability ที่ต้องพึ่งพา Log Aggregation, Metrics Aggregation และ Distributed Tracing เพื่อให้เห็นภาพรวมของระบบที่ไม่อาจมองเห็นด้วยตาเปล่า

สิ่งที่น่าสนใจคือ แรงกดดันเหล่านี้ไม่ได้หายไปเอง แต่มันกลับส่งผลกระทบกลับไปยังระดับองค์กร ตัวอย่างเช่น เมื่อทีมหน้างานต้องการใช้ Container และ Kubernetes เพื่อแก้ปัญหาการ Deploy แบบ Zero-Downtime สิ่งนี้ไม่ใช่แค่เรื่องของ Infrastructure แต่มันบังคับให้องค์กรต้องปรับมาตรฐานด้าน Security (Zero Trust Architecture), ปรับโครงสร้างทีมให้สอดคล้องกับ Conway's Law ที่ว่าสถาปัตยกรรมระบบจะเลียนแบบโครงสร้างองค์กร และสร้าง Internal Platform ที่ช่วยลดภาระของทีม Stream-Aligned ลง — นี่คือตัวอย่างชัดเจนของ Bottom-Up Drive ที่การตัดสินใจระดับปฏิบัติการไล่เกลี่ยขึ้นไปเปลี่ยนแปลงโครงสร้างระดับองค์กร

จาก Grassroots Innovation สู่มาตรฐานใหม่: บทเรียนสำหรับ Evolutionary Architect

สิ่งที่ทำให้ Building Microservices (Second Edition) แตกต่างจากหนังสือสถาปัตยกรรมทั่วไปคือแนวคิดเรื่อง Evolutionary Architecture ที่ Newman นำเสนอในบทสุดท้าย เขาไม่เชื่อใน Architect ที่นั่งอยู่บนอาคารสูงแล้วโยนผังระบบลงมาให้ทีมล่าง Implement แต่เชื่อใน Architect ที่เดินอยู่ท่ามกลางทีมปฏิบัติการ กำหนด Principles และ Practices ที่เป็นแนวทาง ไม่ใช่กฎเหล็ก สร้าง Paved Road ที่ทำให้ทีมเดินไปในทิศทางที่ถูกต้องได้ง่ายกว่าเดินออกนอกทาง และใช้ Governance ที่ผสมผสานระหว่าง Automated Gate กับ Human Review อย่างมีสัดส่วน

ในท้ายที่สุด การตัดสินใจว่าจะใช้ Microservices หรือไม่ ไม่ควรตอบด้วยคำว่า "ใช่" หรือ "ไม่" แบบตรงไปตรงมา แต่ควรตอบด้วยคำถามว่า "ปัญหาที่เรากำลังเผชิญอยู่นั้น มีต้นกำเนิดมาจากความซับซ้อนของระบบหรือความซับซ้อนขององค์กร?" หากต้นตออยู่ที่ระบบ การปรับสถาปัตยกรรมอาจช่วยได้ แต่หากต้นตออยู่ที่โครงสร้างองค์กร การเปลี่ยนแปลงสถาปัตยกรรมโดยไม่ปรับโครงสร้างทีมไปพร้อมกัน อาจกลายเป็น Distributed Monolith ที่ไร้ประโยชน์และเต็มไปด้วยความเจ็บปวดยิ่งกว่าเดิม สำหรับทุก Software House ที่กำลังพิจารณาพัฒนาระบบในรูปแบบใหม่ การเริ่มต้นจากความเข้าใจโดเมนจริง ฟังเสียงจากทีมที่ทำงานอยู่หน้างาน และวิวัฒนาการสถาปัตยกรรมไปทีละก้าว คือแนวทางที่ยั่งยืนที่สุด

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

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