ทำไมนำแนวคิด Microservices ไปใช้งานแล้ว กลับวุ่นวายหรือมีปัญหากว่าเดิม ?
ส่วนใหญ่มักพูดกันว่า
เมื่อเราทำงานแบ่งงานใหญ่ ๆ ออกเป็นงานเล็ก ๆ แล้ว
ผลที่ได้มันจะแจ่มมากเพราะว่า พัฒนาและจัดการได้ง่าย
และมักจะอธิบายในแง่ดีว่า
- ช่วยเพิ่ม productivity ของการพัฒนาให้ดีขึ้น
- Time to market เร็วมาก
- Scale ระบบได้เร็วมาก
- คุณภาพของระบบงานที่ดีขึ้น
- มีความยืดหยุ่นสูงทั้งเรื่องของคนและเทคโนโลยี
นั่นคือคำที่เอาไว้ขายซึ่ง มันอาจจะไม่ถูกมากสักเท่าไร
เพราะว่าการแยกเป็นงานเล็ก ๆ มันมีต้นทุนหลาย ๆ อย่าง
ที่จำเป็นต้องแก้ไขและปรับปรุงให้ดีขึ้น
มิเช่นนั้นแทนที่จะมีประโยชน์กลับมีโทษ !!
ยกตัวอย่างเช่น
โครงสร้างขององค์กรและทีม
บ่อยครั้งพบว่าในทีมที่เรียกว่า Microservices team นั้น จะมีแต่นักพัฒนาเท่านั้น
เมื่อเห็นก็จะงง ๆ ว่า มันต่างจากเดิมอย่างไร
คำตอบคือ ก็ Microservices team ไงละ
พัฒนาอย่างเดียว
ออกความคิดเห็นไม่ได้
ทำตาม timeline ที่กำหนด
เมื่อพัฒนาเสร็จ จะส่งให้อีกทีม deploy และจัดการต่อไป !!
แต่เมื่อมีปัญหาก็ส่งกลับมาให้ทีม
ดังนั้น สิ่งแรกที่ต้องทำการปรับเปลี่ยนก่อนคือ
โครงสร้างของการทำงานขององค์กร
จากเดิมที่ต่างฝ่ายต่างทำงานของตนเองไป
จำเป็นต้องมีการทำงานร่วมกันตั้งแต่
คุย ออกแบบ วิเคราะห์ พัฒนา ทดสอบ deploy และดูแล
การจัดการ dependency ที่เกี่ยวข้อง
ปัญหาที่เจอบ่อยมาก ๆ คือ การจัดการ dependency หรือสิ่งที่ service หนึ่ง ๆ ต้องใช้งาน
ทั้ง internal และ external system
บ่อยครั้งพบว่า ไม่สามารถควบคุมและจัดการได้เลย
สามวันดีสี่วันไข้
หนักกว่านั้นก็ต้องรอให้ระบบที่เราต้องใช้งานเสร็จก่อน
มันทำให้สูญเสียเรื่องความเป็นอิสระของ Microservices ไปอย่างมาก
ไหนจะยากต่อการพัฒนา ทดสอบและ deploy
ส่งผลให้แทนที่จะได้ประโยชน์กลับเกิดโทษมากกว่า
ดังนั้นจำเป็นต้องมีแนวทางและเครื่องมือในการจัดการ dependecy ที่ดี
ยกตัวอย่างเช่น พวกเครื่องมือจัดการ container เช่น Docker และ Kubernetes เป็นต้น มาช่วยจัดการ
- security
- networking
- storage
- monitoring
- complexity
ดังนั้นทีม infrastructure, network หรือ operation team จะต้องแข็งแกร่ง
และทำงานร่วมกัน development team ได้อย่างดี
แต่ถ้าไม่ส่งเสริมกันก็อาจจะก่อให้เกิดปัญหาใหญ่ตามมาได้
การจัดการเรื่อง communication ระหว่าง services
เนื่องจากเราทำงานแบ่งเป็น service ย่อย ๆ แล้ว
แต่ละ service อาจต้องติดต่อสื่อสารกัน
คำถามที่น่าสนใจคือ การติดต่อสื่อสารจะเป็นอย่างไร
ทั้ง Synchronous และ Asyschonous
เพราะว่าทั้งสองแบบก็มีข้อดีและข้อเสียต่างกันไป
เช่นถ้าเป็นแบบ synchronous แล้วเกิดปัญหาที่ระบบ network ก็ต้องรอกันไป
ส่งผลให้ประสิทธิภาพแย่ลงไปอีก
หรือถ้าเป็น asyschonous ก็จะเป็นต้องมีคนกลางหรือ message system
แน่นอนว่าประสิทธิภาพดีขึ้น แต่ส่งผลให้ระบบมีความซับซ้อนขึ้นมาอีก
หนักว่านั้น ถ้าแต่ละ service มันมีปัญหาหรือพังขึ้นมา
จะทำการจัดการแก้ไขอย่างไร หรือรู้จุดที่เกิดปัญหาได้รวดเร็วอย่างไร
บางครั้งเราจะใช้ค่า MTTR (Mean Time To Recovery) มาใช้วัดผลอีกด้วย
การจัดการกับความหลายหลาย
เนื่องจากประโยชน์หนึ่งของ Microservices คือ
การเลือกเครื่องมือให้เหมาะสมกับงาน
ดังนั้นอาจจะส่งผลให้มี technology ที่หลากหลายขึ้นมา
แน่นอนว่า มันทำให้เกิดปัญหาในการดูแลจัดการ ทั้ง
- Programming language
- Database
- APIs
- Configuration
- Operating system
คำถามที่ต้องตอบให้ได้คือ
เราจำเป็นต้องนำแนวคิด Microservices มาใช้จริง ๆ ไหม ?
หรือเพียงตามกระแสนิยม ว่าถ้าไม่ทำจะตก trend เท่านั้นเอง !!
หรือถ้าระบบไม่ใหญ่ก็เริ่มจาก Monolithic ไปก่อน
แต่แยกให้เป็น modular ที่ดี
จากนั้นถ้าใหญ่ขึ้นจึงค่อยแยกออกไปเป็น service ต่อไป
แต่ถ้าเป็นระบบขนาดใหญ่มันก็คือ
หนึ่งในความท้ายทายอย่างมาก
แต่ขอให้เริ่มต้นจากปัญหาก่อนเสมอ