บันทึกการสอน และ แบ่งปันความรู้เรื่องของ Microservices ที่ Skooldio
ตั้งแต่การออกแบบ การพัฒนา การทดสอบ และ การ deploy
รวมไปถึงการ operate เรื่องต่าง ๆ เช่น monitoring และ observability
จำนวน 4 วัน โดยครั้งนี้เขาบอกว่าเป็นรุ่นที่ 13 แล้ว
จึงทำการสรุปการแบ่งปันไว้นิดหน่อย
เริ่มด้วย 2 วันแรก จะลงรายละเอียดของการออกแบบ
โดยเป้าหมายของ 2 วันนี้ คือ
- เพิ่มความรู้ความเข้าใจของปัญหาต่าง ๆ ที่พบเจอของระบบงาน
- ให้รู้และเข้าใจว่า ทำไม เราจึงมีแนวคิดต่าง ๆ ของการออกแบบระบบ รวมทั้งเรื่องของ software architecture
- แนวคิดต่าง ๆ ล้วนสร้างขึ้นมาเพื่อแก้ไขปัญหา
- แต่เมื่อเรานำมาใช้งาน ทำไมถึงสร้างปัญหา
- เราเข้าใจถึงที่มาที่ไปของแนวคิดนั้น ๆ หรือไม่
ดังนั้นจึงได้เริ่มสร้างความเข้าใจในแนวคิดต่าง ๆ เข้ามา ยกตัวอย่างเช่น
- DevOps, DevSecOps
- Continuous Integration และ Continuous Deployment/Delivery
- Software architecture เช่น Monolith, Modular, Layer, Tier, SOA, Microservices และ Function-as-aService
- Containerization
โดยสิ่งที่เน้นย้ำในการแบ่งปันครั้งนี้ คือ Software Architecture
ซึ่งล้วนมี trade-off ที่เราต้องพิจารณาเสมอ
เนื่องจากไม่ได้มีเพียงข้อดีเท่านั้น
มันยังมีข้อเสียที่เราต้องรู้และเข้าใจ รวมทั้งต้องเตรียมวิธีการรับมือเสมอ
บ่อยครั้งจะพบว่า เราแก้ไขปัญหา ด้วยการเพิ่มปัญหาใหม่ ๆ !!
กลับมาที่ Microservices นั้น จะแนะนำให้มอง 4 มุมเป็นอย่างน้อยเสมอ
ประกอบไปด้วย
- การสร้าง service จะเพิ่มเข้าไป หรือ แยกออกมา มีเหตุผลอะไร อย่างไร
- การออกแบบ interface หรือ การเข้าถึง service นั้น ๆ เป็นอย่างไร สนใจเรื่อง compatability และ ใช้งานง่ายหรือไม่
- การทดสอบ คิดไหมว่า จะทดสอบอย่างไร
- การ operate คิดหรือไม่ว่าจะดูแล จัดการอย่างไร deploy อย่างไร monitoring/observability เป็นอย่างไร ถ้าเกิดปัญหาต่าง ๆ จะจัดการอย่างไร หรือ ระบบสามารถ react ต่อปัญหาได้หรือไม่ อย่างไร
ยิ่งทำการแยกกันออกมา มีข้อดีหรือข้อเสียมากกว่ากัน
มีความเป็นอิสระหรือไม่ ในมุมมองต่าง ๆ ไม่ใช่เพียงแค่แยกกันพัฒนา แยกกันทำงาน
แต่ยังต้องมองเรื่องของ
- การติดต่อสื่อสาร เช่น แยกกันแล้ว แต่ต้องติดต่อสื่อสารกันเสมอ คำถามคือ แยกกันทำไม ตรงนี้ตอบได้ไหม
- การ deploy และ scale ต้องรอกันไหม ? ถ้ารอ แล้วไหนบอกว่า service ต้องเป็นอิสระแก่กัน
- การแก้ไข พบว่าเมื่อทำการเปลี่ยนแปลง ต้องไปแก้ไขหลาย ๆ ที่ หรือ หลาย service แบบนี้คือ duplication ไหมนะ น่าคิด
- เมื่อมีบาง service พัง หรือ ช้าไป แล้วก่อให้ service อื่น ๆ ที่เกี่ยวข้องมีปัญหาไปด้วย แบบนี้เป็นอิสระไหมนะ ไม่น่าใช่หรือเปล่านะ ?
ปิดท้ายด้วยแนวคิดของการออกระบบ ต้องมองให้รอบด้าน
มีหลสยมุมมอง ดังนั้นต้องการคนที่มี skill หลากหลาย
หรือเป็นการทำงานเป็นทีมนั้นเอง เช่น
- แนวทางการแยก (decomposition)
- แนวทางในการจัดเก็บข้อมูล จะรวม หรือ แยกกัน รวมกันมากไปก็ไม่ได้ แยกมากก็ไม่ได้
- พอแยกหลาย ๆ service และ data ต้องทำการนำมารวมกัน จะทำอย่างไร
- พอแยกหลาย ๆ service และ data จะจัดการเรื่องของ transaction อย่างไร
- แต่ละ service จะติดต่อสื่อสารกันอย่างไร ผูกมัดกันเกินไปไหม ? เป็นอิสระต่อกันไหม ?
- เรื่องของการทดสอบทำอย่างไร
- เรื่องของ observability ของ service และภาพรวมเป็นอย่างไร
- เมื่อเกิดปัญหาแล้ว ค่าของ MTTR (Mean-Time-to-Recovery) เป็นอย่างไร ช้า หรือ เร็ว
- การ deploy ทำอย่างไร คิดก่อนทำหรือไม่ หรือทำไปแล้วค่อยไปคิดทีหลัง ?
- สนใจ Zero downtime หรือไม่
- ระบบงาน react ต่อปัญหาอย่างไร
- ทำแต่ service ที่เป็น backend เคยสนใจฝั่ง fronend บ้างไหม ว่ามีปัญหาอะไรไหม ทำงานยากกว่าเดิมไหม
สิ่งเหล่านี้จำเป็นต้องได้รับคำตอบไหมนะ ?
ต่อมาในอีก 2 วัน ว่าด้วยเรื่องของ develop -> testing -> deploy
เป็นการลงมือทำ ว่าจากแนวคิดต่าง ๆ นั้น
เราจะลงมือทำได้อย่างไรบ้าง
เพื่อทำให้เรารู้และเข้าใจว่า
เพียงคิดอย่างเดียวมันยังไม่พอ
คิดได้ ก็ต้องทำให้ดูได้
แนะนำแล้ว ก็ต้องแสดงให้เห็นได้
โดยเป็นการทำ workshop เป็นเรื่อง ๆ แยกกันไปได้ดังนี้
- การออกแบบ interface ของ service เช่น REST API ทำอย่างไร โดยจะแนะนำเรื่องของ Design-first ด้วยเครื่องมือต่าง ๆ เช่น Postman, Swagger/OpenAPI และ API blueprint
- การจัดการปัญหาเรื่อง service to service communication นั่นคือการใช้งาน Circuit breaker ร่วมกับระบบ alert system เพื่อทำให้เรารู้ปัญหาทันที รวมทั้งการจัดการปัญหาเฉพาะหน้า เพื่อลดปัญหาไม่ให้ขยายวงกว้าง จนไปกระทบต่อส่วนอื่น ๆ
- การใช้งาน API gateway แบบพื้นฐาน โดยครั้งนี้แนะนำ APISIX ดูบ้าง
- การจัดการ Observability ของ service ประกอบไปด้วย Application metric, Distributed tracing และ Log aggregation ด้วยภาษาโปรแกรม และ เครื่องมือต่าง ๆ ที่หลากหลาย
- การติดต่อสื่อสารระหว่าง service แบบ asynchronous ว่าเป็นอย่างไร ลงมือทำเพื่อให้เข้าใจ
- การทดสอบ service to service ทำอย่างไร โดยลงมือทำ workshop 2 รูปแบบคือ component testing และ contract testing
- การออกแบบ pipeline ของการส่งมอบ service รวมไปถึง product ว่าควรมีอะไรบ้าง เพื่อทำให้เรามั่นใจในคุณภาพ พร้อมกับความรวดเร็ว
ปิดด้วย แนวคิดต่าง ๆ เกิดมาเพื่อแก้ไขปัญหา
ดังนั้นเราต้องรู้ก่อนว่า ปัญหาของเราตรงกับแนวคิดเหล่านั้นหรือไม่
มิเช่นนั้น เราเองที่จะเป็นคนสร้าง หรือ นำ ปัญหาเข้ามาเอง
