ในช่วงวันหยุดหยิบหนังสือ Release It 2nd edition มาอ่าน เน้นบทที่ 6 ว่าด้วยเรื่อง Stability Patterns ซึ่งอธิบายถึงรูปแบบของการวางสถาปัตยกรรมของระบบที่ดี เป็นแนวทางในการออกแบบระบบ เพื่อลด ขจัดปัดเป่า จากปัญหาต่าง ๆ ที่อาจจะเกิดขึ้น หรือลดความอันตรายจากข้อผิดพลาดต่าง ๆ ลงไป ไม่ใช่ต้องตื่นมากดึก ๆ เพื่อมาแก้ไขระบบ ไม่ใช่ต้องยกเลิกงานทั้งหมด เพื่อมาแก้ไขระบบ ถ้าเป็นแบบนี้คงไม่ต้องทำอะไรกันพอดี !! ดังนั้นมาสร้างระบบดี ๆ กันหน่อย
ช่วงนี้พูดถึง Istio กันเยอะ แต่คำถามที่น่าสนใจคือ มันอ่านว่าอะไร ? มีทั้ง ไอ เอส ที ไอ โอ และ อิท ทิ โอ อ่านอย่างไรก็ช่างมันนะ มันคืออะไร ? มันมาจัดการ service mesh ไง แล้ว service mesh คืออะไร ? ทำไมต้องใช้งานมันละ ? สถาปัตยกรรมมันเป็นอย่างไร ? ทำงานอย่างไร ? บ้างก็บอกว่า ปกติก็พัฒนาด้วย Stack ของ Spring Cloud Netflix ทำไมต้องมาใช้ ? ชีวิตดูยากมากมาย ดังนั้นลองมาเริ่มเรียนรู้กันนิดหน่อย (ไม่น่าจะนิดนะ)
ในเรื่องของ Microservices นั้นเรามักจะพูดกันถึง จะออกแบบ และ แยก service ออกมาเป็น Microservices กันอย่างไร ? จะต้องพัฒนาอย่างไร ? จะต้องทดสอบอย่างไร ? จะต้องดูแลอย่างไร ? แต่ก่อนที่จะไปกันไกล ให้กลับมาดูตัวเราเองก่อนว่า มีสิ่งที่ Microservices ต้องการหรือยัง ? ซึ่งเป็นความรู้และสิ่งจำเป็นพื้นฐานอย่างมาก
จากบทความเรื่อง SHIFT Commerce’s Journey: Deconstructing Monolithic Applications into Services ทำการอธิบายขั้นตอนการเปลี่ยนสถาปัตยกรรมระบบจาก Monolith ไปเป็น Microservices เป็นกรณีศึกษาที่น่าสนใจ จึงทำการสรุปไว้นิดหน่อย
มีโอกาสได้แบ่งปันเรื่อง Microservices มากขึ้น ทำให้เห็นมุมมองต่าง ๆ มากขึ้นเช่นกัน หนึ่งในนั้นคือ 6 เรื่องน่าคิดสำหรับ Microservices ซึ่งทาง Pivotal เขียนสรุปไว้ มันน่าสนใจมาก ๆ จึงนำมาสรุปไว้นิดหน่อย น่าจะพอมีประโยชน์บ้างสำหรับการตัดสินใจต่าง ๆ มาเริ่มกันเลย
ในช่วงที่ผ่านมาได้มีการพูดถึง Go-kit กันพอสมควร ทั้งในเรื่องของรูปแบบการเขียนที่ดี ทั้งในเรื่องของชุดเครื่องมือสำหรับการพัฒนา Microservices บางคนก็บอกว่าเหมือน Netflix เลย บางคนก็บอกว่าเหมือน Finagle ของ Twitter เลย
หลังจากใช้งาน Zipkin มาสักพัก ก็มีเจอสิ่งที่คล้าย ๆ กันและน่าสนใจมาก ๆ คือ Jaeger จาก Uber โดยมีแรงบันดาลใจมาจาก Dapper และ OpenZipkin เป้าหมายหลักของเครื่องมือตัวนี้ คือทำการ tracing การทำงานต่าง ๆ ของระบบงาน ไม่ว่าจะอยู่ในรูปแบบไหนก็ตาม แน่นอนว่าทุก ๆ ระบบน่าจะมีหรือคิดหรือทำไว้บ้าง เพื่อทำการ monitoring การทำงานของระบบ เพื่อช่วยวิเคราห์เรื่อง dependency ต่าง ๆ ของระบบ เพื่อช่วยหา root cause ของปัญหาต่าง ๆ เพื่อช่วยดู performance การทำงานของส่วนต่าง ๆ ของระบบ
ช่วงสัปดาห์ที่ผ่านมามีการพูดถึง NGINX Unit เยอะพอควร ดังนั้นเลยลองศึกษาแบบผิว ๆ หน่อยสิว่า มันคืออะไร ทำงานอย่างไร ใช้งานอย่างไร น่าจะมีประโยชน์ต่อการพัฒนาและ deploy ระบบงานต่อไป ปล. จะเรียก NGINX Unit ว่า Unit
จากบทความเรื่อง The evolution of scalable microservices นั้น ทำการอธิบายเกี่ยวกับ microservice ได้อย่างน่าสนใจ โดยเฉพาะในเรื่อง Microlith หรือ Micro Monolith ดังนั้นจึงทำการสรุปไว้นิดหน่อยดังนี้
มีโอกาสได้ไปสอนและแบ่งปันเรื่องของ SOA/Microservice เป็นเวลา 1 เทอม ที่คณะเทคโนโลยีสารสนเทศ สถาบันเทคโนโลยีพระจอมเกล้าเจ้าคุณทหารลาดกระบัง จึงทำการสรุปสิ่งที่สอนและพาทำไว้นิดหน่อย ซึ่งน่าจะพอเป็นประโยชน์ต่อคนที่สนใจบ้าง