สาย ๆ นั่งอ่านบทความเกี่ยวกับ Anti-pattern สำหรับ Microservices
ซึ่งแนวคิด Microservices นั้นมันไม่ใช่วิธีแก้ไขปัญหาทั้งหมด
สิ่งที่ต้องเข้าใจก่อนคือ เรามีปัญหาอะไรบ้าง
จากนั้นจึงหาวิธีการแก้ไข วัดผลและปรับปรุงหรือเรียนรู้จากผลที่ตามมา
แนวคิดต่าง ๆ ล้วนมีข้อดีและข้อเสีย
ถ้านำไปใช้แบบไม่เข้าใจ แน่นอนว่า Microservices ก็เช่นกัน
จากบทความข้างต้น อธิบายไว้ 3 เรื่องคือ
- แบ่งเป็น service เล็กมาก ๆ แทนที่จะดีขึ้นกลับแย่ลง
- แบ่งเป็น service ย่อย ๆ แต่เรื่องของ data กลับไปแยก
- เกิดระบบที่เรียกว่า Frankenstein
มาดูรายละเอียดกัน
แบ่งเป็น service เล็กมาก ๆ แทนที่จะดีขึ้นกลับแย่ลง
จากระบบเดิมที่ใหญ่หรือ monolith ที่รวมทุกอย่างไว้ที่เดียว
ทำการให้การ deploy ระบบงานก็ช้า พร้อมความเสี่ยงที่สูง
การดูแลรักษาที่ยาก
ปัญหาเรื่อง performance ของระบบงาน
ที่สำคัญปรับปรุงได้ยากอีก
การทำงานร่วมกันของทีมยิ่งแย่มาก ๆ
การทดสอบไม่ต้องพูดถึง ยากสุด ๆ
ไหนจะการจัดเตรียมข้อมูลทดสอบ
ไหนจะชุดการทดสอบ
จะปรับให้มีการทำงานแบบอัตโนมัติก็เป็นไปได้ยาก
ยิ่งจะนำเทคโนโลยีใหม่ ๆ มาใช้ นี่ไม่ต้องคิดเลย
แต่พอได้ยินแนวคิด Microservices ว่ามันดีนะ
ทั้ง deploy ได้ง่าย
ทั้งทดสอบได้ง่าย
ทั้งดูแลง่าย
ทั้ง scale ได้ง่าย
เพราะว่าแยกการทำงานใหญ่ ๆ ออกเป็นการทำงานย่อย ๆ
ดังนั้นก็แยกกันไปแบบสุด ๆ เลย
ผลที่ได้แสดงดังรูป
ผลที่ตามมาจากการแยกเป็น service ย่อย ๆ
กลับไม่เป็นไปตามที่คิดที่ฝันคือ
มันกลายเป็นว่าแต่ละ service คือ Monolith เช่นเดิม !!
แถมทำให้การ deploy, testing และ ดูแลรักษายากและนานขึ้นอีก
หนักกว่านั้น
เปลี่ยนแปลงการทำงานของ service หนึ่ง
กลับส่งผลกระทบต่อภาพรวมของระบบ
แถมหาปัญหายากกว่าเดิมอีก
จะ scale service หนึ่ง ดันต้องไป scale service อื่น ๆ อีก
ปัญหาจัดการเรื่องของ transaction อีก
หา service ไม่เจออีก
ทำไมปัญหามันเยอะขนาดนี้ ?
ไหนใคร ๆ ก็บอกว่าแยกเป็น service เล็ก ๆ แล้วมันดีนะ
สงสัยแนวคิดนี้ไม่ดีแน่ ๆ !!
แบ่งเป็น service ย่อย ๆ ยกเว้น data กลับไม่แยก
สิ่งที่ชอบทำต่อการการแบ่ง service ที่ไม่ถูกต้อง หรือ ไม่เหมาะสม
ก็คือ การไม่แยก data ออกมาตามแต่ละ service
เพราะว่า การที่จะแยก data ออกมาตามแต่ละ service มันยากมาก ๆ ทั้ง
- แยก database ออกมาใน server เดียวกัน
- แยก database ตามแต่ละ server ไปเลย
แต่ปัญหาที่เจอคือ database ที่ใช้นั้น
มักจะมีเรื่องของ licence การจะแยกออกมานั่นหมายความว่า
ค่าใช้จ่ายสูงขึ้นอย่างมาก
ไหนจะเรื่องของการจัดการข้อมูล
รวมไปถึงระบบอื่น ๆ ที่ต้องใช้งาน data อีกด้วย
ถ้าต้องการใช้ data จากหลาย ๆ service จะทำอย่างไร ?
ดังนั้น เพื่อความง่ายก็ไม่ต้องแยกดีกว่า
ผลที่ตามมาคือ
ทุก service ยังคงใช้ database เดียวกัน
ถ้ามีการเปลี่ยนแปลง หรือ database มีปัญหา
ผลกระทบที่ตามมาคือ ทุก ๆ service ที่ใช้งานก็พังไปด้วยสิ
ซึ่งมันขัดแย้งกับแนวคิดของ microservices อย่างมาก
ที่แต่ละ service ต้องทำงานจบในตัวเอง ไม่ยืมจมูกคนอื่นหายใจ
แสดงดังรูป
เกิดระบบที่เรียกว่า Frankenstein
เป็นสิ่งที่ตามมาจากข้อที่ 1 และ 2 นั่นคือ
แยกเป็น service ย่อย ๆ แล้วก็มีทีมทำ
ที่สำคัญคือ แต่ละทีมก็ต่างทีมต่างทำไป
ไม่มีแผนงานที่มา sync กัน ไม่คุยกันมากพอ
แต่ละส่วนทำงานได้
บ่อยครั้งแต่ละ service ก็มีงานที่ซ้ำซ้อนกันอีก
หนักกว่านั้น ไม่รู้ว่าต้องมาทำงานร่วมกัน
เมื่อต้องทำงานร่วมกันก็จะปะผุไปเรื่อย ๆ
เหมือนกับ Frankenstein นั่นเอง
หวังว่าคงไม่มีใครทำแบบนี้นะ
มิเช่นนั้น
ผลที่ตามมามันจะยิ่งเลวร้ายกว่าเดิมไปอีก
ดังนั้นก่อนอื่นให้ทำความเข้าใจก่อนว่า
ปัญหาจริง ๆ คืออะไร
จากนั้นจึงคิดและหาวิธีการแก้ไข
ลงมือทำ และวัดผลเพื่อปรับปรุงต่อไป
