TW Tech Radar #23 มีอะไร cool ๆ บ้าง
หลังจากไม่ได้ update technology ใหม่ๆมาซักพักนึง พอดีกับที่ Thoughtworks radar เล่ม 23 ออกใหม่เร็วๆนี้ เลยอยากมาสรุปให้สำหรับคนที่สนใจ
จริงๆเห็นว่ามีหลายคนได้เขียน review ฉบับนี้เเล้ว เลยขอออกตัวก่อนว่านี่ไม่ใช่ full review ของฉบับนี้ แต่ผมจะสรุปเฉพาะสิ่งที่เห็นว่าน่าสนใจ (สำหรับผม) เท่านั้น
Technique
Dependency drift fitness function (Adopt)
สำหรับคนที่ไม่คุ้นกับคำว่า fitness funtion มันคือ concept ของการมี executable fuction ที่ใช้เช็คว่า application หรือ architecture ของเรามันทำงาน หรือ อยู่ในรูปแบบที่เราต้องการจริงๆหรือไม่ (เช่น unit test เป็น fitness function ของ functionality ของ code เรา)
technique นี้คือการมี automated check ว่า dependencies ของ application เรานั้นมัน outdated หรือว่ามี vulnerability ต่างๆที่ต้อง update หรือยัง
Tool ที่ถูก mention ในที่นี้ก็คือ Dependabot ส่วนตัวที่ผมเคยใช้ก็จะมีตัว OWASP dependency check ที่คอยตรวจจับ vulnerability ของ dependency หรือ Twistlock ที่ช่วยเช็ค dependency ของ running container
Run cost as architecture fitness function (Adopt)
ด้วย model pay as you go ของ cloud provider ถ้าหากเราไม่มี technique หรือ process ที่ช่วยในการ track, monitor, control cost ของ cloud architecture เราอาจจะเจอ surprise ตอนบิลมาได้
ซึ่ง cost พวกนี้อาจเกิดจาก design architecture ที่ overkill หรือมากเกินจำเป็น หรือ usage ที่คาดเดาไม่ได้ เนื่องจาก cloud provider เก็บ cost จากหลายๆปัจจัย ไม่ใช่แค่ค่า physical machine อย่างเดียว ค่า network traffic, storage ต่างๆก็เป็น cost เช่นกัน
ซึ่งหลายๆ cloud provider ก็ช่วย provide tool ในการ monitor และ track cost ซึ่งอาจรวมไปถึงการ set threshold ไม่ให้เกิน xxxx บาท อยู่เเล้ว ซึ่งเราก็ใช้อยู่ในปัจจุบัน
แต่มีประโยคนึงที่ผมคิดว่าน่าสนใจในบทความคือ
teams can observe the cost of running services against the value delivered
ผมยังไม่ค่อยจะเห็นการ run cost analysis comparing with value delivered มากนักในปัจจุบัน ซึ่งทีมอาจจะต้องช่วยกันคิดถึง business value delivered ว่ามันคุ้มค่ากับ architecture ที่ implement ไปหรือไม่
Security policy as code (Adopted)
security policies ต่างๆ เช่น access control policies, network security policies ควรถูก define ให้ชัดเจนด้วย code
concept นี้คือ concept เดียวกับ Infrastructure As a Code แต่เป็นในมุม security ข้อดีของมันก็คือ การ set policies ต่างๆก็จะถูก version controlled ทำให้ง่ายต่อการ audit เเละ reproduce รวมถึงการแชร์ policies implementation ระหว่างทีมเช่นกัน
tool ที่ถูกพูดถึงคือ Open Policy Agent ส่วน ณ ปัจจุบันเราก็มีการ implement network rule ต่างๆ เช่น allowed ip range, VNET policies และ network security ต่างๆ ด้วย code ในการ set up Kubernetes cluster อยู่เเล้ว
Distroless Docker images (Trial)
technique นี้ถูก mark เป็น Trial แต่ค่อนข้าง practical มากโดยหลักการคือ ปกติแล้วการ build docker image เราจะ concern กับเรื่อง size ของ image เเละ security ซึ่งเราก็จะมี tool เช่น twistlock ที่เอาไว้ใช้ scan docker image เพื่อเช็คเรื่อง security และใช้ distribution เล็กๆ เช่น ubi หรือ alpine
“Distroless” images contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.
Distroless image คือ image ที่มีแต่ app ของคุณกับสิ่งที่จำเป็นเท่านั้น จะไม่มี program อื่นๆเลย ทำให้ size มันเล็ก เเละมีของน้อยลง security concern ก็จะ limit เฉพาะกับ app ของเราเท่านั้น
Event interception (Trial)
Technique นี้น่าสนใจมากๆ โดยหลักการของมันคือ
ปกติแล้วการที่เราจะหนีจาก legacy system วิธีที่หลายคนคุ้นเคยคือการทำ CDC (Change Data Capture นะ ไม่ใช้ Crystal Design Center 😂) ซึ่งมันคือการ capture ข้อมูลที่เกิดขึ้นเเล้วจาก source system เพื่อทำสำเนาจาก legacy ไปใช้ใน Microservices
แต่ Event interception คือการ “Fork Ingress” หรือการ copy event / message ขาเข้า หรือแม้แต่การ fork HTTP request เพื่อช่วยในการค่อยๆ implement Microservices ควบคู่ไปจนค่อยๆ retire legacy บางส่วนได้
ซึ่งผมมองว่ามันช่วยให้การทำอีก technique ที่จะเขียนถัดมาซึ่งคือ Parallel run with reconciliation (Trial) ง่ายขึ้น
Parallel run with reconciliation คือการ รันทั้ง legacy และ new system ควบคู่กันไปเลย แล้วนำ result มาเทียบกัน เพื่อดูว่า new system นั้น implement ได้ถูกต้องตามที่ต้องการหรือไม่ เพื่อเพิ่ม confident ในการ move ออกจาก legacy
Platform
Azure DevOps (Trial)
ADO ถูกพูดถึงเป็นหัวข้อแรกเนื่องจาก platform มี development aspect ค่อนข้างครบ ทั้ง Git Repos , CI/CD , artifact repository และ backlog management
ซึ่งโดยส่วนตัวกับงานปัจจุบันก็ได้ใช้ Azure DevOps อยู่ก็ค่อนข้างเห็นด้วย โดยเฉพาะถ้า Cloud provider ที่ใช้เป็น Azure Cloud จะทำให้ทำงานได้สะดวกมากๆด้วย concept ของ service connection ต่างๆ
Debezium (Trial)
Highlight ของ platform คงเป็น Debezium ซึ่งเป็น CDC platform ที่ช่วย stream database change ไปลง Kafka Topic ให้ เเละในบทความเขียนว่ามี connector ของ db ดังๆเช่น Postgres, MongoDB, MySQL
หลังจากนี้อาจจะต้องลองไปเล่นดู ถ้ามัน work อาจจะช่วยลด effort ในการทำ event driven architecture ได้เยอะเลยทีเดียว
Backstage (Assess)
จากที่ได้อ่าน platform นี้ดูเหมาะกับ enterprise ค่อนข้างมาก
Backstage เป็น platform ที่ใช้สร้าง Developer portal เพื่อสร้าง unity ให้ developers ในบริษัท โดยรวม tool, service, document เอาไว้ให้ manage ได้ง่าย
จาก feature ที่ list ไว้ ค่อนข้างสนใจ Tech Doc และ software template มากๆ เพราะคิดว่าเป็นสิ่งที่ team ตามหามานานว่าจะ manage ของที่มี และ distribute knowledge ยังไง
K3s (Assess)
บทความบอกว่าเป็น Kube ฉบับมินิ เหมาะสำหรับการทำ IoT และ Edge computing เพราะลดของที่ไม่จำเป็นออก หากใครกำลังทำ IoT อยู่อาจจะลองศึกษาเพิ่มเติ่มกับเจ้าตัวนี้
Tools
Helm (Adopt)
คงไม่ต้องพูดอะไรมากสำหรับ Helm ซึ่งแทบจะกลายเป็น De facto สำหรับ Kube package manager ไปแล้ว ใครที่ยังไม่รู้จัก Helm ก็ควรจะเริ่มศึกษาได้แล้ว
Trivy (Adopted)
Trivy เป็น open-source vulnerability scanner ซึ่งมาในรูป stand alone binary ทำให้เรา incorporate มันเข้าไปใน pipeline ของเราได้ง่ายมาก โดยส่วนตัวยังไม่เคยใช้เนื่องจาก environment ปัจจุบันใช้ของเสียตังไปแล้ว แต่ถ้าต้องทำใช้เองแน่นอนว่าคงจะอ่านเจ้านี้อย่างจริงจังให้เหมาะกับ poor-man strategy แบบเราๆ
Concourse (Trial)
Concourse เป็น CD pipeline tool ที่สามารถ deploy production software ไปยังหลายๆ environments ได้ ในบทความ mention ว่าหลายๆทีมของ TW ได้ใช้เจ้า Concourse และชอบมันเป็นอย่างมาก โดยส่วนตัวพึ่งเคยได้ยิน หลักจากนี้จะไปศึกษาเพิ่มเติมสำหรับ tool นี้ ถ้ามันเจ๋งก็จะมาเขียนเล่าให้ฟังแยกจากบทความนี้
Pitest (Trial)
เราเขียน Unit test ให้กับ Production code ของเรา เเล้วเราจะรู้ได้ยังไงว่า test ที่เราเขียนมันทำงานได้ดี? เราก็ test มันสิ!! Testception!!
โดยหลักการที่พูดถึงเรียกว่า Mutation testing ซึ่งใช้ evaluate ตัว test case เอง
mutation test จะไปทำการลองแก้ source code แล้วลอง run test suite ของเราอีกที ถ้าแก้ code เเล้ว run test เดิมแต่ดันผ่าน แปลว่า ……….. นั่นละครับ
Terragrunt (Trial)
จากบทความก่อนหน้า เราพูดถึง Terraform ว่าเป็น tool ที่ใช้ในการจัดการกับ Infra ของเราด้วย code
Terragrunt เป็น tool ที่เข้ามาช่วยในเรื่อง reusability เเละการ manage Terraform module ที่เรามีในกรณีที่มีการใช้ Module ที่แชร์กันได้อย่างมีประสิทธิภาพ
Tfsec (Trial)
software code เราต้องมีการ run code analysis เพื่อหา vulnerabilities ฉันใด infracode เราก็ควรจะต้องมีการ run static code analysis ฉันนั้น
โดย Tfsec จะทำการอ่าน Terrafrom template code เเละ scan หาจุดบกพร่องเพื่อให้เราแก้
ก่อนอ่าน radar ฉบับนี้เราก็ยังไม่เคยใช้มาก่อน หลักจากอ่านเเล้วเดี๋ยวจะเอาไปใช้ทันที
k6 (assess)
Performance testing tool ที่เขียนโดย Javascript
ในบทความบอกว่ามี advance feature ค่อนข้างเยอะเเละสามารถ feed result ไปยัง monitoring tool อย่าง datadog ได้ด้วย ส่วนตัวคิดว่าน่าสนใจเเละน่าลองใช้
