ระหว่างนั่งกินข้าวกลางวัน มีคำถามเกี่ยวกับการพัฒนา Spring Boot
ว่ามีคำแนะนำอะไรบ้าง ที่จำเป็นต่อการพัฒนา
ก็เลยบอกไปสั้น ๆ ว่า
เขียน code ให้ดี ทดสอบให้ได้
ที่เหลือก็รับผลกรรม !!

ตอบแบบนี้ไปคงไม่ดีแน่ ๆ จึงสรุปไว้นิดหน่อย
เน้นเฉพาะสิ่งที่ทำ อะไรที่มัน advance มาก ๆ ผมก็ทำไม่เป็น
มาเริ่มกันเลย

เรื่องแรก ต้องเข้าใจก่อนว่า Spring Boot มันเหมือนขนมเค้กที่ทำเสร็จแล้ว

นั่นคือพร้อมกินหรือส่งมอบ
ที่เหลืออยู่ที่ว่าเราต้องตกแต่ง หรือ ต่อเติมมันอย่างไร
ดังนั้นต้องเข้าใจว่า มันมีโครงสร้างพื้นฐานการทำงานแบบที่ตกลงกันไว้อย่างไร
มากกว่าที่จะมาทำการ custom หรือ configuration อะไร
นั่นคือ Convention over Configuration นั่นเอง
เพราะว่าสิ่งที่เตรียมมาให้น่าจะดีในระดับหนึ่งแล้ว

ที่สำคัญยิ่งไป custom เยอะ ยิ่งเลอะเทอะ
แถมดูแลรักษายากอีก
บ่อยครั้งไม่สามารถ upgrade ได้อีก
ต้องระวังไว้เลย

ข้อความระวังคือ พวก annotation ต่าง ๆ ที่จะเยอะเป็นพิเศษ
ถ้าใครกำลังทำ หรือ เจออยู่ ขอให้ลด ละ เลิก เถอะ มันไม่ได้ดูเหนืออะไรนะ

เรื่องที่สอง การจัดการพวก dependency แนะนำให้ใช้ BOM (Bills of Material)

จะทำให้เราจัดการพวก dependency ของ project ได้ดียิ่งขึ้น
หลัง ๆ มีปัญหาเกี่ยวกับเรื่องความปลอดภัยของ dependency ที่ใช้บ่อย ๆ
ยิ่งต้องใช้งาน

เรื่องที่สาม สร้าง project ด้วย Spring Initializr ดีกว่านะ

การไป copy จาก project ก่อนหน้า หรือ project เก่า ๆ ที่ทำมา
และเชื่อว่ามันจะดี
อย่าทำเลยนะ ขอร้อง

เรื่องที่สี่ โครงสร้างของ project ในเอกสารของ Spring Boot ก็บอกไว้

ทำเป็นในรูปแบบของ domain/function ซะ สำหรับ project ที่ใหญ่
แต่ Spring Boot ไม่ได้สร้างมาเพื่อให้ project ใหญ่นะ
มี controller เยอะ ๆ ไม่น่าดีใช่ไหมนะ ?
แต่ทำไมทำกันนะ สงสัยไม่อ่านเป้าหมายของ Spring Boot มั้ง !!

แต่ถ้า project เล็ก ๆ เรื่องของ project structure ก็ไม่ได้สำคัญมากนัก

อีกอย่างพวก Fat controller, large class/service คงไม่มีกันแล้วใช่ไหม ?

ส่วน business logic จริง ๆ ไม่ควรหรือมี code ของ Spring Boot น้อยที่สุดใช่ไหม ?

อีกอย่าง ถ้าสังเกตตัวอย่าง code ของ Spring Boot
มักจะใช้ Constructor Injection หมดแล้วนะ
ทำให้ไม่ต้องใช้ @AutoWired เลย
นั่นหมายความว่า เราสามารถสร้าง instance
โดยไม่ต้องอยู่ใน context ของ Springได้แบบง่าย ๆ อีกนะ

พวก Controller, Service annotation ต่าง ๆ นั้น
มันคือ singleton by default นะ ดังนั้นการจะเก็บ state ใด ๆ ก็ระวังให้มาก ๆ
พอมีคนใช้พร้อมกันเยอะ ๆ อาจจะมีปัญหาได้เลย !!

เรื่องที่ห้า การจัดการ configuration ต่าง ๆ

อย่างแรกไม่ควรใช้งาน Spring profile แบบ hard code กัน
เช่นมีกี่ environment ก็มี profile แยกกัน
load file แยกกัน
ต้อง build ใหม่ทุก ๆ environment
เนื่องจากก่อให้เกิดความผิดพลาดมากมายตามมา
เคยไหมทำการ build ผิด profile !!

แนะนำให้ใช้ environment variable จาก OS นั้น ๆ ดีกว่า
หรือไปใช้พวก external configuration server เป็นต้น

เรื่องที่หก เขียน test ด้วยละ

Spring Boot นั้น เขียนไว้เลยว่า สำหรับสร้าง Testable application
เขาก็มี library ของการทดสอบมาให้ด้วย
ทั้ง Spring Boot Test
ทั้ง Slice test
ทั้ง Unit test
ทั้ง Contract test
ทั้ง Component test
ก็เขียนกันด้วยละ
ไม่ใช้มี test case เดียวตลอดทั้ง project ซะงั้น !!

เรื่องอื่น ๆ ที่สำคัญไม่แพ้กัน ก็เช่น

• Logging framework
• Error handling
• Transaction management
• Metric ด้วย Spring Boot Actuator
• Circuit breaker

เขียนไปเขียนมาเยอะเกินไปแล้ว
พอดีกว่า !!

ปล. คำถามสุดท้าย ใช้งาน Spring Boot version อะไรอยู่ ?
คำตอบที่ได้กลับมาสยองมาก ๆ คือ ยังไม่ 2 เลย !!
สวัสดี

เห็นว่า NATS นั้นมี JetStream มาให้ใช้งาน
เพื่อมาจัดการปัญหาเรื่องของ persistence และ นโยบายการ delivery message
รวมทั้งให้ง่ายต่อการ scale และรองรับข้อมูลขนาดใหญ่
สามารถดูเป้าหมายการออกแบบของ JetStream เพิ่มได้ที่นี่

โดยที่การทำงานของ JetStream นั้น จะรองรับทั้งแบบ push และ pull message
แสดงดังรูป

เพื่อความสนุกสนาน มาลองใช้งานกันดีกว่า

โดย software ที่ใช้งานใน blog นี้ประกอบไปด้วย

• NATS with Docker
• Go
• NATS Go Client

ขั้นตอนที่ 1 ทำการ start NATS JetStream Server ด้วย Docker

ทำการ start server ดังนี้

ขั้นตอนที่ 2 ทำการเขียน codeด้วยภาษา Go สำหรับ connect ไปยัง NATS server

เชื่อมต่อไปยัง NATS server ผ่าน port 4242
ทำการสร้าง stream ชื่อว่า data ในกรณีที่ยังไม่มีการสร้าง

ขั้นตอนที่ 3 ทำการสร้างส่วนของ Publisher เพื่อสร้าง message เข้าไปยัง demo.data

ขั้นตอนที่ 4 ทำการสร้างส่วนของ Subscriber เพื่อรับ message จาก demo.data

ซึ่งทำงานแบบ push ดังนี้

เพียงเท่านี้ก็สามารถเริ่มต้นใช้งาน NATS JetStream Server ได้แล้ว
รวมทั้งเขียน code ด้วยภาษา Go เพื่อ publish/subscribe ข้อมูลแบบง่าย ๆ อีกด้วย

จาก Elasticsearch 8.3 นั้น
ทำการปรับปรุง performance การทำงานของ Ingest pipeline
โดยลดการใช้ CPU ลงไปประมาณ 5-10% ขึ้นอยู่กับรูปแบบของข้อมูล
และมีสิ่งที่น่าสนใจ ประกอบไปด้วย

• สามารถ query ข้อมูลที่สร้างจาก version 5 หรือ 6 ได้ ช้าหน่อย แต่ใช้ได้
• ปรับปรุงเอกสารเกี่ยวกับ size of shards
• เพิ่ม Geo grid query เข้ามา
• แก้ไข bug ของ Machine Learning เยอะมาก ๆ

ไป Download มาใช้งานกันครับ

เห็นบทความเรื่อง Things You Should Know About Databases
จากทาง Architecture Notes
ว่าด้วยเรื่องที่ควรต้องรู้เกี่ยวกับ database ที่ใช้งานกัน
โดยเฉพาะ RDBMS (Relational DataBase Management System)
ที่ถูกใช้งานกันอย่างมากในระบบต่าง ๆ

มีเรื่องพื้นฐานหลายอย่างที่น่าสนใจมาก ๆ
และบ่อยครั้งเรามักจะหลงลืมหรือไม่เข้าใจมัน
ทำให้ใช้งานแบบถูก ๆ ผิด ๆ กันมา
ดังนั้นมาดูกัน โดยประกอบไปด้วยเรื่องต่าง ๆ ดังนี้

• การทำงานของ Index ว่าเป็นอย่างไร มีโครงสร้างอย่างไร (BTRee และ B+Tree)
  ช่วยให้ค้นหาข้อมูลได้รวดเร็วขึ้นอย่างไร
• Performance ของการอ่านและเขียนข้อมูล รวมทั้งเรื่องของ Big O Notation

• การจัดการ transaction ที่ต้องเข้าใจ ACID (Atomic, Consistency, Isolation, Durability)
• ทำความเข้าใจเรื่องของการเข้าถึงข้อมูลพร้อม ๆ กัน (Concurrency) ซึ่งต้องเข้าใจ Isolation Level ทั้ง Repeatable read, Serializable, Read committed และ Read uncommitted เป็นต้น

ลองอ่านรายละเอียดเพิ่มเติมดูครับ
เป็นการปูพื้นฐานให้แน่น ก่อนที่จะไปเรื่องที่ซับซ้อนกว่านี้

ใน RDBMS มี ACID
ส่วนในโลกของ NoSQL จะมี BASE (Basically Available, Soft state และ Eventually consistent)

เห็นมีการพูดถึง Bun ซึ่งเป็น JavaScript Runtime ที่รวมเอาทุกอย่างไว้ด้วยกัน
ทั้ง Bundling ของ JS และ CSS,
Transpiler ของ JS, TS และ JSX
JavaScript Runtime ที่มี Web API มาเลย ทั้ง fetch และ websocket เป็นต้น
Task runner และ package manager ที่ทำงานร่วมกับ package.json และ npm ได้เลย
ที่สำคัญเร็วมาก ๆ !!

ปล. แต่เป็นเพียงตัวที่สร้างขึ้นมาเพื่อทดลองเท่านั้นนะ !!

Bun พัฒนาด้วยภาษา Zig และ C++ เป็นหลัก

มาลองใช้งานง่าย ๆ กัน

เริ่มด้วยการติดตั้ง

จากนั้นลองเขียน api server เล่นหน่อย ด้วย fetch

สุดท้ายก็ลอง start server และยิง load test ด้วย WRK ดูหน่อย

จะได้ผลตามนี้ ยิงเบา ๆ
ได้ผลออกมา โหดร้ายจริง ๆ

ปัญหาวันนี้ ต้องการจะสร้าง Dockerfile ขึ้นมา
จาก Docker Image ที่มีอยู่แล้ว
คำถามคือ จะทำอย่างไรดี ?

โดยปกตินั้นเราจะใช้คำสั่ง $docker image history สำหรับดูว่า
ในแต่ละ layer ของ Docker Image นั้นประกอบด้วยอะไรบ้าง
จากนั้นก็ทำการ copy มาใส่ใน Dockerfile เท่านั้นเอง

หรือใครอยากเขียน codeก็สามารถใช้งานผ่าน Docker client library ได้เช่นกัน

ยกตัวอย่างเช่น Docker client for Python

สามารถเขียน code เพื่อดู history ของ Docker Image ได้ดังนี้

หรือจะใช้เครื่องมือต่าง ๆ ที่มี ก็เป็นอีกทางเลือก เช่น

• Dive
• Dedockify

ส่วนผมใช้วิธีการแรก ก็เพียงพอแล้ว !!

ปกติในการจัดการพวก job scheduling นั้น
มักจะใช้พวก crontab เป็นหลัก
หรืออาจจะไปใช้งานพวก AirFlow ไป ก็ช่วยได้เยอะ
แต่ลองไปค้นหาเพิ่มเติ่ม ก็เจอ Rocketry
ซึ่งพัฒนาด้วยภาษา Python
ที่สำคัญเขียน code ง่าย ๆ เพื่อจัดการ job scheduling
ดังนั้นมาลองใช้งานกันดูหน่อย

สิ่งแรกจากการใช้งานตัว Rocketry นั้น คือ

• Code ที่อ่านง่าย
• Code สั้น กระชับ

ตัวอย่าง code ง่าย ๆ เป็นดังนี้

สิ่งที่ชอบคือ การกำหนด schedule ของแต่ละ function ว่าทำงานตอนไหน
ที่อ่านเข้าใจได้ง่าย ยกตัวอย่างเช่น

• every 10 seconds คือ ทำงานทุก ๆ 10 วินาที
• daily after 10:00 คือ ทำงานทุกวันหลัง 10 โมงเช้า
• (weekly on Monday | weekly on Saturday) & time of day after 10:00 ลองคิดดูว่า จะทำงานวันไหน เวลาอะไรบ้าง
• after task 'do_first' คือ ให้ทำการหลังจาก task/function ชื่อว่า do_first ซึ่งใช้ในการกำหนด pipeline ของการทำงานได้แบบง่าย ๆ

รวมทั้งยังสามารถทำงานได้หลากหลายมากขึ้น
แต่ยังคงความง่ายของ code ที่เขียนออกมา ยกตัวอย่างเช่น

• การทำงานแบบ concurrency
• การทำงานแบบ pipeline
• การจัดการ order ของการทำงานของ job ต่าง ๆ
• สามารถเก็บ log ลอง data store ต่าง ๆ ได้ ทั้ง SQL และ NoSQL

ตัวอย่างของการทำงานแยกออกจาก thread/process หลัก

เป็น project ที่นำมาใช้แล้ว
ช่วยให้จัดการ job scheduling ได้สะดวกยิ่งขึ้น
น่าสนใจมาก ๆ
ลองทดลองใช้กันดูครับ

ขอให้สนุกกับการ coding ++

จาก Release notes ของ Robot Framework 5.1 alpha 1 นั้น
มี feature ใหม่ที่น่าสนใจออกมาเยอะน่าดู
หนึ่งในนั้นคือ Localization
ช่วยทำให้ เราสามารถเขียน test script ให้ตรงตามภาษาของประเทศนั้น ๆ ได้เลย

โดยตอนนี้สามารถใช้ได้เฉพาะ test script หลัก ๆ

ที่อยู่ในไฟล์ languages.py เช่น

• Setting
• Variable
• Test Case
• Keyword
• Tags
• Suite Setup/Teardown
• Test Setup/Teardown
• Test Template
• Template
• Arguments
• Documentation

ต่อไปจะมีพวกชุดคำสั่งต่าง ๆ เช่น IF/FOR เป็นต้น
ให้สามารถเปบลี่ยนไปตามภาษาต่าง ๆ ด้วย

โดยตอนนี้จะสนับสนุนภาษาต่าง ๆ ดังนี้

• Czech (CS)
• Dutch (NL)
• Finnish (FI)
• French (FR)
• German (DE)
• Portuguese (PT) and Brazilian Portuguese (PTBR)

สามารถดูเพิ่มเติมได้ที่ Crowdin Robot Framework

วันนี้ได้อ่านบทความเรื่อง Frankenstein APIs Explained! - API Cyber Security Series
แต่ได้ฟังชื่อก็แปลกดี ไม่เคยได้ยินเลย
ดังนั้นจึงลองอ่านและสรุปไว้นิดหน่อย
ว่าคืออะไร มีรูปแบบอย่างไร ?

จากบทความได้แบ่งหมวดหมู่ของ API เป็น 7 หมวดคือ

• Public API
• Internal API
• Partner API
• Composite API
• Shadow API
• Zombie API
• Frankenstein API

มาดู Frankenstein API ว่าคืออะไร เป็นอย่างไร

เริ่มด้วยคำถาม
ถ้าเราต้องการ API เพื่อทำงานหรือใช้งานบางสิ่งบางอย่าง
แต่ระบบงานของเราไม่มี API เหล่านั้นเตรียมไว้ให้
เราจะทำอย่างไร ?

หนึ่งวิธีการคือ ทำระบบหรือ API ครอบอีระบบ API เดิมอีกชั้น
หรืออาจจะทำการดึงข้อมูลบางอย่างมาใช้งานในระบบใหม่
เหมือนเป็นระบบที่สร้างขึ้นมาเพื่อตอบสนองการใช้งาน
แน่นอนว่า ระบบเดิมไม่ได้เกี่ยวข้องหรือไม่รู้เรื่องอะไรด้วยเลย
ส่วนคนใช้งานก็มาใช้ผ่านระบบใหม่ที่สร้าง

ผลที่อาจจะเกิดขึ้นมาคือ
เรื่องของ function การทำงานอาจจะทำได้ตามที่ต้องการ
แต่อาจจะขาดเรื่องของการจัดการ security
รวมทั้งอาจจะก่อให้เกิดผลกระบทบต่อ API เดิมที่มาครอบอีกด้วย
แต่ไม่ได้บอกว่าไม่ดี แต่เพียงต้องระวังเท่านั้นเอง
เช่นการ bypass การตรวจสอบ Token ต่าง ๆ ทิ้งไป
จาก Client -> API เปลี่ยนเป็น Client -> API ใหม่ -> API เก่า

อีกอย่างเป็นการทำงานแบบต่างคนต่างทำงาน
อาจจะส่งผลหรือมีปัญหาเมื่อ เกิดการเปลี่ยนแปลงจากระบบเก่า
ทำให้ระบบใหม่เกิดปัญหาก็เป็นได้
รวมทั้งชี้ให้เก็นถึงปัญหาของการทำงานภายในบริษัทหรือไม่ !!

หรือเป็นการเพิ่มภาระงานให้ API เก่าเพิ่มด้วยหรือไม่ ?

คำถามคือ ในระบบงานของเรามี Frankenstein API บ้างไหมนะ ?

มาทำความรู้จักและลองใช้งาน GitHub CodeQL กัน
ซึ่งสร้างขึ้นมาเพื่อทำการ scan sourcecode ต่าง ๆ
เพื่อตรวจสอบหาจุดบกพร่องของ code ในมุมมองของ bug และ security
หรือเป็น Static Application Security Testing (SAST)
ซึ่งสามารถเขียน query เพื่อหารูปแบบที่ต้องการได้

การใช้งาน CodeQL สามารถทำได้ดังนี้

• CodeQL CLI สามารถ integrate เข้ากับ CI pipeline ได้เลย
• Extension ใน VS Code
• Integrate เข้ากับ GitHub Actions

ตัวอย่างง่าย ๆ เช่น GitHub Actions

เป็นอีกเครื่องมือที่น่าสนใจ สำหรับการ scan code
เพื่อช่วยเพิ่มความเชื่อมั่นมากยิ่งขึ้น
ลองใช้งานกันดูครับ

ใน Java 19 นั้น มีความสามารถที่น่าสนใจคือ JEP 425 : Virtual Threads
ซึ่งอยู่ใน Project Loom นั่นเอง
โดยยังเป็น feature preview อยู่

เป้าหมายของ Virtual Threads

• ทำการ scale การทำงานของ thread ให้ทำงานร่วมกับ hardware ได้ดีขึ้น ลดการใช้ memory ลงไป
• สามารถปรับการใช้งาน Thread API ได้ง่าย
• ให้ง่ายต่อการแก้ไขปัญหา การ debug และ profiling ด้วย JDK tools

มาลองเขียน code เล่น ๆ กันหน่อย

โดยทำการสร้าง 10 ล้าน thread มาเล่นหน่อย

จากนั้นลอง run ด้วย Java 19
พบว่าทำงานได้ปกติ ไม่เกิด out of memory ใด ๆ
และเร็วอีกด้วย !!
น่าสนใจมาก ๆ สำหรับ feature นี้

คำถามที่น่าสนใจเกี่ยวกับ MySQL database คือ
ทำไม memory ถึงใช้เยอะขึ้นเรื่อย ๆ กัน
บ่อยครั้งกินไปเรื่อย ๆ จนเกือบไม่เหลือ
แต่ระบบก็ยังทำงานได้ปกตินะ

หนึ่งในสิ่งที่เจอคือ การใช้งานจาก INDEX ต่าง ๆ ของแต่ละ table นั่นเอง
ยกตัวอย่างการ query ข้อมูลมาดู
ว่าอะไรที่ใช้งาน memory เยอะ ๆ บ้าง

เจอผลลัพะ์แนว ๆ นี้ ซึ่งทำให้เรารู้ว่า
ส่วนไหนที่ใช้งาน memory เยอะ เพื่อแก้ไขปัญหาต่อไป

Reference Websites

• What To Do When MySQL Runs Out of Memory

มีโอกาสได้แบ่งปันเรื่องเกี่ยวกับ feedback loop ในการพัฒนา software
โดยหนึ่งในเรื่องที่น่าสนใจคือ
การให้ได้มาซึ่ง feedback ที่รวดเร็ว
เพื่อให้เรารู้และเข้าใจในสิ่งที่สร้างขึ้นมาว่า เป็นอย่างไร
ทั้งคุณภาพภายใน คือ code และโครงสร้าง รวมถึงการทำงาน
ทั้งคุณภาพภายนอก คือ มุมมองจากผู้ใช้งาน เน้นว่าผู้ใช้งานจริง ๆ

โดยสามารถสรุปสั้น ๆ จากการพูดคุยได้ดังนี้

หนึ่งรอบการ review เพื่อให้ได้มาซึ่ง feedback ต้องสั้น และ บ่อย ๆ
รวมทั้งต้อง focus กับ feature หรือ งาน หรือ ปัญหา หนึ่ง ๆ ไปเลย
ยิ่งมีหลายเรื่อง ยิ่งไม่ focus
ดังนั้นเรื่องการ focus หรือ ความถี่จึงต้องสัมพันธ์กัน
ยิ่งตอนเริ่มไม่พร้อมแล้วด้วย ยิ่งต้อง review กันบ่อย ๆ

ในการทำงานร่วมกัน ถ้ามีคนไม่พร้อมมาทำการ review
แนะนำให้ record screen หรือ บันทึก VDO
แล้วส่งให้เลย
เพราะว่า บ่อยครั้งแค่ตัวอักษร เสียง มันยังไม่พอ
ที่จะอธิบายให้เข้าใจถึงปัญหา หรือ เรื่องที่ต้องสื่อสารจริง ๆ

คำถามต่าง ๆ ต้องเฉพาะเจาะจงลงไปเลย
ไม่ต้องกว้างเป็นมหาสมุทร

บางครั้งงาน หรือ ปัญหาที่ต้องการแก้ไขหรือหา solution
มันใหญ่และซับซ้อนมาก ๆ
แนะนำให้แบ่งเป็นปัญหาย่อย ๆ
และคิดหา solution ย่อย ๆ ไป
เพื่อให้ได้ feedback ที่รวดเร็วขึ้น
อีกทั้งช่วยทำให้เราเข้าใจปัญหาได้ดีขึ้นอีกด้วย

สุดท้ายเมื่อได้ feedback ต่าง ๆ มาแล้ว
ต้องมีเวลาให้ทีม เพื่อนำ feedback เหล่านั้นมาปรับปรุงต่อไปด้วย
ได้ feedback แต่ไม่ได้เอามาใช้งาน ก็เท่ากับไม่มีนั่นเอง

จากที่เคย review หนังสือ Cloud Native Go ไว้นิดหน่อย
ตอนนี้ได้เปิดให้ download มาอ่านแบบฟรี ๆ จำนวน 3 บท
ประกอบไปด้วย

• Building Cloud Native service ด้วยภาษา Go
• เรื่อง Dependability ในการจัดการปัญหาต่าง ๆ ของระบบที่เกิดขึ้น
• เรื่อง Scalability รองรับการใช้งานที่สูงขึ้น และหาจุดคอขวดของระบบ

ลองไป Download มาอ่านกันดูครับ
น่าจะมีประโยชน์ต่อการพัฒนาระบบ

ปัญหาอย่างหนึ่งที่พบเจอบ่อย ๆ คือ
เมื่อข้อมูลในระบบมากขึ้นเรื่อย ๆ ตามอายุของระบบ
หรือเพิ่มตามจำนวนผู้ใช้งานที่สูงขึ้น
ผลที่ตามมาคือ ระบบที่เคยทำงานได้ดี กลับแย่ลงเรื่อย ๆ
ทั้งที่ไม่ได้เปลี่ยนแปลงอะไรเลย

การแก้ไขปัญหาก็มักจะแก้ไขที่ปลายเหตุคือ
ทำการเพิ่มเครื่อง หรือ ขยาย spec ของเครื่องให้ใหญ่ขึ้น
เพื่อให้ทำงานได้ตามปกติ
แน่นอนว่า เป็นวิธีการแก้ไขที่ง่าย เร็ว

แต่ ... ต้นเหตุของปัญหาที่แท้จริงคืออะไร ?
ได้ลงไปดู และแก้ไขที่ต้นเหตุมันไหม ?

หนึ่งในต้นเหตุคือ จำนวนข้อมูลสูงขึ้น
แต่ก็มีข้อมูลจำนวนมากที่ไม่ได้ใช้งาน หรือ ไม่ได้ใช้งานบ่อย ๆ

ยกตัวอย่างเช่น
ข้อมูลการซื้อขาย เรามักจะใช้งานข้อมูลใหม่ ๆ หรือไม่เกิน 1 ปีเสมอ
แต่สิ่งที่แปลกคือ เราต้องไปดึงข้อมูลไม่กี่เดือน หรือ ปีเดียว
มาจากข้อมูลทั้งหมด
คำถามคือ มันเป็นวิธีการที่ถูกต้องแล้วหรือ ?
ตรงนี้น่าคิดนะ
จะดีกว่าไหม ถ้าเรามีข้อมูลเท่าที่จะใช้งานก็พอ
ส่วนข้อมูลที่ใช้ไม่บ่อย ก็แยกไปอีกที่
ถ้าจะใช้ค่อยดึงหรือหาวิธีนำมาใช้งานแบบง่าย ๆ

วิธีคิด นำมาสู่ วิธีการแก้ไขปัญหา หรือแนวทางการพัฒนาต่อไป
ต้องคิด พิจารณามากยิ่งขึ้น

คำถามคือ เราจัดการปัญหานี้กันอย่างไร ?

มาดูกันหน่อยว่า library เกี่ยวกับ Machine Learning
ด้วยภาษา JavaScript นั้นมีอะไรให้ใช้บ้าง มาดูกัน

ประกอบไปด้วย

• Brain.js สำหรับ neural network ซึ่งจะทำงานบน GPU แต่ถ้าไม่มีก็จะทำงานแบบ pure JavaScript ให้อัตโนมัติ
• TensorFlow.js สำหรับ Machine Learning ซึ่งได้รับความนิยมสูงสุด
• Keras.js สำหรับ Deep Learning ทำงานบน GPU ซึ่งด้านหลังจะมีทั้ง TensorFlow และ CNTK(Microsoft Cognitive Toolkit) โดยที่หลาย ๆ บริษัทก็นำไปพัฒนาต่อยอด ทั้ง NetFlix และ NASA
• ยังมี library อื่น ๆ อีก เช่น ml5.js, Mind.js และ Covnet.js

จะเห็นได้ว่า JavaScript ก็เป็นอีกภาษาที่ทำเรื่องของ Machine Learning ได้ดีเช่นกัน

อ่านบทความเรื่อง How observability is redefining the roles of developers
ทำการอธิบายเรื่องของ Observability ของระบบ
ซึ่งถ้าเคยได้ยินจะพูดถึงเรื่องของ

• Application metrics
• Distributed tracing
• Centralized logging

แต่ปัญหาที่น่าสนใจคือ สิ่งต่าง ๆ เหล่านี้มักจะถูกสร้างเพื่อระบบ
หรือหน่วยงานใดหน่อวยงานหนึ่ง เช่น DevOps และ Ops เป็นต้น
แต่ไม่ได้ทำเพื่อทีมพัฒนาสักเท่าใดนัก

ดังนั้นจึงเป็นมาของคำว่า Developer Observability
ซึ่งระบบ Observability นั้นควรออกแบบมาจากความต้องการของทีมพัฒนาด้วย
เป็นเครื่องมือที่ช่วยให้นักพัฒนา
ง่ายต่อการพัฒนา
ง่ายต่อการหาข้อผิดพลาด
ตั้งแต่ source code ยันไปถึงการ deploy ที่ production เลย
ไม่ใช่ทำมาเพื่อส่วนใดส่วนหนึ่งเท่านั้น

ดังนั้นข้อมูลที่จัดเก็บมี 2 ประเภทคือ

• ข้อมูลการ request ของผู้ใช้งาน ที่เข้ามายังระบบ
• ข้อมูลของ source code เช่น ไฟล์ไหน บรรทัดอะไร commit อะไร เป็นต้น

ยกตัวอย่างข้อมูลของ log ต่าง ๆ ควรเป็นไปตาม demand หรือ ความต้องการ

เช่นในการพัฒนานั้นสามารถเขียน log ได้ในระดับ method เลย
แต่เมื่อขึ้น production mode แล้ว สามารถเลือกเฉพาะที่จำเป็นเท่านั้น
เพราะว่า พบบ่อยมากที่ log ที่จัดเก็บอ่านไม่รู้เรื่องเลย
แถมใช้ที่จัดเก็บเยอะจนเกินเหตุ
ทำให้ performance ของระบบลดลงไปอีก !!

หรือสามารถระบบลงไปได้เลยว่า
code แต่ละไฟล์ แต่ละบรรทัด ถูกใช้งานจาก feature ไหนบ้าง ?
ก็จะทำให้เห็นว่า code ที่เราเขียน และดูแลนั้น ถูกใช้งานจริง ๆ หรือไม่
จะได้ช่วยลดค่าใช้จ่ายในการดูแลรักษาต่อไป

อีกทั้งยังช่วยดูการทำงานหรือปัญหาต่าง ๆ ของระบบอีกด้วย

เช่น

• ปัญหาเรื่อง performance
• ปัญหาเรื่องของ security เช่น บรรดา library ต่าง ๆ ที่นำมาใช้งาน มีช่องโหว่หรือไม่ โดยการใช้ SBOM (Software Bill of Materials) มาใช้เช่นกัน

จะเห็นได้ว่าแนวคิด Developer Observability นั้น เพื่อลดการทำงานแบบ Silo

หรือการทำงานแบบต่างคนต่างทำงาน
นั่นคือ การทำงานแบบเป็นทีมนั่นเอง
แถมช่วยป้องกันปัญหาต่าง ๆ ไม่ให้เกิดบน production
หรือเมื่อเกิดปัญหาจะได้แก้ไขได้อย่างรวดเร็วอีกด้วย

เห็นเพื่อน ๆ แนะนำ Podman มานาน
วันนี้ว่าง ๆ เลยลองมาเล่นดูหน่อยว่าใช้งานกันอย่างไร
โดยที่ Podman เป็นเครื่องมือสำหรับการจัดการ image และ container
ตามมาตรฐาน Open Containers Initiative (OCI) นั่นเอง

การทำงานของ Podman นั้นเป็นแบบ standalone
ไม่ต้องมี background process สำหรับจัดการการทำงาน
ดังนั้นมาลองใช้งานแบบง่าย ๆ กันหน่อย

ขั้นตอนที่ 1 ติดตั้งตาม OS กันเลย

จากนั้นทำการสร้างและ start Podman ดังนี้

ขั้นตอนที่ 2 ทำการสร้าง image จาก Containerfile

มีรูปแบบเดียวกับ Dockerfile นั่นเอง

ทำการสร้าง image ดังนี้

ขั้นตอนที่ 3 สร้าง container และทดสอบใช้งาน

ทดสอบการใช้งานผ่าน url = http://localhost:9999
เพียงเท่านี้ก็สามารถใช้งาน Podman แบบง่าย ๆ ได้แล้ว

จากเอกสาร Microservices Anti-Patterns: A Taxonomy นั้น
ทำการสรุปเกี่ยวกับ Anti-patterns หรือแนวทางที่แย่ ๆ สำหรับ Microservices
ออกมาประมาณ 20 patterns ที่มักจะพบเจอ
มาดูกันว่ามี pattern อะไรบ้าง
เพื่อที่จะไม่ผิดกันอีก !!

จากเอกสารแบ่งเป็น 2 กลุ่มใหญ่ ๆ คือ

• Technical
• Organization

กลุ่มแรก Technical ประกอบไปด้วย

การทำงานภายในของแต่ละ service ที่จะมีปัญหา เช่น

• API versioning
• Hard code สิ่งต่าง ๆ ใน code เช่น endpoint, ip และ port เป็นต้น
• Service ใหญ่เกินไป
• การจัดการ logging
• แบ่ง service ผิด
• ขาดระบบ monitoring ที่ดี ตรงนี้น่าจะเรื่องของ Observability
• การ share ที่จัดเก็บข้อมูล
• การ share library ต่าง ๆ
• ออกแบบ endpoint แบบทำได้ทุกอย่าง ไม่ยอมออกแบบให้ทำงานแบบเฉพาะเจาะจง

ในเรื่องของการติดต่อสื่อสารระหว่าง service ก็เยอะเลย

• ที่เจอบ่อย ๆ เช่นกันคือ Cyclic dependecy คือการเรียกวนไปมา เกิดสปาเกตตี้ระดับ service ได้ง่าย
• มีการใช้ ESB (Enterprise Service Bus) เพื่อ share ข้อมูลและติดต่อกัน ซึ่งเป็นมาตั้งแต่ SOA แล้ว !!
• ไม่ใช้ API gateway
• เรื่องของ timeout น่าจะเป็นเรื่องของพวก resilience pattern นั่นเอง ตัวที่ได้รับความนิยมคือ circuit breaker
• มี protocol ในการติดต่อสื่อสารมากจนเกินไป
• ขาดความรู้และเครื่องมือที่เหมาะสม
• ใช้เทคโนโลยีที่ใหม่เกินไป หรือ ยังขาดความรู้ความเข้าใจต่อสิ่งนั้น ๆ เห็นเขาว่าดีก็เลยนำมาใช้

กลุ่มสอง Organization ประกอบไปด้วย

แนวคิด Microservice นั้น ไม่ใช่เพียงเรื่องของ architecture เท่านั้น
แต่ยังเกี่ยวข้องกับองค์กรอีกด้วย
ถ้าองค์กรไม่ปรับก็จะยิ่งส่งผลเสียเช่นกัน
มาดูว่า pattern อะไรบ้างที่ทำให้เกิดปัญหา

• ยังคงใช้โครงสร้างเดิม ๆ ที่ก่อให้เกิดปัญหา แต่ก็ยังทำแบบเดิมเพียงแต่เอา Microservice มาใช้ ผลที่ได้อาจจะแย่กว่าเดิมไปอีก อยากแก้ไขปัญหา แต่ยังใช้ process เดิม ๆ ที่ก่อให้เกิดปัญหาก่อนหน้านี้
• เรื่องของ Ownership ส่วนใหญ่จะเป็นแบบ strong ownership คือ ดูแลของใครของมัน ไม่สนใจภาพรวมของ product
• เป้าหมายคือ Microservice แทนที่ควรจะเน้นที่การแก้ไขหรือปรับปรุงระบบให้ดีขึ้นมากกว่า
• คิดว่า Microservice จะแก้ไขปัญหาทุกอย่าง ซึ่งผิดมาก ๆ
• รีบทำจนเกินไป เทียบได้กับ ยังเดินไม่ได้ แต่อยากจะบินแล้ว
• ขาดการทดสอบที่ดี หรือสภาวะแวดล้อมของการทดสอบไม่น่าเชื่อถือ
• ทีมหนึ่ง ๆ ดูแล service จำนวนมาก

น่าจะเป็นประโยชน์ต่อการนำไปใช้งานต่อไป

หนึ่งในสิ่งที่ได้แบ่งปันไปในงาน meetup ของสถาบัน IMC
เรื่องของแนวทางในการศึกษา และ ทำงานด้าน programming development
ว่าควรทำอย่างไรบ้าง ?
เป็นคำถามที่สามารถตอบได้หลายแนวทาง ตามประสบการณ์ของแต่ละคน

ในมุมมองเล็ก ๆ ของผม แนะนำให้เน้นไปที่ การแก้ไขปัญหา

เนื่องจากในสายงาน programming นั้นคือ การแก้ไขปัญหาเป็นหลัก
โดยปัญหาเหล่านั้นมักจะมาจาก ปัญหาที่มาจากคน
ว่าเราสามารถทำความเข้าใจ และ แก้ไขปัญหาได้อย่างไร

ดังนั้นเมื่อเราทำความเข้าใจเกี่ยวกับปัญหานั้น ๆ แล้ว
เราจึงลงมือแก้ไขปัญหาด้วย coding, technology
และเครื่องมือที่เหมาะสมกับปัญหานั้น ๆ (Right tool for the right job)

คำถามต่อมาคือ เรามีชุดของเครื่องมือ หรือ วิธีการที่มาแก้ไขปัญหาอย่างไร
มีเครื่องมือให้เลือกเยอะไหม
มีเทคนิคและเทคโนโลยีให้เลือกไหม
ไม่ใช่มีเพียงทางเลือกเดียวให้ใช้งาน แบบนี้ไม่น่าจะถูกต้องหรือเหมาะสมนัก !!

ในการศึกษา programming language ใหม่ ๆ ก็เช่นกัน
ควรเริ่มด้วยปัญหา จากนั้นลองพยายามแก้ไขปัญหานั้น ๆ
จะช่วยให้เรามีกรอบในการศึกษาที่ชัดเจน
ไม่ใช่ศึกษาไปทุกอย่างแบบไร้ทิศทาง

แต่การที่จะต่อยอด หรือ ศึกษาอะไรเพิ่มเติม ก็ต้องมีพื้นฐานที่แน่นด้วยเช่นกัน
ทั้งเรื่องของ วิธีการคิด การออกแบบ การเข้าใจปัญหา
ทั้งเรื่องของเครื่องมือที่นำมาใช้งาน

จึงเป็นที่มาว่า เราในฐานนะนักพัฒนา (Developer)
ก็ควรต้องพัฒนาทั้งตัวเอง ทีม ระบบ งานด้วยเสมอ

Continuous Learning ...