มีโอกาสได้แบ่งปันเรื่อง 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 ครับ
