อ่านบทความเกี่ยวกับการนำแนวคิด PDCA (Plan-Do-Check-Act)มาใช้กับการจัดการ วางแผนระบบงานในส่วนของ infrastructure หรือ DevOps Using the Plan-Do-Check-Act Framework to Produce Performant and Highly Available Systems เนื่องจากระบบงานนั้น ไม่ใช่สนใจแต่การออก feature ใหม่ ๆ ให้ลูกค้าเท่านั้นแต่ระบบงานต้องน่าเชื่อถือ รวมทั้งมี performance ที่ดีด้วยสรุปได้ดังนี้
ก่อนที่จะเลือกใช้ที่จัดเก็บข้อมูลชนิดใดควรต้องตอบคำถามเหล่านี้ให้ได้ก่อน ชนิดของข้อมูลที่จะจัดเก็บเป็นอะไร ? log user account order transaction JSON Document ถ้าเรารู้และเข้าใจ ก็จะทำให้เราเลือกที่จัดเก็บข้อมูลให้เหมาะสมต่อไป
จาก Google I/O มี session ที่น่าสนใจเกี่ยวกับ การพัฒนาระบบด้วย Flutter คือ frontend สนับสนุนทั้ง mobile, web และ desktop application Dart และ Cloud Run คือ backend หรืออาจจะใช้ Serverless ก็ได้ Firebase Realtime Database คือ database ที่ใช้เก็บข้อมูล หรืออาจจะใช้งาน Firestore ก็ได้ เป็น stack ที่น่าสนใจมาก ๆ
Apache Kafka นั้นได้ปล่อย version 2.8.0 มาเมื่อวันที่ 16 เมษายนโดยความสามารถที่น่าสนใจมีทั้ง Core, Connect และ Streamแต่ตัวที่น่าสนใจคือ KIP-500 นั่นก็คือ การเปลี่ยนที่เก็บข้อมูลต่าง ๆ สำหรับการจัดการ (Metadata)จาก Apache Zookeeper มาไว้ใน Apache Kafka เองเลยเพื่อลดความซับซ้อนของระบบ ทั้งการติดตั้งและ configurationรวมทั้งในเรื่องของ scale และ security ของระบบ
วันนี้อ่านบทความเรื่อง The software architect fallacyโดยสิ่งที่น่าสนใจคือ ภาพประกอบการอธิบายในบทความซึ่งใช้การสร้างเรือมาอธิบายเรื่องของการ ออกแบบและสร้างระบบงานเป็นการพัฒนาเป็นรอบ ๆ ไป ตามความต้องการมาดูกันว่า ใครยังเป็นแบบนี้กันอยู่บ้าง
จากงาน QCon Plus 2020 :: The Journey from Monolith to Microservices at GitHub ระบบของ GitHub นั้นมีอายุมากกว่า 12 ปีโดยพัฒนาในรูปแบบของ Monolith architecture เป็นหลักพัฒนาด้วย RoR หรือ Ruby on Railsทำการ deploy หลายครั้งต่อวันระบบต้อง scale เพื่อรองรับจำนวน request มากกว่า 1,000 ล้านครั้งต่อวันโดยระบบสามารถทำงานได้ตามที่ต้องการเป็นอย่างดี
ถ้าเรามีความรู้และเข้าใจเกี่ยวกับสิ่งที่ไม่ดีแล้วเราสามารถนำมันมาใช้ให้เกิดประโยชน์ได้ถ้าเราใช้มันอย่างถูกต้องและเหมาะสมรวมทั้งสิ่งที่ดีก็เช่นกัน ถ้าไม่เข้าใจและนำมาใช้ผิด ๆ แล้วแทนที่จะเกิดประโยชน์กลับเกิดโทษมากกว่าไปอีกมาตัวแนวทางที่ไม่ดีกันหน่อย (ชอบทำกันไหม ?)
ในการออกแบบ service ของระบบงานนั้นมีรูปแบบหนึ่งที่เจอบ่อยมาก ๆ คือเรามักจะแยกเป็น service ย่อย ๆโดยแต่ละ service ทำงานอย่างใดอย่างหนึ่งไปเลย (Single Responsibility)เป็นสิ่งที่ดีมาก ๆ เพราะว่าแต่ละ service มีขอบเขตการทำงานชัดเจนแต่เมื่อนำ service ต่าง ๆ มาทำงานร่วมกันจะเกิดรูปแบบต่าง ๆ มากมาย หนึ่งในรูปแบบคือ Chain of Responsibility หรือ Chain of Services
จากหนังสือฟรีเรื่อง Architecting for Scaleเฉพาะในบทที่ 4 Service and Dataมีหนึ่งสิ่งที่น่าสนใจคือ การกำหนด Six Levels of Cloud Maturityสำหรับขั้นตอนการนำ Cloud มาประยุกต์ใช้งานในองค์กรประกอบไปด้วย
หลังจากที่ใช้งาน OpenTracing มานานซึ่งตอนนี้ OpenTracing ได้รวมเข้ากับ OpenCensus แล้วมีชื่อว่า OpenTelemetry จึงมาลองศึกษาและใช้งานดูกันหน่อย
