สรุปเรื่อง Microservices Anti-Patterns

จากเอกสารแบ่งเป็น 2 กลุ่มใหญ่ ๆ คือ

• Technical
• Organization

กลุ่มแรก Technical ประกอบไปด้วย

การทำงานภายในของแต่ละ service ที่จะมีปัญหา เช่น

• API versioning
• Hard code สิ่งต่าง ๆ ใน code เช่น endpoint, ip และ port เป็นต้น
• Service ใหญ่เกินไป
• การจัดการ logging
• แบ่ง service ผิด
• ขาดระบบ monitoring ที่ดี ตรงนี้น่าจะเรื่องของ Observability
• การ share ที่จัดเก็บข้อมูล
• การ share library ต่าง ๆ
• ออกแบบ endpoint แบบทำได้ทุกอย่าง ไม่ยอมออกแบบให้ทำงานแบบเฉพาะเจาะจง

ในเรื่องของการติดต่อสื่อสารระหว่าง service ก็เยอะเลย

• ที่เจอบ่อย ๆ เช่นกันคือ Cyclic dependecy คือการเรียกวนไปมา เกิดสปาเกตตี้ระดับ service ได้ง่าย
• มีการใช้ ESB (Enterprise Service Bus) เพื่อ share ข้อมูลและติดต่อกัน ซึ่งเป็นมาตั้งแต่ SOA แล้ว !!
• ไม่ใช้ API gateway
• เรื่องของ timeout น่าจะเป็นเรื่องของพวก resilience pattern นั่นเอง ตัวที่ได้รับความนิยมคือ circuit breaker
• มี protocol ในการติดต่อสื่อสารมากจนเกินไป
• ขาดความรู้และเครื่องมือที่เหมาะสม
• ใช้เทคโนโลยีที่ใหม่เกินไป หรือ ยังขาดความรู้ความเข้าใจต่อสิ่งนั้น ๆ เห็นเขาว่าดีก็เลยนำมาใช้

กลุ่มสอง Organization ประกอบไปด้วย

แนวคิด Microservice นั้น ไม่ใช่เพียงเรื่องของ architecture เท่านั้น แต่ยังเกี่ยวข้องกับองค์กรอีกด้วย ถ้าองค์กรไม่ปรับก็จะยิ่งส่งผลเสียเช่นกัน มาดูว่า pattern อะไรบ้างที่ทำให้เกิดปัญหา

• ยังคงใช้โครงสร้างเดิม ๆ ที่ก่อให้เกิดปัญหา แต่ก็ยังทำแบบเดิมเพียงแต่เอา Microservice มาใช้ ผลที่ได้อาจจะแย่กว่าเดิมไปอีก อยากแก้ไขปัญหา แต่ยังใช้ process เดิม ๆ ที่ก่อให้เกิดปัญหาก่อนหน้านี้
• เรื่องของ Ownership ส่วนใหญ่จะเป็นแบบ strong ownership คือ ดูแลของใครของมัน ไม่สนใจภาพรวมของ product
• เป้าหมายคือ Microservice แทนที่ควรจะเน้นที่การแก้ไขหรือปรับปรุงระบบให้ดีขึ้นมากกว่า
• คิดว่า Microservice จะแก้ไขปัญหาทุกอย่าง ซึ่งผิดมาก ๆ
• รีบทำจนเกินไป เทียบได้กับ ยังเดินไม่ได้ แต่อยากจะบินแล้ว
• ขาดการทดสอบที่ดี หรือสภาวะแวดล้อมของการทดสอบไม่น่าเชื่อถือ
• ทีมหนึ่ง ๆ ดูแล service จำนวนมาก

น่าจะเป็นประโยชน์ต่อการนำไปใช้งานต่อไป