เริ่มต้นจากสถาปัตยกรรมของระบบงาน (Application Architecture) สถาปัตยกรรมของ software นั้นมีหลากหลายรูปแบบ แต่แนวโน้มของสถาปัตยกรรมต่าง ๆ ล้วนพยายามแยกส่วนการทำงานออกเป็นชิ้นเล็ก (Decomposition) โดยแต่ละชิ้นต้องทำงานได้ด้วยตัวเอง (Service) ระบบงานใหญ่ ๆ เรามักจะเรียกว่า Monolithic ส่วนระบบงานที่เราทำการแบ่งเป็น Service เล็ก ๆ จะเรียกว่า Microservice
ไปอ่านเจอใน feed จาก Twitter แบบผ่าน ๆ เจอว่ามีการพูดถึง Microservices 4.0 ด้วย (หา link ต้นทางไม่เจออีก) แบบนี้แสดงว่า 4.0 นี่ไม่ได้ฮิตในบ้านเราเท่านั้นนะ (ไม่น่าเกี่ยวข้องกัน) เลยนำมาสรุปแบบคร่าว ๆ ไว้หน่อย น่าจะพอมีประโยชน์กันบ้าง ปล. แค่เรื่อง Microservices ก็ยังงง ๆ กันแล้ว นี่มีทั้ง 1.0, 2.0, 3.0 และ 4.0 จะไม่งงได้อย่างไร !!
จาก Part ที่ 1 สรุปปัญหาและการนำแนวคิดของ Microservices มาใช้งานและแก้ไขปัญหา มาใน Part ที่ 2 มาดูแนวทางการใช้งานกัน ซึ่งทางทีมพัฒนาของ Medium.com ได้แบ่งแนวทางการนำ Microservices มาใช้ ออกเป็น 7 ข้อ มาดูกันว่าแต่ละข้อเป็นอย่างไรบ้าง
ทาง Medium.com ได้เขียนสรุปเกี่ยวกับแนวทางการนำ Microservice Architecture มาใช้งาน ซึ่งช่วยทำให้ทีมพัฒนาสามารถพัฒนาและส่งมอบระบบงานได้เร็วขึ้น พร้อมกับคุณภาพที่สูงขึ้น รวมทั้งยังช่วยทำให้แต่ละ service แยกกันพัฒนาและลดผลกระทบต่าง ๆ อีกด้วย ดังนั้นเรามาดูกันหน่อยว่า ทีมพัฒนาของ Medium.com เขาทำกันอย่างไรบ้าง ? จึงทำการสรุปจากบทความไว้นิดหน่อย
ในช่วงวันหยุดหยิบหนังสือ 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 เลย