หนึ่งในเรื่องพื้นฐานที่ควรต้องรู้และเข้าใจคือ Load Balancerหรือการกระจายงานที่เข้ามาไปยัง server หรือ resource ต่าง ๆเพื่อให้ระบบทำงานอย่างมีประสิทธิภาพรวมทั้งต้องทำให้มั่นใจด้วยว่า ทำการกระจายงานไปยัง server ตามที่ต้องการ ไปเจอ web อธิบายเรื่อง Load Balancer ด้วยรูปการ์ตูนจาก Cloud for Geeksเห็นว่าน่าสนใจ จึงนำมาฝาก
คำถามที่น่าสนใจมาก ๆ ที่ถูกถามเป็นประจำคือ ทำไมต้องมี 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 กลับมาจากความผิดพลาดได้ด้วยระบบเอง โดยไม่ต้องมีคนเข้าไปยุ่งเกี่ยว ซึ่งสรุปว่าระบบที่จะทำได้จำเป็นจะต้องมีคุณสมบัติดังต่อไปนี้
