คุยเรื่องไมโครเซอร์วิสกับสถาปัตยกรรมเบื้องหลังบริษัทใหญ่ที่คุณควรรู้

เคยสังเกตไหมว่าแอปพลิเคชันที่เราเปิดใช้งานในทุกวัน มันดูเหมือนจะรองรับคนจํานวนมหาศาลพร้อมกันได้ตลอดเวลา ไม่ว่าจะเป็นแอปธนาคารหรือแอปสั่งอาหารเจ้าดังๆ เบื้องหลังหน้าจอที่เราเห็น มันมีโครงสร้างการทํางานที่ซับซ้อนกว่าเมื่อก่อนมาก หากย้อนกลับไปสมัย

ก่อน ตอนที่เราจะเขียนโปรแกรมสักตัว ก็มักจะเขียนเป็นก้อนเดียวใหญ่ๆ หรือที่หลายคนในวงการคุ้นหูกันในชื่อ โมโนลิธ ข้อดีหลักๆ คือทําง่าย ดูแลอยู่ในที่เดียวได้สบาย แต่พอบริษัทเติบโตขึ้น มีผู้ใช้งานหลายล้านคนพร้อมกัน ก้อนใหญ่ก้อนนี้เริ่มจะมีปัญหา การจะ

แก้แค่ฟีเจอร์เดียวหรืออัปเดตระบบนิดหน่อย อาจจะกลายเป็นว่าทําให้ระบบล่มทั้งแพลตฟอร์มได้ คนในทีมเลยต้องกลับมาคิดทบทวนใหม่ว่าโครงสร้างเดิมยังรอดไหม จากจุดนี้เองแนวคิดที่เรียกว่าไมโครเซอร์วิสจึงถูกยกขึ้นมาพูดถึงบ่อยขึ้น หลายบริษัทจึงตัดสินใจแยกส่วน

ประกอบของระบบออกจากกัน เป็นบริการย่อยๆ ที่สามารถคุยกันได้ผ่านเน็ตเวิร์กเหมือนการต่อจิ๊กซอว์ชิ้นเล็กๆ เข้าด้วยกัน ถ้าวันไหนบริการส่วนจองคิวมีปัญหา บริการส่วนอื่นก็ยังคงทํางานได้ตามปกติ นี่เป็นเหตุผลสําคัญที่ทําให้บริษัทขนามใหญ่ต่างยอมเสียเวลาและงบ

ประมาณมหาศาลในการรื้อโครงสร้างระบบ เพื่อให้แอปของตัวเองยืนระยะได้นานขึ้นและยืดหยุ่นกว่าที่เคยเป็นมา แต่เหรียญย่อมมีสองด้านเสมอ เพราะการแยกส่วนออกมาเป็นชิ้นเล็กชิ้นน้อยก็นํามาซึ่งความปวดหัวรูปแบบใหม่ ทีมพัฒนาต้องเก่งขึ้น ต้องรับมือกับการสื่อสาร

ระหว่างบริการที่อาจขัดข้องได้ตลอดเวลา รวมถึงการจัดการข้อมูลที่กระจัดกระจายไปคนละทิศทาง บางทีมอาจจะรู้สึกว่าถ้าไม่ได้ทําระบบในสเกลใหญ่ขนาดนั้น การกลับไปเขียนแบบเดิมที่จัดการง่ายกว่าก็น่าจะตอบโจทย์มากกว่าและจุกจิกน้อยกว่ากันเยอะ เรื่องนี้จึงกลาย

เป็นประเด็นที่คนในวงการมักจะนํามาถกเถียงกันอยู่บ่อยครั้งว่าอะไรคือทางออกที่ดีที่สุด หลายคนมองว่าเป็นทิศทางที่หลีกเลี่ยงไม่ได้หากต้องการขยายธุรกิจให้โตขึ้นเรื่อยๆ ในขณะที่บางคนก็เห็นว่าความซับซ้อนที่ตามมาอาจไม่คุ้มค่าสําหรับงานบางประเภท เพื่อนๆ ที่

ได้มีประสบการณ์คลุกคลีกับการเขียนโค้ดและดูแลระบบเหล่านี้ลองมาแชร์มุมมองหรือประสบการณ์กันได้ ไม่ว่าจะเป็นความลําบากตอนไล่แก้บั๊กหรือความสุขเวลาที่ระบบทํางานได้เป็นอิสระต่อกัน ใครมีความเห็นอย่างไรลองพิมพ์แลกเปลี่ยนกันได้เลย