คำถามที่น่าสนใจมาก ๆ ที่ถูกถามเป็นประจำคือ ทำไมต้องมี API Gateway ด้วย ? ไม่ใช้ได้ไหม ? พอดีซื้อมาแล้ว ก็ต้องใช้ ? คนออกแบบกำหนดว่าต้องให้มี ? แต่ก็มักตอบกลับด้วยคำถามคือ ใช้ API Gateway ไปทำไม ? ทำไมต้องใช้ ? ไม่ใช้ได้ไหม ? การใช้หรือไม่ใช้ มีข้อดีและข้อเสียอะไรบ้าง
บันทึกการอ่านบทความเรื่อง How Django can handle 100 millions of requests per day มีหลาย ๆ แนวคิดที่น่าสนใจ เพื่อให้ระบบมีประสิทธิภาพสูงขึ้น จึงทำการบันทึกสิ่งที่น่าสนใจไว้ มาเริ่มกันเลย
วันนี้อ่านบทความเรื่อง Everything you need to know about Caching — System Design อธิบายเรื่องพื้นฐานเกี่ยวกับ caching หรือข้อมูลชั่วคราว ว่าคืออะไร มีการใช้งานใน use case หรือในกรณีอะไรบ้าง รวมทั้ง strategy และ policy การใช้งาน caching ว่าเป็นอย่างไร ผมคิดว่าเป็นเรื่องพื้นฐานที่นักพัฒนาจำเป็นต้องรู้และเข้าใจ เพื่อนำมาประยุกต์ใช้งานได้อย่างมีประสิทธิภาพ จึงทำการสรุปไว้นิดหน่อย
จาก Live กับหนึ่งในทีมพัฒนาของระบบเราไม่ทิ้งกัน จาก page รู้ไม่มากแต่อยากเล่า ที่เปิดให้คนไทยที่ได้รับผลกระทบจาก COVID-19 มาลงทะเบียนเพื่อรับเงินเยียวยา ดังนั้นจึงทำการสรุปสั้น ๆ ไว้หน่อย
บันทึกการนั่งเฝ้าดูระบบ เราไม่ทิ้งกัน.comซึ่งบอกไว้ว่าจะเปิดให้ลงทะเบียนวันที่ 28 มีนาคม เวลา 18.00 น.ผมก็เฝ้ารอดูระบบเลยว่าจะเอาอยู่ไหม ?เรื่อง IT เราสนใจอยู่แล้วมาดูกันเป็น timeline กันเลย
เจอรูปที่น่าสนใจว่า เราให้ความสำคัญกับคำว่า Loose coupling มากจนเกินไปทำให้เกิดระบบแยกกันมาก ๆ ทำการเกิด communication และ relationship กันเยอะไปยิ่งกว่านั้นกลายเป็น dependency ที่เหนียวแน่นมาก ๆ (แยกกัน แต่ตอนทำงานดันติดกันมาก)สุดท้ายก็กลายเป็นระบบที่ Complicate หรือซับซ้อนจนเอาไม่อยู่กันอยู่หรือเปล่านะ
จากบทความเรื่อง The Elephant in the Architecture นั้น ทำการอธิบายถึงที่มาที่ไปของปัญหาต่าง ๆ ที่เกิดขึ้นในการออกแบบ software ว่าเราทำการออกแบบด้วยแนวคิดอย่างไร ? ซึ่งแนวทางนั้นจะเทียบเคียงได้กับสำนวน The Elephant in the room นั่นคือ เราทุกคนนั้นเห็นปัญหา เห็นข้อเท็จจริงต่าง ๆ อย่างชัดเจน แต่ทุกคนหลีกเลี่ยงที่จะพูดถึงมัน เหมือนกับการมีช้างอยู่ในห้อง แต่ทุกคนจะไม่พยายามหรือมองเห็นมันนั่นเอง
หนึ่งในเรื่องที่น่าสนใจจากหนังสือ Monolith to Microservices (Evolutionary patterns to transform your monolith) อธิบายว่า เมื่อจำนวน service ของระบบเพิ่มมากขึ้นแล้ว ปัญหาที่ต้องพบเจอก็มากและแตกต่างกันไป เช่นปัญหาของ service ที่ไม่เกิน 10 service จะแตกต่างจาก 50 หรือ 100 service ดังนั้นสิ่งที่เราควรต้องรู้แล้วเข้าใจคือ จะรับมือหรือแก้ไขปัญหาเหล่านั้นกันอย่างไร
อ่านบทความเรื่อง Taming Complex Systems in Production มีเรื่องที่น่าสนใจเยอะ หนึ่งในนั้นคือ เรื่องเกี่ยวกับการพัฒนาระบบ ให้สามารถ recover กลับมาจากความผิดพลาดได้ด้วยระบบเอง โดยไม่ต้องมีคนเข้าไปยุ่งเกี่ยว ซึ่งสรุปว่าระบบที่จะทำได้จำเป็นจะต้องมีคุณสมบัติดังต่อไปนี้
วันนี้ว่าง ๆ เลยมานั่งอ่าน The InfoQ eMag – Taming Complex Systems in Production เป็น miniBook จากทาง InfoQ แนะนำสำหรับจัดการหรือควบคุมระบบงานที่ยิ่งนานวันยิ่งมีความซับซ้อนมากขึ้นเรื่อย ๆ ยิ่งเมื่อเกิดปัญหาขึ้นมา บ่อยครั้งต้องมีค่าใช้จ่ายสูงมากในการแก้ไขเพื่อให้ระบบกลับมาทำงานได้อย่างปกติ ดังนี้เราควรต้องทำการแก้ไขและปรับปรุงแล้วนะก่อนอื่นเราต้องทำการปรับปรุงในแง่ขององค์กร คน และระบบการทำงาน ให้มีความยืดหยุ่น และสามารถกลับคืนมาสู่สภาวะการทำงานปกติได้ง่าย