มองข้าม 'ขนาด' จับต้อง 'เสรีภาพ': แก่นแท้ของไมโครเซอร์วิสที่กำลังเขย่ามาตรฐานระดับองค์กร

เมื่อสถาปัตยกรรมแบบเก่ากลายเป็นพิมพ์เขียวของการเจริญพันธุ์ปัญหา

ในอดีต วงการพัฒนาซอฟต์แวร์เคยหลงใหลในแนวคิดของ Service-Oriented Architecture (SOA) ซึ่งพูดถึงการแบ่งระบบออกเป็นบริการย่อยๆ ที่ทำงานร่วมกัน ทว่าด้วยแรงผลักดันจากผู้ขายเครื่องมือระดับองค์กรที่ต้องการผลักดันสินค้าของตัวเอง ทำให้ SOA กลับกลายเป็นฝันร้ายของทีมหน้างาน ที่ต้องดิ้นรนอยู่กับพิธีการซับซ้อนของโปรโตคอลแบบเก่า, ซอฟต์แวร์กลาง (Middleware) ที่ซ้ำซ้อน และการกำหนดขอบเขตบริการที่ผิดพลาด ผลลัพธ์ที่ได้คือระบบที่ดูเหมือนแยกส่วน แต่พื้นที่เก็บข้อมูล (Database) ยังคงถูกผูกมัดเป็นหนึ่งเดียว ทำให้ทุกครั้งที่ต้องอัปเดตระบบ ทีมพัฒนายังคงต้องประสานงานและ Deploy ทุกอย่างพร้อมกัน

ไมโครเซอร์วิสจึงไม่ได้ถือกำเนิดขึ้นมาจากการถกเถียงกันในห้องประชุมบริหาร หากแต่มันคือ Grassroots Innovation ที่งอกเงยขึ้นมาจากปัญหาจริงในสนามปฏิบัติการ โดยทีมหน้างานได้นำเอาความเข้าใจที่ลึกซึ้งขึ้นเกี่ยวกับสถาปัตยกรรมระบบมาปรับใช้ ผลักดันให้เกิดแนวทางใหม่ที่ทำ SOA ได้อย่างแท้จริง ในลักษณะเดียวกับที่ Extreme Programming (XP) หรือ Scrum คือการนำ Agile มาใช้จริงอย่างเป็นรูปธรรม

การหลุดพ้นจากพิมพ์เขียวเดิม: Bottom-Up Drive สู่เสรีภาพในการ Deploy

หากเราต้องยกหัวข้อสำคัญที่สุดของไมโครเซอร์วิสไปไว้บนแท่นบูชาข้อเดียว นั่นคือ 'Independent Deployability' หรือความสามารถในการ Deploy อย่างเป็นอิสระ มันไม่ใช่แค่ข้อเท็จจริงทางเทคนิค แต่เป็นวินัยที่ทีมหน้างานต้องยึดถือเป็นมาตรฐานพื้นฐานในการปล่อยระบบ คุณทำการเปลี่ยนแปลงไมโครเซอร์วิสตัวใดตัวหนึ่ง แล้วส่งมันขึ้นสู่ Production ได้ทันที โดยไม่ต้องไปยุ่งเกี่ยวกับ Services อื่นๆ

เพื่อให้บรรลุจุดนี้ ทีมวิศวกรได้หยิบเอาแนวคิด Hexagonal Architecture ที่ Alistair Cockburn เคยนิยามไว้มาปรับใช้อย่างเต็มรูปแบบ โดยแยกส่วนของการทำงานภายใน (Internal Implementation) ออกจากส่วนของอินเทอร์เฟซภายนอก (External Interfaces) อย่างชัดเจน การทำเช่นนี้สร้างแรงกดดันทางอ้อมที่ดีต่อมาตรฐานระดับองค์กร เพราะเมื่อทีมหน้างานยึดเป้าหมายความเป็นอิสระนี้ไว้ มันกลายเป็น Forcing Function ที่บังคับให้ทุกฝ่ายต้องออกแบบระบบให้มี Coupling ต่ำและ Cohesion สูงโดยธรรมชาติ ข้อตกลงระหว่าง Services จึงต้องถูกกำหนดอย่างชัดเจนและคงที่

การปะทะระหว่างพิกัดทางเทคนิคกับขอบเขตทางธุรกิจ

อุปสรรคที่ใหญ่ที่สุดที่ทีมหน้างานต้องเผชิญในการปฏิบัติจริง คือการปลดปล่อยตัวเองจากฐานข้อมูลร่วม (Shared Databases) หลักการที่ชัดเจนคือ หาก Service หนึ่งต้องการข้อมูลของอีก Service หนึ่ง มันต้อง 'ขอ' ผ่าน API ตามข้อกำหนด ไม่ใช่ลักลอบเปิดทางลัดเข้าไปอ่านตารางใน Database โดยตรง การที่แต่ละ Service มีสิทธิ์ในการครอบครองและซ่อนข้อมูลของตัวเอง (Owning Their Own State) นี้เอง ทำให้เกิด Information Hiding ที่สมบูรณ์แบบ เทียบเท่ากับหลักการ Encapsulation ในโลกของ Object-Oriented Programming

เมื่อพูดถึง 'ไมโคร' คำถามยอดฮิตคือ 'มันควรจะเล็กแค่ไหน?' แต่ James Lewis จาก Thoughtworks เคยกล่าวไว้ติดปากว่า 'ไมโครเซอร์วิสควรมีขนาดพอที่จะเข้าใจได้ในหัวของคุณ (As big as your head)' ในท้ายที่สุดแล้ว ขนาดไม่ใช่ตัวแปรสำคัญ แต่สิ่งที่สำคัญกว่าคือการออกแบบ Service รอบๆ โดเมนธุรกิจ (Modeled Around a Business Domain) ผ่าน Domain-Driven Design แทนที่จะแบ่งระบบตามเลเยอร์ทางเทคนิค เพราะการเปลี่ยนแปลงส่วนใหญ่ที่เกิดขึ้นมักเป็นการเปลี่ยนแปลงทางธุรกิจ หากเราแบ่งระบบแบบเลเยอร์ การเปลี่ยนแปลงฟีเจอร์เล็กๆ น้อยๆ กลับต้องไล่แก้ทั้ง Presentation, Logic และ Data Tier ซึ่งขัดต่อจุดประสงค์ของการพัฒนาในยุคปัจจุบัน

การโค่นล้มกำแพงเขตแดน: เมื่อสถาปัตยกรรมบังคับองค์กรให้จัดโครงสร้างตัวเองใหม่

สิ่งที่น่าสนใจที่สุดคือ ไมโครเซอร์วิสไม่ได้เปลี่ยนแปลงแค่โค้ด แต่มันกำลังเขย่าโครงสร้างของ Enterprise จนต้องหายใจใหม่ ลองมองภาพบริษัท E-commerce แห่งหนึ่งที่ใช้สถาปัตยกรรมแบบ 3 ชั้น (Three-Tiered) หากต้องการเพิ่มฟีเจอร์ให้ลูกค้าเลือกแนวเพลงโปรด ทีม Frontend, ทีม Backend และทีม DBA ต้องประสานกันและ Deploy กันทีละขั้นตอนอย่างเหนื่อยล้า นี่คือภาพสะท้อนของกฎของ Conway ที่ว่า สถาปัตยกรรมระบบใดๆ ก็ตาม มักจะเป็นภาพสะท้อนของโครงสร้างการสื่อสารขององค์กรนั้นๆ

แต่เมื่อทีมหน้างานเริ่มนำไมโครเซอร์วิสมาใช้ พวกเขาไม่ได้แค่แบ่งระบบให้เล็กลง แต่พวกเขา 'ตัดขวาง' ระบบในแนวตั้ง (Vertical Slices) ตามเส้นทางธุรกิจ แทนที่จะจัดกลุ่มคนตามความเชี่ยวชาญทางเทคนิค องค์กรถูกบังคับให้ปรับตัวจัดตั้งทีมที่มีทักษะหลากหลาย (Poly-skilled Teams) ที่รับผิดชอบ Feature ตั้งแต่หน้าจอไปจนถึงฐานข้อมูลเต็มรูปแบบ เพื่อลด Handoffs และทำให้สามารถส่งมอบซอฟต์แวร์ได้เร็วขึ้น ไมโครเซอร์วิสจึงเปรียบเสมือนการหมุนปุ่มระดับเสียง (Turning a dial) ไม่ใช่การกดสวิตช์เปิด-ปิด ยิ่งคุณหมุนเพิ่ม คุณจะได้ความยืดหยุ่นมากขึ้น แต่คุณก็ต้องเรียนรู้ที่จะจัดการกับความซับซ้อนที่เพิ่มขึ้นด้วย และนั่นคือทางเลือก (Options) ที่ทีมวิศวกรรมระดับสูงตัดสินใจจะซื้อไว้เพื่ออนาคตขององค์กร

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

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