เรื่องของ Microservices นั้น ไปที่ไหนก็มีแต่คนพูดถึง
หรือบางครั้งมันกลายเป็นแนวทางหลักของระบบต่าง ๆ ไปแล้ว
แต่บ่อยครั้งจะพบว่า
เราเน้นไปเรื่องว่าจะทำ อย่างไร ก่อนปัญหาที่เราต้องการแก้ไข
มันอาจจะทำให้เกิดปัญหามากมายตามมา
จากบทความ 5 Key Takeaways From My Experience with Microservices
ทำการสรุปจากประสบการณ์การนำแนวคิด Microservices มาใช้งาน
ว่ามันมีข้อดีข้อเสีย ข้อระมัดระวังรวมทั้งความเข้าใจ
จึงทำการสรุปไว้นิดหน่อย น่าจะพอมีประโยชน์บ้าง
เรื่องที่ 1 ทำการสร้างและพัฒนา Product ไม่ใช่ Project
น่าจะได้ยินเรื่องนี้บ่อยมาก ๆ แต่กลับทำได้ยาก
เพราะว่า เรามักจะมองเป็น project
คือมีขอบเขตชัดเจน แถมมีกรอบเวลาชัดเจนอีก
เหมือนทำให้มันจบ ๆ ไปทีละ project ไร้ความต่อเนื่อง
แต่ระบบงานส่วนใหญ่จะเป็นแบบ product มากกว่า
คือทำการพัฒนาและเพิ่มความสามารถไปเรื่อย ๆ ต้องดูแลแบบยาวนาน
แต่เมื่อเวลาผ่านไป กลับทำให้แต่ละ product นั้น
พัฒนายาก ดูแลยาก เกิดการพูดคุยข้าม service/system เยอะมาก ๆ
เนื่องจากความรู้ของระบบงานกระจายตามแต่ละส่วนงาน
นี่คือปัญหาหรือ overhead ของการพัฒนาหรือไม่ ?
หลาย ๆ ที่ก็บอกว่า เราจะแก้ไขปัญหานี้ด้วย Microservices
แต่ผลที่ได้กลับมาคือ แย่ไปกว่าเดิม
เพราะว่าคนทำก็ยังคิดหรือทำแบบเดิม เปลี่ยนไปแค่ชื่อ !!
- ทั้งการออกแบบเผื่อมาก ๆ
- ขั้นตอนการทำงานที่เทอะทะ ทำงานแบบ centralize
- กระบวนการ build -> test -> deploy แบบ manual
สิ่งที่ควรปรับเปลี่ยนคือ Project -> Product
นั่นคือใน product หนึ่ง ๆ นั้น คนที่เกี่ยวข้อง
ทั้ง business, development, operation ต้องมีเป้าหมายร่วมกัน เข้าใจร่วมกัน
ไม่ใช่ต่างฝ่ายต่างมีเป้าหมายที่ต่างกัน
ทำให้มีความสัมพันธ์ที่ดีต่อกัน
ผลที่ได้คือ ได้ product ที่ดีต่อผู้ใช้งานหรือลูกค้า
ยิ่งเป็นแนวทาง Microservices คือ การแบ่งออกเป็น service เล็ก ๆ
ซึ่งแต่ละ service นั้นมีการทำงานที่เป็นอิสระ หรือไม่ยืมจมูกคนอื่นหายใจ
ตั้งแต่การจัดการ requirement, design, develop, testing, deploy และดูแลรักษา
เพื่อให้การทำงานของแต่ละ service เป็นไปอย่างคล่องตัว
คำถามคือ เราจะทำการปรับเปลี่ยนหรือไม่ ? หรือเพียงแค่เปลี่ยนชื่อเท่านั้นเอง ?
เรื่องที่ 2 แยก services แล้วชีวิตต้องดีขึ้น
การแยก ยุบรวม หรือแบ่ง service ในระบบนั้นเป็นสิ่งที่สำคัญมาก ๆ
การจะบอกว่าแยกอย่างไรให้ถูกต้อง
มันเป็นคำถามที่ตอบได้ยากมาก ๆ
เนื่องจากในแต่ละที่ล้วนแตกต่างกัน
ดังนั้นก่อนแยก services ควรเข้าใจการทำงานแบบ end-to-end ก่อนว่าเป็นอย่างไร
เพื่อทำให้เข้าใจภาพรวม ทั้ง business flow, operation flow
แต่เมื่อแยกแล้ว กลับทำให้ระบบแย่ลง
การพัฒนาแย่ลง การทดสอบแย่ลง
การ deploy แย่ลง
การแก้ไขแย่ลง
อาจจะต้องกลับมายังจุดเริ่มต้นว่า
เราพร้อมหรือยัง
มีอะไรต้องแก้ไขปรับปรุงก่อนไหม
การทำงานร่วมกันของคนในองค์กรเป็นอย่างไร
เพราะว่ามันไม่ใช่แค่เรื่องของ architecture ของระบบ
แต่มันคือโครงสร้างขององค์กรกันเลยทีเดียว
เรื่องที่ 3 อย่าลืมว่าเราแก้ไขปัญหาอะไร เพื่ออะไร
การเปลี่ยนแปลงนั้น มันต้องดูผลในระยะยาว
อย่าลืมว่า ทำการแยกเพราะว่าอะไร ?
นั่นคือเรามีปัญหาอะไร ต้องเข้าใจ
ยกตัวอย่างเช่น
ต้องการแยกเพราะว่า ต้องการให้การทำงาน A สามารถรองรับผู้ใช้งานได้เยอะ
ก็ต้องเน้นไปที่เรื่องของการ scale เฉพาะในระบบ A
โดยที่ต้องไม่ไปกระทบส่วนอื่น ๆ ด้วย
ดังนั้นทั้งการพัฒนา, operation, infrastructure ต้องสนับสนุนด้วยเสมอ
รวมทั้งมันคือ การทำงานแบบเป็นทีมและทำงานร่วมกันยาวนาน
ดังนั้นจำเป็นต้องมีรูปแบบของการทำงานร่วมกัน
ทั้งรูปแบบการพูดคุย
ทั้งรูปบบการพัฒนา
ทั้งรูปแบบการจัดการ version ต่าง ๆ
ทั้งรูปแบบของการทำงานแบบอัตโนมัติ
ทั้งรูปแบบการจัดการปัญหาต่าง ๆ
การเตรียมพร้อมก่อนจะเริ่มจึงสำคัญมาก ๆ
แถมใช้เวลาและทรัพยากรต่าง ๆ ในการเตรียมเยอะ
การจะพลิกจากหน้ามือเป็นหลังมือ ภายในเวลาอันสั้นเป็นเรื่องยากมาก ๆ
ดังนั้นจึงจำเป็นต้องทำแบบค่อยเป็นค่อยไป
เริ่มง่าย ๆ จากปัญหาที่มี จากนั้นก็ค่อย ๆ แก้ไขทีละปัญหาไป
ถ้าแยกแล้วมีปัญหามากมายตามมาแล้ว
นั่นหมายความว่า เราทำผิดนั่นเอง
ประเด็นคือ เรารู้ว่าผิดได้รวดเร็วเพียงใด รวมทั้งแก้ไขได้เร็วไหม
ดังนั้นแนวคิดนี้ มันไม่ใช่สำหรับการแก้ไขในทุก ๆ ปัญหานะครับ
เลือกวิธีการให้เหมาะกับปัญหา
ถ้าไม่มีปัญหาก็ไม่ต้องไปสร้างปัญหา
เพียงแค่คนอื่นเขาทำ แต่เราไม่จำเป็นต้องทำก็ได้ !!
รู้และเข้าใจความต้องการของระบบ มิใช่ความต้องการของเรา
