สรุป 6 เรื่องน่าคิดสำหรับ Microservices

มีโอกาสได้แบ่งปันเรื่อง Microservices มากขึ้น ทำให้เห็นมุมมองต่าง ๆ มากขึ้นเช่นกัน หนึ่งในนั้นคือ 6 เรื่องน่าคิดสำหรับ Microservices ซึ่งทาง Pivotal เขียนสรุปไว้ มันน่าสนใจมาก ๆ จึงนำมาสรุปไว้นิดหน่อย น่าจะพอมีประโยชน์บ้างสำหรับการตัดสินใจต่าง ๆ มาเริ่มกันเลย

เรื่องที่ 1 Multiple rate of change

คำถามแรกที่ต้องตอบให้ได้ก่อน ในแต่ละส่วนของระบบนั้นมีการเปลี่ยนแปลงอย่างไร ช้า เร็ว บ่อยเพียงใด ? แต่ละส่วนการทำงานมีทิศทางหรือเป้าหมายอย่างไรบ้าง ? เป็นคำถามที่ช่วยเหลือให้เราสามารถแบ่งส่วนการทำงานออกจากกัน ในแต่ละส่วนการทำงานเราจะเรียกว่า Microservices ซึ่งแต่ละ service จะมี lifecycle ต่างและเป็นอิสระแก่กัน ยกตัวอย่างระบบ e-commerce ซึ่งเป็นระบบ monolith เป็นดังนี้ จากคำถามข้างต้น อาจจะตอบได้ดังนี้

• ระบบ Cart, Inventory, Order และ Account ไม่เปลี่ยนบ่อยนะ
• ระบบ Recommendation นั่นอยู่ในช่วงการทดลอง ดังนั้นเปลี่ยนบ่อยมาก ๆ
• ระบบ Search ต้องปรับปรุงระบบอยู่เป็นประจำ

ดังนั้นเราสามารถแบ่งส่วนการทำงานออกเป็น 2 ส่วน ซึ่งส่งมอบคุณค่าทาง business สูงมาก รวมทั้งช่วยให้ทีมพัฒนาพัฒนาได้ง่าย และ ส่งมอบได้บ่อยขึ้นอีกด้วย แสดงดังรูป

เรื่องที่ 2 Independent Lifecycle

แต่ละส่วนการทำงานเป็นอิสระแก่กันนั่นหมายความว่า มี repository สำหรับจัดการ source code แยกออกไป มี CI/CD process แยกออกไป มีการทดสอบแยกออกไป ผลที่ตามมาคือ ขนาดหรือการทำงานของ service หรือส่วนการทำงานนั้นจะน้อยและเล็ก ดังนั้นเวลาในการทดสอบก็จะน้อยลงไป ถ้า service คุณใช้เวลาการทดสอบนาน แสดงว่ามาผิดทางแน่นอน แต่การทดสอบไม่ใช่เหตุผลหลักในแยก service ออกมา แต่สิ่งที่ต้องอให้ความสนใจคือ business value ยกตัวอย่างเช่น ถ้า business ต้องการเพิ่มความสามารถใหม่เข้าไปยังระบบเดิม แต่ business ต้องการทดลองตลาดให้เร็วที่สุด แต่ทางฝั่ง technical/development ตกลับต้องใช้เวลานาน ในการเพิ่มความสามารถใหม่เข้าไปยังระบบเดิม หรือ Monilith พูดตรง ๆ คือไม่ทันกิน ดังนั้นสิ่งที่น่าลองทำคือ ในส่วนของ feature ใหม่ สามารถแยกออกไปเป็น service ใหม่ ที่มีสิ่งต่าง ๆ เป็นของตัวเอง น่าจะทำให้เรียนรู้ได้เร็ว น่าจะทำให้พัฒนาได้เร็ว ถ้าผลการใช้งานพบว่า ไม่เป็นไปตามที่ business คาดคิด ก็สามารถลบทิ้งไปหรือโยนทิ้งไปได้ง่าย ๆ เลย แสดงดังรูป

เรื่องที่ 3 Independent Scalability

เมื่อส่วนการทำงานต่าง ๆ มันมีรูปแบบการใช้งานที่แตกต่างกัน นั่นหมายความว่า มีการ scale หรือการขยายเพื่อรองรับการใช้งานต่างกัน ดังนั้นควรแยกส่วนการทำงานต่าง ๆ ออกจากกันใช่ไหม ? มิเช่นนั้น ถ้ามีเพียงส่วนเดียวที่ต้อง scale เราจำเป็นต้อง scale ทุก ๆ ส่วนไปพร้อมกัน เพราะว่า มันอยู่ในระบบเดียวกัน !! ดังนั้นแยกเถอะนะ

ปล. ต้องมีระบบ monitoring ที่ดีก่อนด้วยนะ จึงจะรู้ว่าส่วนการทำงานไหน มันถูกใช้เยอะ

ยกตัวอย่างเช่น ระบบ Order processing มีผู้ใช้งานมาสั่งซื้อจำนวนมาก ๆ ส่งผลให้ต้องทำการ scale ส่วนการทำงานนี้ ดังนั้นก็แยกออกมาจะง่ายกว่านะ แต่เมื่อเจองานจริง ๆ มันไม่ง่ายแบบที่คิดนะครับ แต่ต้องทำ !!

เรื่องที่ 4 Isolated Failure

ว่าด้วยเรื่องของการทำงานที่ผิดพลาด และ ระบบล่ม ยกตัวอย่างเช่น ถ้ามีส่วนการทำงานที่ใช้งานเกิดข้อผิดพลาดหรือล่ม เราจะจัดการหรือรับมืออย่างไร ? ยกตัวอย่างเช่นการทำงานในส่วนของระบบ Inventory ซึ่งต้องทำงานร่วมกับ Legacy system เช่นระบบ Warehouse ที่เก่า ๆ แน่นอนว่า ระบบนี้อาจจะล่มหรือมีปัญหาบ่อยมาก ๆ (ระบบ monitoring จะบอกเองนะ) ดังนั้นเราสามารถแยกส่วนการทำงานนี้ออกมาเป็น service ใหม่ เพื่อให้ดูแลรักษาง่ายขึ้น ทั้งการทำ redundancy ทั้งการทำ caching

เรื่องที่ 5 ต้องไม่ยึดติดกับ External service/dependency

บ่อยครั้งที่แต่ละ service ต้องทำงานกับ External service/dependency สิ่งที่ควรทำคือ อย่าเรียกใช้งาน service/dependency เหล่านั้นโดยตรง เนื่องจากมันเปลี่ยนแปลงบ่อย เนื่องจากเกิดความผิดพลาดบ่อย ดังนั้นสิ่งที่ควรทำคือ สร้าง layer หรือ abstraction layer ขึ้นมา เพื่อให้ service เรียกใช้งานได้ง่ายขึ้น และยังซ่อนความซับซ้อนต่าง ๆ อีกด้วย และถ้ามีการเปลี่ยนแปลงก็ทำเฉพาะส่วนที่ซ่อนไว้ โดยไม่กระทบต่อผู้ใช้งาน หรือ ให้กระทบน้อยที่สุด

เรื่องที่ 6 Choose the Tech for the Job

เมื่อแยกส่วนการทำงานออกมาได้แล้ว จะช่วยทำให้สามารถเลือกใช้เทคโนโลยี framework และเครื่องมือต่าง ๆ ที่เหมาะสม มิเช่นนั้น เราจะใช้แต่สิ่งเดิม ๆ เพื่อแก้ไขงานทุกอย่าง !! แต่ใช้เยอะ ๆ มันก็ดูแลยากนะ ดังนั้นสิ่งที่เลือกต้องสามารถดูแลรักษาต่อไปได้ด้วย

สุดท้ายเรื่องที่สำคัญมาก ๆ คือ วัฒนธรรมขององค์กร (Culture)

โครงสร้างขององค์กรที่เป็นอยู่ มันเอื้อต่อแนวทางของ Microservices หรือไม่ ? Microservices ว่าด้วยเรื่องการทำงานี่เล็ก คล่องตัว และเปลี่ยนบ่อย ๆ ซึ่งจะไม่มีคำว่า freeze code, big bang, merge code/integrate code !!

ยิ่งถ้านำแนวคิด Microservices มาใช้กับรูปแบบการพัฒนาแบบ Waterfall แล้ว จะยิ่งไม่เห็นผลประโยชน์ใด ๆ จาก Microservies เลย

ยกตัวอย่างเช่นการ Provisioning infrastructure ของระบบงาน ทีมสามารถทำการสร้างหรือเลือกสิ่งที่ต้องการด้วยตัวเอง ซึ่งทำให้ง่ายต่อการพัฒนา ทดสอบ และ deploy มันง่ายและปลอดภัยต่อการทดลองและเรียนรู้สิ่งใหม่ ๆ

ลองคิดดูสิว่า ถ้าการ Provisioning infrastructure ใช้เวลาเป็นสัปดาห์ เป็นเดือน คิดว่าแนวคิด Microservices จะมีประโยชน์อะไร ?

สิ่งที่ควรให้ความสนใจกว่า Microservices คือ

สิ่งที่ทำไปนั้นมีประโยชน์ต่อ business อย่างไร สิ่งที่ทำไปนั้นมีประโยชน์ต่อ technical หรือทีมพัฒนาอย่างไร ? (Delivery team) ถ้าไม่มีประโยชน์อะไรเลย ก็อย่าไปทำ เสียเวลา เสียเงินโดยเปล่าประโยชน์ ขอให้สนุกกับการ coding ครับ