หนึ่งในเรื่องที่น่าสนใจจากหนังสือ Monolith to Microservices
(Evolutionary patterns to transform your monolith)
อธิบายว่า เมื่อจำนวน service ของระบบเพิ่มมากขึ้นแล้ว
ปัญหาที่ต้องพบเจอก็มากและแตกต่างกันไป
เช่นปัญหาของ service ที่ไม่เกิน 10 service
จะแตกต่างจาก 50 หรือ 100 service
ดังนั้นสิ่งที่เราควรต้องรู้แล้วเข้าใจคือ
จะรับมือหรือแก้ไขปัญหาเหล่านั้นกันอย่างไร ?
ในหนังสือยกตัวอย่างให้เข้าใจง่าย
ด้วยการแบ่งปัญหาตามจำนวนของ service ดังนี้
- Breaking change
- Reporting
- Ownership at scale
- Developer experience
- Running to many things
- Global vs. Local optimisation
- Orphaned services
แสดงดังรูป
ปัญหาแรกที่มักเจอคือ เรื่อง Ownership at scale
หรือความเป็นเจ้าของ service ต่าง ๆ นั่นเอง
เมื่อมีจำนวน service มาก ๆ ขึ้นมา
คำถามคือ ใครละเป็นเจ้าของ เป็นเจ้าภาพ เป็นคนดูแล service แต่ละตัว ?
จากบทความเรื่อง Code ownership นั้นของคุณ Martin Fowler
ได้แบ่งไว้ 3 กลุ่ม ในมุมมองของ service นั้น
มองในแง่ของการเปลี่ยนแปลง มากกว่าที่จะมองในแง่ของการ deploy
รวมไปถึงการ support ต่าง ๆ เป็นดังนี้
กลุ่มที่ 1 Strong code ownership
แต่ละ service มีเจ้าของชัดเจน
ดังนั้นถ้าใครก็ตามที่อยู่นอกกลุ่ม ต้องการเปลี่ยนแปลง
ต้องส่งการเปลี่ยนแปลงนั้นมาที่เจ้าของ
หรืออาจจะอยู่ในรูปแบบของ pull request
เพื่อให้เจ้าของพิจารณาว่าจะอนุญาตหรือไม่
กลุ่มที่ 2 Weak code ownership
ไม่แน่ชัดว่าใครเป็นเจ้าของ service
แต่ทุก ๆ คนสามารถทำการเปลี่ยนแปลงโดยตรงได้เลย
แต่ก่อนจะแก้ไข ควรหาก่อนว่าใครกันแน่ที่เป็นเจ้าของ
เพื่อพูดคุยว่าจะเปลี่ยนนะ
กลุ่มที่ 3 Collective ownership
กลุ่มนี้ไม่มีใครเป็นเจ้าของ service เลย
และทุก ๆ คนสามารถทำการแก้ไขได้ตามที่ต้องการ
ในหนังสืออธิบายปัญหาที่เกิดจาก Collective ownership
ตอนเริ่มต้นนั้นมีจำนวนทีมและจำนวน service ไม่เยอะ
ดังนั้นจึงมีแนวคิดการทำงานแบบ collective ownership
เพื่อทำให้การทำงานคล่องตัว
และทุกคนเข้าใจในภาพรวมทั้งหมดของระบบ
แต่เมื่อจำนวน service และขนาดของทีมเพิ่มขึ้น
ยกตัวอย่างเช่นจำนวนคนในทีมมีประมาณ 30-100 คน
แนวคิดการทำงานแบบ collective ownership นั้นจึงเกิดปัญหา !!
เนื่องจากไม่มีการแบ่งหน้าที่ความรับผิดชอบที่ชัดเจน
ว่าใครทำอะไร ส่วนไหนบ้าง
และทำให้แนวคิดและแนวทางของ architecture ของระบบไม่ชัดเจน
ว่าจะโตไปทางไหน
ก่อให้เกิดปัญหาตามมา ยกตัวอย่างเช่น ระบบแบบ Distributed monolith !!
การแก้ไขปัญหาในกรณีนี้คือ
เริ่มมีการตั้งกฏกติการในการทำงานขึ้นมา
ซึ่งเป็นช่วงเวลาที่เหมาะสมอย่างมากในการจัดการ
ว่าแต่ละทีมจะดูแล service อะไรบ้าง
มันเป็นการแยกให้เป็น local collective ownership
หรือบ่อยครั้งก็แยกไปตาม business domain ได้เลย
ทำให้แต่ละทีมสามารถ focus ไปเพียง business domain นั้น ๆ ได้เลย
ลองดูสิว่า โครงสร้างของทีมและองค์กรของเราเป็นอย่างไร
แล้วมีปัญหาในรูปแบบใดบ้าง
จากนั้นทำการแก้ไขหรือไม่
หรือ มันกลายเป็นข้อจำกัดไปแล้ว
ถ้ามีปัญหาแล้วไม่แก้ไข
จะใช้อะไรมันก็มีปัญหาเช่นเดิม หรือ หนักกว่าเดิมก็เป็นไปได้
