วันนี้เห็นว่าการจัดการ configuration ต่าง ๆ
ทั้ง service, route และ plugin ของ Kong API Gateway ผ่านเครื่องมือชื่อว่า decK
การทำงานก็ใช้งานผ่าน Kong Admin API นั่นเอง
มีขั้นตอนการใช้งานง่าย ๆ ดังนี้

• ทำการติดตั้งซึ่งเป็น CLI ปกติ
• การใช้งานก็ทำการ export configuration จาก Kong ออกมาเป็นไฟล์ YAML ปกติ
• ทำการจัดเก็บไฟล์ที่ได้ลง Version Control System ไว้
• เมื่อทำการแก้ไขไฟล์และบันทึกเรียบร้อย ให้ทำการ sync ผ่าน decK ได้เลย ทั้งการ diff และ sync ไปยัง Kong เองด้วย โดยทำการ sync แบบ 2 ทางให้อีกด้วย แถมยังทำการ validate, delete ได้อีก ตรงนี้สบายขึ้นเยอะ
• มองง่าย ๆ ได้ทำการ backup configuration ไปในตัวเลย
• อีกอย่าง สามารถนำไปใส่ใน Pipeline CI/CD ของการส่งมอบระบบงานได้เลย ช่วยลดการทำงานแบบ manual ลงไปได้เยอะ

สรุปแล้วเป็นอีกทางเลือกที่น่าสนใจ

จากเอกสารของทาง Google ว่าด้วยเรื่อง Cloud FinOps
ซึ่งเป็นแนวทางในการจัดการระบบงานบน Cloud
ให้สอดคล้องกันทั้งเรื่องของ technology, business และ finance นั่นเอง
ไม่ใช่แค่การใช้ technology หรือ innovation เพียงอย่างเดียว
ไม่ใช่แค่การลดค่าใช้จ่ายเพียงอย่างเดียว
แต่สิ่งที่ทำต่อส่งมอบคุณค่าเชิง business ให้ได้มาก
ไม่ใช่ทำเพียงครั้งเดียว แต่ต้องทำอย่างต่อเนื่อง
ไม่ใช่ทำเพียงคนเดียว แต่ต้องทำทั้งองค์กร

โดยที่ Cloud FinOps แสดง framework การทำงานดังรูป

แต่ก่อนอื่นในการใช้งาน Cloud ต้องเข้าใจก่อนว่า

• อะไรก็ตามที่ถูกสร้างขึ้นมา แล้วไม่ถูกใช้งานนั่นคือ สิ่งที่ไร้ค่า สิ้นเปลือง จำเป็นต้องลบทิ้งไป แต่ว่าเรารู้ไหม ? ซึ่งตรงนี้ต้องมี dashboard เพื่อแสดง
• ในการออกแบบ architecture ต้องเข้าใจเสมอ ว่าทุกอย่างมันคือค่าใช้จ่าย เช่น network เข้า region หรือ การเข้าถึงข้อมูล ดังนั้นใช้เมื่อต้องการ ไม่ต้องเผื่อ
• อีกอย่างถ้ามีการควบคุมมากเกินไปก็จะทำให้การทำงานไม่คล่องตัว ไม่เกิด innovation หรือไม่ควบคุมเลย ก็อาจจะทำให้เกิดขยะหรือสิ่งที่ไม่จำเป็นเกิดขึ้นมาจำนวนมาก ดังนั้นต้องจัดการให้สมดุลทั้งสองฝั่ง ดังนั้นจำเป็นต้องมีการสรุปตัวเลขต่าง ๆ ออกมาเพื่อใช้ในการตัดสินใจ

เรื่องการจัดการค่าใช้งาน สามารถอ่านเพิ่มเติมได้จาก Cost Management

สามารถอ่านเอกสารเพียวเติมได้

ในเอกสารได้เน้นเสมอในเรื่องของการ visible ส่วนการทำงานต่าง ๆ ออกมา
หรือ transparency นั่นเอง
รวมทั้งการทำงานร่วมกันของแต่ละฝ่าย

• ทั้ง Platform team ที่ต้องสร้างระบบแบบอัตโนมัติ เพื่อแสดงการทำงาน การใช้งาน และค่าใช้จ่ายต่าง ๆ ออกมา ในรูปแบบที่เข้าใจได้ง่าย เช่น dashboard หรือ report
• ทั้ง Workload team มีหน้าที่คอยดูแล และ optimize การใช้งานต่าง ๆ ใน Cloud และ share ประสบการณ์ต่าง ๆ ให้กับทีมอื่น ๆ เพื่อดูแลเองต่อไปได้ เนื่องจากเรื่องนี้ไม่ใช่ดูแลเพียงแค่ทีมเดียวเท่านั้น
• Business ก็ต้องดูด้วยว่า value ที่ได้ กับค่าใช้จ่าย ที่เสียไปมันคุ้มค่า สมเหตุสมผลไหม
• Finance แน่นอนว่าต้องเข้ามาในทุก ๆ ขั้นตอนการทำงานแน่นอน

แสดงการทำงานดังรูป

เป็นเรื่องที่น่าสนใจมาก ๆ สำหรับระบบงานที่อยู่บน Cloud ต่าง ๆ

Reference Websites

• Introduction to FinOps on Google Cloud

ทาง InfoQ มักจะสรุป trends ต่าง ๆ ของภาษา Java
ในเดือนธันวาคม 2022 ก็เช่นกัน
มีเรื่องที่น่าสนใจ ที่นักพัฒนา Java ควรรู้และเข้าใจ
เพื่อปรับตัวให้ทัน หรือ รู้ว่าควรจะทำอย่างไรต่อไปบ้าง
มาดูกันเลย

เริ่มต้นด้วย Java 8 มัน outdate ไปแล้วนะ หรือถูกเรียกว่า Legacy ไปแล้ว
รวมทั้งสถิติการใช้งานก็ลดลงอย่างต่อเนื่อง
ดังนั้นถ้าจะใช้งานก็ควรใช้ Java 11 หรือ 17 ไปเลย
ที่น่าสนใจคือ พบว่าการ migrate จาก 8 ไป 11 ยากกว่า 11 ไป 17 อีกนะครับ

ส่วน Java 18 และ 19 แนะนำให้ลองใช้งานกัน
เพราะว่ามี preview feature ที่น่าสนใจให้ลองใช้งาน เช่น

• Virtual Thread
• Structured Concurency
• Pattern matching for switch, record pattern
• Foreign function และ Memory API

และ Java 20 ก็จะออกมาในเดือนมีนาคม 2023 อีกด้วย

และล่าสุด GraalVM ก็จะเข้ามาใน OpenJDK อีกด้วย
น่าจับตามองอย่างมาก
ตรงนี้เราจะได้ยินคำว่า Native Java มากขึ้น
ยิ่งสาย Spring ยิ่งใกล้ชิดสุด ๆ

แน่นอนว่า ใครสาย Spring framework และ Spring Boot แล้ว
ใน version ล่าสุดใช้งาน Java 17 อีกด้วย
ตรงนี้และเป็น game changer อย่างหนึ่งเลย
คุณจะเลือกทางเดิม หรือ ทางใหม่ ?

สำหรับเรื่อง Container สำหรับ Java
ก็มีความพยายามจากหลาย ๆ ที่ เช่น Microsoft
เขียน guideline สำหรับการจัดการจอง memory และ garbage collection

อีกเรื่องที่พูดกันมากขึ้นคือ reflectionless frameworks 
ช่วยลดการใช้งาน memory และช่วยให้ startup time เร็วขึ้น
เช่นพวก Quarkus, Micronaut, Spring Native และ Jakarta CDI Lite 

ดังนั้นลองศึกษากันดูครับ ว่าจาก trend นี้
เราอยู๋ตรงไหนกันบ้าง และมีแนวทางการจัดการอย่างไรต่อไป

หลังจากที่ลองเล่น และ ศึกษาทำความเข้าใจกับ Spring Modulith มาสักพัก
จึงทำการสรุปการศึกษาไว้นิดหน่อย
ว่ามันคืออะไร ทำมาเพื่ออะไร มีเป้าหมายอย่างไรบ้าง
มาเริ่มกันเลย

Spring Modulith เป็น project ทดลอง
สำหรับการวางโครงสร้างที่ดีขึ้นสำหรับ Spring Boot 3
โดยเน้นที่การวางระบบ modular ที่ดี สำหรับระบบแบบ monolithic นั่นเอง
จะมี class และ annotation ใหม่ ๆ มาให้ใช้งาน
ที่ต้องเข้าใจก่อนคือ ไม่ใช้จัดการตาม Java Platform Module System (JPMS) นะ
แต่ใช้การ map java package ปกติ
กับใช้การส่ง event ใน Apring application สำหรับการติดต่อสื่อสารระหว่าง module
โดย event จะจัดเก็บใน Event Publication Registry
ซึ่งจะการันตีว่า event จะส่งถึง module แลายทางเสมอ
ช่วยทำให้แยกการทำงานของแต่ละ module ได้ง่ายขึ้น
รวมทั้งช่วยให้ load และ ทดสอบแต่ละ module ได้ง่ายขึ้น
ไม่ต้อง load class ในทุก ๆ module ขึ้นมา

Software Requirements

• Java 17
• Spring Framework 6
• Jakarta EE 9
• Spring Boot 3

ปล. ส่วน project Moduliths นี้เลิกทำไปแล้วนะ

ความพยายามของ project นี้
เพื่อช่วยให้ในระบบแบบ Monolithic นั้นจัดการ module ได้ดีขึ้น
ทำให้เกิด loose coupling ได้มากที่สุด
นั่นจะเอื้อหรือง่ายต่อการแยกไปคนละ service
ก่อนที่จะแยกเป็น service เล็ก ๆ เราทำการจัดการ module ได้ดีหรือยัง
ถ้าไม่แล้ว แยกก็ฉิบหายหนักกว่าเดิมไหม !!

ไว้เรามาดูตัวอย่างในการใช้งานใน blog ต่อไป

จากการพูดคุยเรื่อง tuning performance ของระบบนั้น
ก่อนอื่นอย่าเพิ่ง tuning หรือ optimize เยอะนัก
หรือทำจนเกินความจำเป็นเท่านั้นก่อน
แต่คนที่ทำต้องรู้ด้วยนะว่า สิ่งที่เลือกหรือ solution ในการแก้ไขปัญหา
จะไม่เกิดปัญหาในระยะอันใกล้
หรือมันทำงานได้ ตอบโจทย์ทาง business
ทั้งด้วย function การทำงานในสภาวะปกติ
และสถานที่การณ์ที่จำนวนผู้ใช้งานถึงจุดหนึ่ง

ดังนั้นทีมพัฒนาควรมีความรู้ในเรื่อง technology หรือ ภาษาโปรแกรม
ตลอดจน data structure และ algorithm ที่เลือกใช้
ว่าเป็นอย่างไรก่อน

จากนั้นระบบก็ต้องมีระบบ monitoring และ onservability ที่ดี
เพื่อดูการใช้งาน resource ต่าง ๆ
รวมทั้งพฤติกรรมการใช้งาน และการทำงานของระบบ
ว่าเป็นปกติหรือไม่ เพื่อเข้าไปถึงจุดเกิดเหตุได้อย่างรวดเร็ว

ส่วนนักพัฒนาถ้าถึงเวลาต้อง tuning performance ในระดับ code
จำเป็นต้องมีเครื่องมือช่วยทำ profiling ด้วย
รวมทั้งการยิง performance test เข้าระบบ
เพื่อดูผลการทำงาน ว่ารองรับได้หรือไม่
หรือจุดไหนคือ คอขวดของระบบ

ถ้าจะให้ดีควรมีชุดการทดสอบด้วย functional และ non-functional
ครอบคลุมในทุก ๆ feature ของระบบนั่นเอง

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

ในระดับ code ยังคงไม่พอ ต้องมองเรื่องของ architecture ของระบบด้วย
ว่าเป็นอย่างไร ทำงานอย่างไรบ้าง
ทั้งเรื่องของ caching data แบบ local, cluster หรือ remote
และเรื่องของ database ไม่ว่าจะเป็น RDBMS หรือ NoSQL
ว่าตัวไหนเหมาะกับระบบงานหรือ use case แบบใด
รวมทั้งเหมาะสมกับทีมด้วยนะ

ดังนั้นเรากลับมาดูสิว่า เราทำการ tuning performance ระบบอย่างไร
ที่สำคํญคือ เรารู้ว่าระบบงานที่เราพัฒนามีปัญหาเรื่อง performace ตอนไหน !!

เพิ่งกลับมาเขียนระบบงานด้วย Flutter และ Dart นิดหน่อย
ซึ่งแน่นอนว่า ต้องมาแก้ไขระบบเดิม
ก่อนที่จะแก้ไข อย่างแรกก็ต้องแก้ไข warning ต่าง ๆ ก่อน
สิ่งหนึ่งที่ปวดตับมาก ๆ คือ ระบบพัฒนาด้วย version เก่า
ซึ่งยังไม่บังคับเรื่อง Null Safty
อย่างที่สองคือ ไม่เขียน test กันอีก จะรู้ไหมเนี่ยว่าถูกหรือผิดเป็นไง
ก็ต้องทดสอบมือ และเขียน test level ต่าง ๆ กัน

เมื่อทั้งสองอย่าง พอไปวัดไปวาได้ ก็เริ่มต้นการแก้ไขและปรับปรุง
สิ่งที่เจอเยอะมาก ๆ คือ เรื่องของ const ในการประกาศ constructor ของ Widget
หรือเรื่องของ immutable นั่นเอง
ตรงนี้จะช่วยลดเรื่องการใช้งาน CPU และ Memory เยอะ
เพราะว่า จะทำการ reuse โดยไม่ต้องสร้าง object ใน memory ขึ้นมาใหม่
ใน Flutter มี performance UI profiling ให้ใช้ ก็ใช้ด้วย

อ๋อ ลืมไป พวก Opacity ก็ใช้น้อย ๆ หรือเท่าที่จำเป็นละ

จะมีคำแนะนำจากการใช้ lint tool
ใช้เครื่องมือแล้ว พอเจอ warning ก็แก้ไขกันด้วยละ
ไม่ใช่บอกแค่ warning มันยังทำงานได้อยู่ ไม่ต้องแก้ไข !!

ปัญหาต่อมาที่เจอคือ 3-party package ที่ใช้งานมันไม่ active แล้ว !!

ซึ่งตรงนี้นักพัฒนาที่ดี ควรต้องเลือกใช้งาน package ที่มีการ update เรื่อย ๆ
มี community ที่ดีพอ หรือ active หน่อย
อย่างน้อยควรจะ update เดือนละครั้งก็ยังดี
รวมทั้งดูเรื่องของการพัฒนา และ จำนวน issue ด้วย
เพื่อลดปัญหาในอนาคต
รวมทั้งอย่างลืม อย่าเลื่อน ที่จะ update version ใหม่ ๆ กันด้วย

อ่าน ๆ ไปเจอมาอีกตัวคือ Flutter Performance Tip: Keep Your Build Method Pure
ช่วยเพิ่ม performance ได้ดีมาก ๆ และอ่านง่ายขึ้นอีกด้วย

เรื่องของ state management ก็ไม่ได้ใช้อะไรอีก ปวดหัวไปอีก
ได้ปรับเปลี่ยนอีกแล้ว !!

ขอให้สนุกกับการ coding
แก้ไข เรียนรู้ และ ปรับปรุงต่อไป

หลังจากช่วงกลางปี 2022 นั้น
ทาง GitHub ได้ประกาศว่าจะปิด project และเลิกพัฒนา Text Edit ชื่อว่า Atom ไป
ซึ่งมีผลในวันที่ 15 ธันวาคม 2022 ที่ผ่านมานั่นเอง
มาจนถึงปี 2023 แล้ว ก็เลยนึกขึ้นได้
มีใครบ้างที่เคยใช้ หรือ ยังใช้งาน Atom อยู่

โดย Atom นั้นพัฒนาด้วย Electron
เป็น text editor ที่หลาย ๆ คนน่าจะเคยใช้งานกัน

แต่ถ้าใครยังคงชอบการใช้งาน Atom อยู่
ก็มี project ใหม่ที่เหมือนกันเลยนั่นก็คือ Pulsar มาให้ใช้เทน
ลองใช้งานกันดู

RediSearch เป็นอีกหนึ่ง module ของ Redis
ช่วยทำให้เราสามารถทำ ful text search ใน Redis ได้
โดยมี feature ที่น่าสนใจดังนี้

• Query แบบ single และ multi-field ได้
• Filter และ Sorting ได้ครบ
• Indexing
• Aggregation

การทำงานอยู่ภายใต้ความสามารถของ Redis นั่นเอง

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

เริ่มด้วยการติดตั้ง Module Redisearch ไปยัง Redis
หรือเพื่อความง่ายใช้งานผ่าน Docker ไปเลย ดังนี้

ทำการเพิ่มข้อมูลในรูปแบบของ Hash

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

ที่สำคัญคือ เมื่อเราทำการเพิ่มข้อมูลเข้าไปใหม่
ตัว RediSearch จะทำการสร้าง index ใหม่ให้แบบอัตโนมัติ

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

เห็นคำว่า Zero-ETL ผ่าน ๆ ทาง social network มานิดหน่อย
ก็เลยมาหาดูหน่อยว่า มันคืออะไร
ถามทาง ChatGPT ก็บอกว่า ไม่รู้จัก

ส่วน product ก็มีออกมาให้ลองใช้ ทั้งจากฝั่ง Google และ AWS คือ

• AWS :: ข้อมูลจาก Aurora ไปยัง Redshift
• AWS :: Redshift กับ Apache Spark
• Google :: สามารถทำการ query ข้อมูลจาก BigTable ผ่าน BigQuery ตรง ๆ ได้เลย

ดังนั้นมาดูกันหน่อยว่ามันคืออะไรกัน ?

ก่อนอื่นต้องทำความเข้าใจกับ ETL (Extract Transform Load)

คือกระบวนการในการย้ายข้อมูลจากที่หนึ่งไปอีกที่หนึ่ง
ซึ่งอาจจะมี datasource ต่างกัน
ซึ่งอาจจะมี format ของข้อมูลต่างกัน
ดังนั้นเราจำเป็นต้องการตัวกลางเพื่ออ่านข้อมูล แปลงข้อมูลให้ตรงตามปลายทาง
และถ้ามีความซับซ้อนสูงอาจจะต้องมา data pipeline ขึ้นมา
หรือแต่ละขั้นตอนจะเรียกว่า ETL แสดงดังรูป

แต่เมื่อนำมาต่อกันจนเกิด Data pipeline ดังรูป

ดังนั้นในการใช้งาน ETL ไปจนถึงการสร้าง Data pipeline
ต้องการคนที่มีความรู้ความสามารถ
ต้องการค่าใช้จ่ายที่สูงขึ้น
ยิ่งข้อมูลมี datasource และ format ที่แตกต่างกัน
ยิ่งก่อให้เกิดความซับซ้อนสูงขึ้น

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

แล้วเป็นอีกแนวทางหนึ่งในการสร้าง data platform
ที่ตอบสนองความต้องการให้รวดเร็วขึ้น

Reference Websites

• So What’s All This Talk about Zero-ETL Integration?
• Zero ETL a New Future Of Data Integration
• Data pipeline

ในปี 2022 ที่ผ่านมา พบว่ามีแนวคิดต่าง ๆ ออกมาเพียบเลย
หรืออาจจะเรียกว่า buzzword ก็ได้
มาดูหน่อยสิว่ามีคำว่าอะไรบ้าง ?

เริ่มจาก 2 ตัวแรกคือ Microservices และ Microfrontend

ซึ่งเป้นแนวคิดคล้าย ๆ กัน แต่ Microservices หลาย ๆ คน
จะเน้นไปที่ Backend มากกว่า
ส่วน Microfrontend จะเน้นไปที่ Product มาก ๆ
แต่หลาย ๆ คนไปเน้นที่ Frontend เป็นหลัก
ทำให้ทั้งสองแนวคิดแยกกันอย่างสิ้นเชิง !!
ทั้ง ๆ ที่สองแนวคิดมีแนวทาง หรือ เป้าหมายเดียวกัน
นั่นคือแยกส่วนการทำงานให้เป็นอิสระต่อกัน ทั้งพัฒนา ทดสอบ deploy และ scaling

แน่นอนว่า ในการออกแบบเพื่อที่จะแบ่งการทำงาน
จะมีการพูดถึง DDD (Domain-Driven Design) เป็นอย่างมาก

ปล. สิ่งที่น่าสนใจสำหรับ 3 สิ่งนี้ที่เหมือนกันคือ
คนที่ออกแบบจะเยอะ
คนพัฒนา ทดสอบ deploy และดูแล น้อยเช่นเดิม !!
มันแปลก ๆ ไหมนะ

ต่อมาในฝั่งของ Application structure ที่พูดถึงกัน

ถ้าแต่ก่อนเราจะรู้จักพวก MVC (Model-View-Controller) เป็นหลัก
แต่ถ้าปัจจุบัน เราต้องพูดถึง

• Clean Architecture
• Hexagonal Architecture
• Onion Architecture

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

ต่อมาเรื่องของ Service Mesh และ Data Mesh

เมื่อมีการแบ่ง service ออกมาเป็น service เล็ก ๆ จำนวนมาก
ไม่ว่าจะ micro, nano, mini service อะไรก็ตาม
ดังนั้นเราจะจัดการอย่างไร
ในเรื่องของ network ระหว่าง service เช่น routing, load balance และ service discovery เป็นต้น
ตลอดจนเรื่องของ observability, security และ deployment/scaling
ดังนั้นจึงเกิดเครื่องมือในการจัดการเข้ามาในโลกของ service
เรามักจะเรียกว่า Service Mesh นั่นเอง

แน่นอนว่ามีเครื่องมือ ให้ใช้งานแน่นอน
ทั้ง Istio, Linkerd, Kuma และ Consul เป็นต้น

ในฝั่งของ Data ก็ไม่ต่างกัน จึงเกิด Data Mesh ขึ้นมาอีก !!

ในฝั่ง Security ก็มีเรื่องของ Zero Trust มาอีก
หรือพวก Security by Design
เยอะดีมาก ๆ

หรือในสาย *Ops ก็ไม่น้อยหน้า

มีทั้ง

• DevOps
• DevSecOps
• DevTestOps
• DevPerfSecOps
• DevPerfSecFinCloudPlatformOps
• BizDevOps
• UxOps, UIOps

เป้าหมายของแนวคิดต่าง ๆ เหล่านี้คืออะไร ?
พยายามให้ทำงานร่วมกัน ไปข้างหน้าด้วยกัน
ไม่ใช่ต่างคนต่างทำงานของตนเองเท่านั้น (Silo)
ว่าแต่เราเอามาใช้กันอย่างไร
แก้ไขปัญหา หรือ สร้างปัญหา ตรงนี้น่าคิดนะ

ในการสร้าง environment ของระบบงาน
ไม่ว่าจะเป็น dev, test, QA, SIT, UAT ใด ๆ ก็ตาม
ส่วนใหญ่มักจะถูกสร้างและใช้งานยาว ๆ กันไป
ดังนั้นการจะสร้างแต่ละครั้ง ต้องมี process ที่เยอะ
จะดีกว่าไหมถ้าเรามี environment แบบที่เรียกว่า Ephemeral Environment

มาทำความรู้จักว่า Ephemeral Environment คืออะไร

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

• สร้างมาเพื่อพัฒนา และ ทดสอบระบบงาน
• สร้างมาทดลองอะไรบ้างอย่าง
• สร้างมาเพื่อรองรับการใช้งานแบบสูง ๆ หรือที่เรียกว่า spike

โดยในการสร้างและลบ environment ต่าง ๆ เหล่านี้
จะไม่มีผลกระทบต่อภาพรวมของระบบใด ๆ

ชื่ออื่น ๆ ของ Ephemeral Environment ก็เช่น

• Dynamic
• Preview
• On-demand

คุณสมบัติคร่าว ๆ ของ Ephemeral Environment ประกอบไปด้วย

• สร้างได้แบบอัตโนมัติตามความต้องการ หรือ event ต่าง ๆ เช่น สร้าง test environment ขึ้นมาเพื่อทดสอบในทุก ๆ PR ที่ส่งเข้ามา เพื่อทำการ pre-approve ในเบื้องต้น
• แยกออกมาจาก development และ production นั่นหมายความว่าการสร้าง ลบ และ load ต่าง ๆ จะไม่ส่งผลกระทบต่อ environment อื่น ๆ
• มีรูปแบบคล้ายกับ production เพื่อทำให้มั่นใจมากขึ้น ทั้ง data, config, library และ ระบบต่าง ๆ ที่ต้องทำงานด้วย
• มีความปลอดภัยในการใช้งาน

เป้าหมายหลัก ๆ ของ Ephemeral Environment

• ประหยัด resource และช่วยลดเวลา นั่นคือ ค่าใช้จ่าย หรือไม่
• ช่วยให้ทีมพัฒนาส่งมอบระบบงานได้รวดเร็ว และ มีคุณภาพมากขึ้น
• เกิดการทำงานร่วมกันของแต่ละส่วนเป็นอย่างดี ตั้งแต่คนคิดยันการ deploy ไปเลย
• ทดสอบได้ตลอดเวลา หรือ ทุก ๆ เหตุการณ์ที่เกิดขึ้นและสนใจ (Continuos Testing)

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

ว่าแต่ปัจจุบันเราทำแบบนี้กันไหม ?

Reference Websites

• Preview Environments

ต่อจากที่แนะนำ Spring Modulith ไปแล้ว
มาลองลงมือเขียน code ตามแนวทางนี้หน่อยว่าเป็นอย่างไร
มีเครื่องมืออะไรที่น่าสนใจบ้าง

ขั้นตอนที่ 1 สร้าง Project ด้วย Apache Maven Project

โดยทำการเพิ่ม library ของ Spring Modulith ในไฟล์ pom.xml ดังนี้

ขั้นตอนที่ 2 ทำการออกแบบสิ่งที่ต้องการ

จะสร้างมา 3 module โดยที่ Module 1 เรียกใช้งาน Module 2 และ 3
โดยแยก package ตามแต่ละ module ไป
ใน Spring Modulith จะทำการ injection ผ่าน constructor ดังนี้

ขั้นตอนที่ 3 ทำการเขียน test สำหรับ Spring Modulith

จากนั้นทำการ run test ผลที่ได้ตามมา
คือ UML diagram ของทั้ง project และแยกแต่ละ module
โดยสามารถเปิดดูได้จาก PlantUML

Diagram ของแต่ละ Module

หรือสร้าง diagram แบบอื่น ๆ ได้อีก ดูที่ Document
เป็นสิ่งที่ดีมาก ๆ ช่วยให้เราสร้างเอกสารของระบบงานแบบ up-to-date อยู่ตลอดเวลา

ในแต่ละ module สามารถมี internal class หรือใช้เฉพาะภายใน module
สามารถสร้าง class/interface ใน package ย่อยชื่อว่า internal

ขั้นตอนที่ 4 สามารถดู tracing ของการเรียกระหว่าง module ผ่าน Zipkin ได้ด้วย

ต้องทำการเพิ่ม library ในไฟล์ pom.xml
ประกอบไปด้วย

• Zipkin
• Tracing
• Actuator
• Observability

ดังนี้

จากนั้นทำการ run และดูผลใน Zipkin จะเป็นดังนี้

เพียงเท่านี้ก็เริ่มใช้งานแบบง่าย ๆ ได้แล้ว
ลองเล่นกันดูครับ
ขอให้สนุกกับการ coding !!

ตัวอย่างของ source code

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

วิธีการที่ผมชอบใช้งานประกอบไปด้วย

วิธีการแรก จะใช้งาน Email & SMS testing ด้วย Mailosaur

เราสามารถสมัครสมาชิก จะได้ domain ของ email มาให้
แล้วเราสามารถสร้าง account ใด ๆ ขึ้นมาได้เลย แต่ใช้ domain ที่ได้รับมา
จากนั้นสามารถส่ง email เข้ามาได้เลย
จากนั้นทาง Mailosaur จะเตรียม API และ Client library
ในการเข้าถึง inbox แบบง่าย ๆ
ทำให้เราสามารถเขียนชุดการทดสอบแบบอัตโนมัติ
เพื่อเข้ามาตรวจสอบข้อมูล email
และทำการ parse email เพื่อจัดการต่อได้แบบง่าย ๆ

วิธีการที่สอง ใช้งาน Fake SMTP server

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

• Fake SMTP Server
• Mountebank โดยใช้งาน SMTP

ทั้งสองวิธีการนี้ น่าจะช่วยให้การทดสอบดีขึ้น
ลดความเสี่ยงต่าง ๆ ได้ดียิ่งขึ้น

ปัญหาในการใช้งาน Docker command ใน GitLab CI
โดยที่ runner จะเป็น docker
ซึ่งใน pipeline จะใช้งาน image ชื่อว่า docker:dind

ปัญหาที่เจอคือ

วิธีการแก้ไขปัญหา (ไม่ใช่ลบและสร้างใหม่ หรือ restart)

ปัญหาคือเรื่อง version ของ docker in docker ที่ใช้งาน
กับการปิด TLS ไปก่อน !!
ก็จะพอช่วยให้งานไปต่อได้

ในส่วนของ TLS ควรจัดการให้ดีตามนี้ CA Certificate in GitLab CI with dind service

ใน Elasticsearch 8.6.0 นั้น ได้เพิ่ม index ชนิดใหม่ขึ้นมา
ชื่อว่า time_series ซึ่งอยู่ในสถานะ tech preview
เพื่อใช้สำหรับเก็บข้อมูลในลักษณะของ time series
โดยจะทำการเรียงลำดับตามเวลาของข้อมูลหรือ document ที่สร้างด้วย timestamp
และจะทำการแยกเก็บตาม index ย่อย ๆ (backing index) ให้เองแบบอัตโนมัติ

ผลที่ได้ตามมาจาก index ประเภทนี้คือ

• ลดพื้นที่ในการจัดเก็บลงไป 20-40%
• ช่วยทำให้จัดการข้อมูลง่ายขึ้น
• ในการค้นหาจะ route ไปยัง index ที่จะเก็บให้อัตโนมัติ
• การค้นหาและวิเคราะห์ (aggregation) จะเร็วและมีประสิทธิภาพมากยิ่งขึ้น

แต่มีข้อดีย่อมมีข้อเสียนั่นคือ

• ไม่สามารถเพิ่มข้อมูลเข้าไปยัง backing index ดดยตรงไม่ได้
• ไม่สามารถใช้ index operation เหล่านี้ได้ delete, clone, split และ shrink
• สร้างมาสำหรับ append เท่านั้น ไม่สามารถแก้ไขข้อมูลแต่ละ document ได้ แต่สามารถใช้ update/delete by query ได้

เป็นอีกหนึ่ง feature ของ Elasticsearch ที่น่าสนใจ
สำหรับการเก็บข้อมูล time serie ทั้ง log และ metric เป็นต้น

ใน Go 1.20 นั้นมีการเปลี่ยนแปลงตัวภาษานิดหน่อย
หนึ่งในนั้นคือ การ convert ข้อมูลจาก slice มาเป็น array
ซึ่งเป็นความรู้ใหม่เล็ก ๆ ที่น่าสนใจ

ใน version 1.19 นั้น code ชุดนี้จะ compile ไม่ผ่าน

แต่ใน version 1.20 นั้นจะ run ผ่าน

แต่ปัญหาหรือ panic จะเกิดขึ้นเมื่อกำหนดขนาดของ array ใหญ่กว่า slice ต้นทาง

ส่วนการแก้ไขทั้ง slice และ array จะไม่ส่งผลกระทบแก่กัน
เนื่องจากทำการ copy value ไปเท่านั้น
แต่ถ้าต้องการให้เปลี่ยนข้อมูลที่ slice หรือ array แล้ว
ต้องการให้ทั้งสองเปลี่ยนไปด้วย
จะต้องทำการ convert ด้วย array pointer ดังนี้

การเปลี่ยนแปลงเรี่องนี้มาพร้อมกับ unsafe package นั่นเอง

Reference Websites

• What’s New in Go 1.20, Part I: Language Changes

เช้านี้เห็นอีกหนึ่งแนวคิดที่น่าสนใจ เกี่ยวกับการนำ ChatGPT มาใช้งาน
โดยเห็น project ชื่อว่า Kubernetes ChatGPT Bot ใน Product Hunt
เป็นการประยุกต์ใช้ที่น่าสนใจ
มีโครงสร้างการทำงานดังนี้

• เมื่อเกิดปัญหาต่าง ๆ ขึ้นมาในระบบ จะทำจัดเก็บไว้ใน prometheus
• ทำการสร้าง rule ใน prometheus alert ไว้ ใน metric ที่สนใจ
• เมื่อมีปัญหาที่ตรงกับ rule จะทำการส่ง noti ไปยัง Slack
• ใน Slack จะมีถามว่า จะให้ Ask ChatGPT หรือไม่ เพื่อช่วยหารายละเอียดของปัญหานั้น ๆ ว่าคืออะไร เกี่ยวกับอะไร มีสาเหตุจากอะไรได้บ้าง

แสดงการทำงานดังรูป

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

อีกหนึ่ง extension ที่น่าสนใจใน VSCode นั่นก็คือ CodeGPT
ซึ่งก่อนใช้งานต้องไปสร้าง API Token มาก่อน
จากนั้นก็ใช้งาน โดยประกอบไปด้วย

• การ Generate codeให้จากการเขียน comment
• การอธิบาย code ให้ (Explain code)
• การ refactoring code
• ถามคำถามต่าง ๆ
• ให้เขียน document ให้
• Analyze หรือ วิเคราะห์ code ให้ เพื่อหาปัญหา

ลอง Download มาใช้งานกันดู CodeGPT extension
เป็นอีกตัวช่วยที่นำ CodeGPT มาประยุกต์ใช้งาน

จาก Podcast เรื่อง API Evolution without Versioning with Brandon Byars
แค่เห็นหัวข้อก็น่าสนใจแล้ว
เลยลองฟังไปขณะที่นั่ง (ยืน) รถไฟฟ้าไปทำงานหน่อย
ที่ดีอีกอย่างคือ มีการ transcript ของ Podcast ให้อ่านไปด้วย
จึงทำให้ได้ทั้งฟัง และ อ่าน ไปทั้งคู่
มาดูกันว่า มีอะไรที่น่าสนใจบ้าง ?

จาก Podcast เรื่องการจัดการ API ที่เปลี่ยนไป
โดยไม่ต้องทำ versioning นั้นทำอย่างไรบ้าง ?

โดยปกติการออกแบบ API นั้น
เมื่อมีการเปลี่ยนแบบ major change หรือเปลี่ยนแปลงมาก ๆ
มักจะมีการจัดการ versioning เพื่อให้ผู้ใช้เดิมสามารถใช้งานได้
และผู้ใช้งานใหม่ก็ไปใช้ version ใหม่
รวมทั้งผู้ใช้งานเก่าก็ค่อย ๆ เปลี่ยนไปใช้ version ใหม่
แต่ทุกอย่างไม่ใช่ได้มาแบบฟรี ๆ หรือ ง่ายเลย
ทั้งจากทางฝั่งผู้ให้บริหารและผู้ใช้

ฝั่งผู้ให้บริการต้องดูแลหลาย ๆ version ไปตลอดหรือไม่ ?
ฝั่งผู้ใช้งานจะเปลี่ยนอย่างไร ต้องใช้เวลา คน อย่างไร ?
ทั้งสองส่งผลกระทบต่อ business/product อย่างไร ?

พูดถึงเครื่องมือช่วยในการทดสอบเรื่อง API คือ Mountebank

ซึ่งมีรูปแบบของการจัดการ API ที่เปลี่ยนแปลงไป
โดยมี 6 รูปแบบที่น่าสนใจ ประกอบไปด้วย

• change by addition
• multi-typing
• upcasting
• nested upcasting
• downcasting
• hidden interfaces

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

ก่อนหน้านี้แนะนำ Bun ไปแล้วนิดหน่อยซึ่งมีความเร็วสูงมาก ๆ
ตอนนี้ได้ปล่อย version 0.5 ออกมาให้ใช้งานกัน
โดยมีความสามารถต่าง ๆ ดังนี้

• สนับสนุน workspace แล้ว เมื่อทดสอบกับ project Remix พบว่าเร็วว่า npm และ yarn มาก ๆ แต่ตรง path ยังไม่สนับสนุน globs pattern นะ
• มี Bun.dns สำหรับการ resolve domain
• สนับสนุนการเปิด socket connection ช่วยให้พวก database driver พัฒนาได้สบายขึ้น ยกตัวอย่างเช่น Postgres.js , mysql2 และ redis
• สนับสนุน node:readline ช่วยให้สนับสนุนการทำงานผ่าน CLI ได้ง่ายขึ้น
• ปรับปรุงการทดสอบด้วย wiptest ซึ่งยังคงพัฒนาอยู่ เพื่อให้ทำงานร่วมกับ jest ได้
• สนับสนุน HTTPS_PROXY แล้ว

เรื่องสุดท้ายคือ performance ที่ดีขึ้น ในแต่ละ API