Common Risks (ความเสี่ยงที่พบบ่อย)

หนึ่ง ในความเสี่ยงที่ใหญ่ที่สุดของ microservices คือการทำ service ให้เล็ก เกินไป ในปี 2016 ผู้เขียนคนหนึ่งของเรา (Mark) บัญญัติชื่อ Grains of Sand ให้กับ antipattern ของการทำ service ให้ละเอียดเกินไป เหมือนเม็ดทรายบนชายหาด ดังที่กล่าวไปแล้ว คำว่า micro ใน microservices หมายถึง สิ่งที่ service ทำ ไม่ใช่ว่ามัน ใหญ่ แค่ไหน granularity ของ service เป็นแง่มุมที่สำคัญมากใน microservices จนเราอุทิศทั้งบทหนึ่ง (Chapter 7) ในหนังสือของเรา Software Architecture: The Hard Parts ให้กับเรื่องนี้โดยเฉพาะ

ความเสี่ยงที่พบบ่อยอีกอย่างใน microservices คือการสร้างการสื่อสารระหว่าง service มากเกินไป ธรรมชาติที่ละเอียด ของ microservices ผนวกกับ bounded context ที่แน่นหนา ทำให้ service ต่าง ๆ ใน microservices ecosystem จำเป็นต้องสื่อสาร กันเองอยู่เสมอ การสื่อสารนี้อาจเกิดจากการประมวลผล workflow (เช่น choreography หรือ AWS step function สำหรับ serverless microservice) หรือต้องการข้อมูลจาก service อื่น (เนื่องจาก bounded context ของแต่ละ service และข้อมูลของมัน) ไม่ว่าเหตุผลจะเป็นอะไร ควรระวังไม่ให้เกิด dynamic coupling และการสื่อสารระหว่าง service มากเกินไป ปัญหานี้มักเกิดจาก การทำ service ให้ละเอียดเกินไปเช่นกัน และสามารถแก้ได้โดยรวม service เข้าด้วยกันให้เป็น microservice ที่หยาบขึ้น

ความเสี่ยงอีกอย่างของ microservices คือการแชร์ข้อมูลมากเกินไป แม้เราจะกล่าวไปแล้วว่าการแชร์ข้อมูลใน microservices เป็นไปได้ (และบางครั้งก็จำเป็น) แต่การแชร์ข้อมูลมากเกินไปก็สร้างความเสี่ยงต่อ change control, scalability, fault tolerance และความคล่องตัวโดยรวมของระบบ—ซึ่งเป็นสิ่งที่ microservices ทำได้ดีมาก (ดู "Style Characteristics" ) รู้ให้ได้ว่าเมื่อไหร่จำเป็นต้องแชร์ข้อมูล และเมื่อไหร่ควรแก้ปัญหาการแชร์ข้อมูลด้วยการรวม service เข้าด้วยกัน

ความเสี่ยงสุดท้ายที่มักถูกมองข้ามในสถาปัตยกรรมสไตล์ microservices คือการใช้ซ้ำโค้ดและแชร์ฟังก์ชันการทำงาน การใช้ซ้ำโค้ดเป็นส่วนจำเป็นของการพัฒนาซอฟต์แวร์ แต่การใช้ซ้ำโค้ดและฟังก์ชันการทำงานขัดกับหลักการของ microservices โดยตรง ซึ่งเป็นที่มาของคำว่าสถาปัตยกรรมแบบ "share nothing" ที่กล่าวถึงก่อนหน้านี้ในบทนี้ เมื่อสถาปนิกแชร์ฟังก์ชัน การทำงานร่วมกันระหว่าง service ผ่าน custom library (เช่นไฟล์ JAR หรือ DLL) ส่วนหนึ่งของ bounded context ก็จะพังลง กล่าวอีกนัยหนึ่งคือ โค้ดที่ใช้ซ้ำถูกกระจายไปทั่วหลาย bounded context ซึ่งหมายความว่าไม่ใช่ฟังก์ชันการทำงาน ทั้งหมด ของฟังก์ชันหรือซับโดเมนนั้นอยู่ภายใน bounded context ของมันเอง และดังนั้นการเปลี่ยนแปลงโค้ดที่แชร์กันอาจทำให้ service ใน bounded context อื่นพังได้ แม้การทำ versioning จะช่วยแก้ปัญหานี้ได้บ้าง แต่การแชร์โค้ดก็ยังเพิ่มความซับซ้อนอย่างมาก ให้กับ microservices ecosystem