จากการแบ่งปันเรื่องของ Microservices และ Software architecture นั้น
มีคำถามเกี่ยวกับการ shared code ระหว่างระบบงาน
ว่าเราควรจัดการอย่างไรบ้าง
จึงทำการสรุปแนวทางที่แนะนำไว้นิดหน่อย ดังนี้
เรื่องการ shared code นั้นเกิดมาจากส่วนการทำงานที่เหมือนกัน
จึงมักจะนำมาไว้ตรงกลาง เพื่อให้สามารถใช้งานร่วมกันได้
รูปแบบการ shared code เป็นดังนี้
รูปแบบที่ 1 ทำการ copy ไปใช้งานจากต้นฉบับเลย (copy-and-paste)
ตัวอย่างเช่นการ copy จาก project หนึ่งไปยัง project หนึ่ง
หรือจาก service หนึ่งไปยัง service หนึ่ง นั่นเอง
สามารถใช้งานได้ปกติ
แต่ถ้า code ชุดนั้นมีการเปลี่ยนแปลง ต้องตามไปเปลี่ยนแปลงหรือไม่
ถ้าใช้ต้องเปลี่ยนหมดเลย มันสร้างความยุ่งยากและวุ่นวายหรือไม่
แต่ถ้าการเปลี่ยนแปลงของแต่ละที่ที่ copy code ไป
มันไม่เกี่ยวข้องกัน วิธีนี้ก็น่าสนใจมาก ๆ นะ
รูปแบบที่ 2 สร้างเป็น library ไว้ตรงกลาง (shared library)
อาจจะเริ่มจากพวก common/util ที่ใช้งานใน project/service เดียวกันก่อน
แต่เมื่อเริ่มใช้ซ้ำ ๆ หรือ เหมือนกันในหลาย project/service แล้ว
และเมื่อเปลี่ยนแปลง จะต้องเปลี่ยนแปลงในทุก ๆ ที่ที่ใช้งาน
ก็ให้นำออกมาสร้างเป็น shared library กันต่อไป
แล้วนำมาไว้ตรงกลางที่เป็น standard ของการจัดการในแต่ละภาษาโปรแกรม เช่น
- สำหรับภาษา Java สร้างเป็น JAR file หรือนำไป publish ขึ้น Maven/Gradle repository server (internal/public)
- สำหรับ JavaScript เก็บไว้ใน NPM package
- สำหรับ Python เก็บไว้ใน pip
การใช้งานแบบนี้จะผูกมัดกับระบบงานนั้น ๆ มาก
ดังนั้นควรจัดการเรื่องของ versioning ให้ดี
รวมทั้งการทดสอบใช้ครอบคลุม มิเช่นนั้นแล้ว ผลกระทบจากการเปลี่ยนแปลงจะเยอะมาก ๆ
ยิ่งมีการใช้งาน shared library เยอะ ๆ
ยิ่งต้องระมัดระวังเรื่องขนาดของ project ที่จะใหญ่ขึ้นอีกด้วย
ใช้ได้กับระบบงานที่พัฒนาด้วยภาษาโปรแกรมเดียวกันเท่านั้น
รูปแบบที่ 3 แยกออกมาเป็น service กันเลย (Shared service)
สร้างเป็น service ใหม่ แยกออกมาเป็นอีก process เป็นอิสระต่อระบบงานอื่น ๆ
ช่วยให้ระบบงานต่าง ๆ สามารถใช้งานได้
โดยไม่ต้องพัฒนาด้วยภาษาโปรแกรมเดียวกัน
ลดค่าใช้จ่าย ๆ และการดูแลตามที่ฝั่งคนคิดพูดให้ทาง management ฟัง !!
แต่ต้องระวังเรื่องปัญหาต่าง ๆ ของ shared service เช่นกัน
ยกตัวอย่างเช่น
- performace การใช้งาน เพราะว่าเรียกผ่านระบบ network ไม่ใช้ process เดียวกันแล้ว ดังนั้น overhead จะสูง
- side effect จากการเปลี่ยนแปลง shared service ดังนั้น กระบวนการพัฒนา ทดสอบ และ deploy มีความสำคัญมาก ๆ ต้องมั่นใจว่า การเปลี่ยนแปลงไม่กระทบต่อผู้ใช้งานทุกคนด้วยเสมอ
- ปัญหาของการ scale เนื่องจากใช้งานจาก service มากมาย
- ที่สำคัญมาก ๆ อย่าให้ shared service เป็นมะเร็ง service คือ นำเอา logic ของผู้ใช้งานมาใส่ใน shared service จะสูญเสียความเป็นอิสระไป มันจะเป็นปัญหาแบบตายผ่อนส่ง ไม่เจอในช่วงแรก ๆ นะครับ
เป็น 3 รูปแบบที่แนะนำไว้
ซึ่งมีอีกหลายรูปแบบที่เกิดขึ้นมา เช่นใช้งาน sidecar เป็นต้น
ลองนำไปประยุกต์ใช้งานดูครับ
ว่ารูปแบบไหนที่เหมาะสมในแต่ละ use case ของเรา