ในการออกแบบ service ของระบบงานนั้นมีรูปแบบหนึ่งที่เจอบ่อยมาก ๆ คือเรามักจะแยกเป็น service ย่อย ๆโดยแต่ละ service ทำงานอย่างใดอย่างหนึ่งไปเลย (Single Responsibility)เป็นสิ่งที่ดีมาก ๆ เพราะว่าแต่ละ service มีขอบเขตการทำงานชัดเจนแต่เมื่อนำ service ต่าง ๆ มาทำงานร่วมกันจะเกิดรูปแบบต่าง ๆ มากมาย หนึ่งในรูปแบบคือ Chain of Responsibility หรือ Chain of Services
จากการแบ่งปันเรื่องปัญหาของระบบที่ทำงานช้า เมื่อพูดคุย วาดรูปของ architecture ของระบบแล้ว ได้เห็นว่า ต้นเหตุของปัญหาหลัก ๆ คือ เรื่องการการจัดการข้อมูล นั่นคือ ปัญหาในการแก้ไขข้อมูลทั้งการเขียน แก้ไขและลบ ปัญหาในการอ่านข้อมูล มักจะแก้ไขข้อมูลโดยไม่คำนึงถึงการใช้งาน เช่นการ ดึงข้อมูลเลยเก็บ ๆ กันไปก่อน แล้วค่อยไปดึงการทีหลัง !!
คำถามที่น่าสนใจมาก ๆ ที่ถูกถามเป็นประจำคือ ทำไมต้องมี API Gateway ด้วย ? ไม่ใช้ได้ไหม ? พอดีซื้อมาแล้ว ก็ต้องใช้ ? คนออกแบบกำหนดว่าต้องให้มี ? แต่ก็มักตอบกลับด้วยคำถามคือ ใช้ API Gateway ไปทำไม ? ทำไมต้องใช้ ? ไม่ใช้ได้ไหม ? การใช้หรือไม่ใช้ มีข้อดีและข้อเสียอะไรบ้าง
จากบทความเรื่อง Principles for Microservice Design: Think IDEALS, Rather than SOLID ทำการอธิบายแนวทางการออกแบบตามแนวคิด Microservices ได้อย่างน่าสนใจ โดยทำการหยิบเอาแนวคิดจาก SOLID สำหรับการออกแบบระบบที่พัฒนาด้วย Object-Oriented Programmingมาประยุกต์ใช้กับ Microservies
จากการสอนใน course Microservices workshop ที่ Skooldio ไปนั้น มีการแนะนำในเรื่องของการนำ messaging และ Event-based architecture มาใช้งาน และได้มีคำถามเกี่ยวกับการนำ RabbitMQ มาใช้งาน ว่าจะออกแบบตามที่ต้องการอย่างไรบ้าง
เรื่องของ Microservices นั้น ไปที่ไหนก็มีแต่คนพูดถึง หรือบางครั้งมันกลายเป็นแนวทางหลักของระบบต่าง ๆ ไปแล้ว แต่บ่อยครั้งจะพบว่า เราเน้นไปเรื่องว่าจะทำ อย่างไร ก่อนปัญหาที่เราต้องการแก้ไข มันอาจจะทำให้เกิดปัญหามากมายตามมา จากบทความ 5 Key Takeaways From My Experience with Microservices ทำการสรุปจากประสบการณ์การนำแนวคิด Microservices มาใช้งาน ว่ามันมีข้อดีข้อเสีย ข้อระมัดระวังรวมทั้งความเข้าใจ จึงทำการสรุปไว้นิดหน่อย น่าจะพอมีประโยชน์บ้าง
ในช่วง 2-3 เดือนที่ผ่านมานั้น มีโอกาสได้แลกเปลี่ยนความรู้และประสบการณ์ เกี่ยวกับการนำแนวคิด Microservices มาใช้งาน ผ่านทางการพูดคุย สอน แบ่งปันแบบ Remote/Online ทำให้ได้เห็นแนวทางที่ชัดเจนขึ้นว่า
บันทึกการอ่านบทความเรื่อง How Django can handle 100 millions of requests per day มีหลาย ๆ แนวคิดที่น่าสนใจ เพื่อให้ระบบมีประสิทธิภาพสูงขึ้น จึงทำการบันทึกสิ่งที่น่าสนใจไว้ มาเริ่มกันเลย
วันนี้ได้รับ email เรื่องเกี่ยวกับ Architecture จาก InfoQ ทำการสรุปสถาปัตยกรรมที่เปลี่ยนไปของ Istio 1.5 ซึ่งเปลี่ยนจากแนวคิดที่แบ่งเป็น component ย่อย ๆ ใน control plane ตามแนวทาง Microservices มาเป็น component เดียว หรือ Monolithic นั่นเอง สิ่งที่น่าสนใจคือ เหตุผลของการเปลี่ยนแปลง มาดูว่าเป็นอย่างไรกันบ้าง
จากหนังสือ Monolith to Microservices นั้น มีเรื่องเล็ก ๆ อธิบายเรื่อง Reuse ? หรือแปลว่า การใช้ซำ้ เราใช้ซ้ำเมื่อใด และเมื่อใดเราถึงใช้ซ้ำ และเราสร้างส่วนที่ใช้ซ้ำตอนไหน