TW Tech Radar #24 มีอะไร cool ๆ บ้าง
เนื่องจากพึ่งผ่านการย้ายงานมา 2 รอบในเวลาแค่ครึ่งปี เลยไม่ค่อยมีเวลาติดตาม Technology มากเท่าที่ตอนที่งานค่อนข้าง stable วันนี้พอดีกับที่ Radar เล่มที่ 24 ออกมา เลยอยากลอเขียนสรุปสิ่งที่ ผม สนใจในเล่มนี้กันมาแชร์ให้อ่านกัน (ในมุม DevOps engineer)
link เล่มเต็มโหลดได้ที่นี่ ส่วนใครอยากอ่านสรุปเล่มที่เเล้วที่ผมได้เขียนไว้ก็ตามไปดูได้ที่นี่
Technique —
Design System
Design system พูดถึง challenge ของ application development ในการทำยังไงให้ product มีความ consistent โดยเฉพาะบริษัทใหญ่ๆที่มีหลายๆ product team
Design systems ในหนังสือยกตัวอย่างของ design patterns, engineering practices, component, libraries ต่างๆ ซึ่งหลักการจริงๆก็คือการทำ standard ให้กับ software development เพื่อให้ product team สามารถ focus ไปที่ product โดยไม่ต้องทำอะไรใหม่เองทั้งหมด (reinvent the wheel) นั่นเอง
ในความคิดของผม ตัวอย่างของ design system มันครอบคลุมทุกแง่มุมของ software development เช่น การใช้ story book ทำ design ของฝั่ง frontend หรือ การทำ common Java library ของ backend และการทำ Infrastructure as a code ในฝั่ง infrastructure
อีก point ที่ควรเก็บไปใช้คือการทำ standard, guidance พวกนี้ให้เป็น code เพื่อสามารถที่จะ version control มันได้ด้วยนั่นเอง
Platform Engineering product team
หรือก็คือทีมที่มีหน้าที่ในการ “สร้างเเละดูแล platform ภายในองค์กร” โดยทีมนี้มีหน้าที่หลักในการช่วย development team ให้ออก product ได้เร็วขึ้น มีประสิทธิภาพมากขึ้น ช่วยให้การ operate product ทำได้ง่ายขึ้น ดีขึ้น
บทความแนะนำให้เราคิดล่วงหน้าว่า ใครคือ customer ของ platform team เเละ product ของ platform team คืออะไร ก่อนที่จะสร้างทีมขึ้นมาเปล่าๆโดยไม่มีเป้าหมาย เเละแนะนำให้ไปดูวิธีการแบ่งทีมแบบ Team Topologies แทนการแบ่งทีมเป็น Layer เช่น frontend, backend, data team และไม่แนะนำการทำ ticket-driven operation team
Distroless Docker images (Trial)
ยังคงอยู่ใน trial สำหรับ Distroless Docker image ซึ่งก็คือการใช้ Docker image ที่มีของน้อยที่สุดเพื่อให้
- image บน production ของเรามีขนาดเล็กที่สุด
- ลด security surface ของ container ที่จะถูกโจมตี
นอกจากนั้นยังทำให้เราประหยัดเวลาในการ patch security ต่างๆของ docker image โดย Docker image ที่เป็น distroless สามารถดูได้จาก Google เนื่องจากยังมี provider อยู่ไม่กี่เจ้าและยังไม่ support การ scan อย่างครบถ้วน Distroless เลยยังอยู่ใน Trial stage
Hypothesis-driven legacy renovation (Trial)
พูดถึงกรณีที่เราถูกขอให้เข้าไปดู technical issue ของ Legacy system ที่เราไม่ได้เป็นคนสร้างขึ้นมา ซึ่งโดยทั่วไปเราก็จะทำการสร้าง Technical story ขึ้นมา แต่ technical story ของ legacy system ส่วนมากจะ estimate หรือเดาผลลัพธ์ของมันไม่ได้ง่ายๆเหมือนกับ User story ทั่วไป และมักจะบานปลาย หาจุดจบไม่ได้
Hypothesis-driven legacy renovation เท่าที่ผมพยายามทำความเข้าใจจากบทความคือ 1. ทีมจะช่วยกันคิด ผลลัพธ์ที่วัดผลได้ ขึ้นมาก่อน เเละ 2. ทีมจะสร้างสมมุติฐานต่างๆขึ้นมาสำหรับปัญหาที่จะแก้
จากนั้นทีมก็ทำการทดลองแก้ปัญหาตามสมมุติฐานที่ตั้งเพื่อดูว่าแต่ละข้อถูกหรือผิดโดยมี time box กำกับและเรียงตาม priority ของแต่ละสุมมติฐาน
ด้วยวิธีนี้ปัญหาจะถูกจัดการอย่างมีระบบ แทนที่เราจะกระโดดเข้าไปงมในระบบแบบมั่วๆไม่มีแบบแผน
สำหรับหัวข้อนี้น่าสนใจมาก เเละผมคิดว่าหลายๆคนอาจจะทำสิ่งนี้อยู่เเล้วในการแก้ปัญหาบางอย่างโดยไม่รู้ตัว หลังจากนี้ผมจะลองเอาหลักการนี้ไปใช้ให้เป็นเรื่องเป็นราวเพื่อให้แก้ปัญหาแบบมีระบบระเบียบ
Bounded low-code platforms (Assess)
แทบไม่ต้องเดาว่าทำไม low-code platforms ถึงถูก Thoughtworks จัดไว้ใน assess เนื่องจากปัญหาใหญ่มากๆๆของ low-code ที่ทุกคนรู้ นั่นก็คือการที่ low code platform ส่วนใหญ่จะถูกสร้างมาให้แก้ปัญหาได้อย่างจำกัด และไม่สามารถที่จะเอา engineering practice ดีๆมาใส่ลงไปได้อย่างอิสระ
Deployment drift radiator (Assess)
คือเทคนิคที่ทำให้เราสามารถเห็นถึงความต่างของ version ระหว่าง software ที่ deploy ไปแล้วกับ version ที่กำลัง develop อยู่ (ยกตัวอย่างเช่น UAT ที่เราต้อง approve change ขึ้นำไปถึงจะ deploy ได้กับ development version) เพื่อที่ทีมจะสามารถ identify gap เเละโอกาศที่เสียไปจากของที่ยังไม่ขึ้น production ได้
ในบทความไม่ได้ mention tool ที่ช่วย visualize drift นี้ ถ้าใครรู้ ก็สามารถแนะนำมาได้นะครับ
Hotwire or HTML over the wire (Assess)
คือเทคนิคในการทำ web app แบบนึง โดยหลักการคือ การสร้าง page จาก component แต่ต่างจาก SPA ทั่วไปคือ page จะถูก rendor จากฝั่ง server และส่ง HTML มาให้ client เลย
ซึ่งเทคนิคนี้จะช่วยลด Javascript code ในฝั่ง client โดยเหลือไว้แค่ code ที่ใช้เชื่อมเพจต่างๆนั่นเอง และข้อดีของมันก็คือจะทำให้ page load ได้ไวมากๆ ใครที่สนใจก็สามารถที่จะไป research ต่อเองได้ (สำหรับ DevOps engineer อย่างผมจะขอคอยดูตามอยู่ห่างๆอย่างห่วงๆ)
ตัวอย่าง web ที่ใช้ hotwire สร้างด้วย Turbo framework
Open Application Model (OAM) [Assess]
กลับมาสู่ Cloud-native area กันบ้าง OAM คือ standard ที่จะทำ infrastructure platform as a product อ่านเเล้วก็ฟังดูยังไม่ค่อยเข้าใจ
เลยตามไปดูที่ website ของ OAM เเละพอจะเข้าใจได้ว่า OAM คือการที่เรา define cloud native application แบบ application first โดยไม่สนว่าจะ deploy บน platform ไหน (runtime-agnostic) โดยหลักการคือ
- application first — เราจะ define app เราแบบ self-contained ไม่สน infrastructure ไม่ต้องรู้จักว่า Ingress, DNS, หรือ labels ต่างๆคืออะไร
- Clarity and extensibility — เราจะแบ่ง infrastructure ออกเป็นส่วนๆตามความสามารถ เพื่อให้สามารถ extend หรือ reuse แต่ละ part ได้ (extensibility)
- Runtime agnostic — เราสามารถที่จะ deploy app ของเราโดยไม่ต้องสนว่ามันจะถูก deploy บน on-premise หรือ cloud providers เจ้าไหนก็ตาม
Tool ที่ถูก mention ในการ adopt OAM คือ KubeVela ซึ่งจากการที่ผมลองดูเร็วๆ มันจะออกแนวเหมือนการที่เราสร้าง PaaS ของเราเองคือ platform ทีมจะ define custom resource หรือ template เอาไว้ เเละ development team ก็จะสร้างของตาม template OMA นี้ เเละเลือกว่าจะ deploy ไปที่ไหน โดย detail ของการสร้าง infrastructure การ deploy หรือการแปลง template ไปสู่ของจริงๆบน platform จะเป็นหน้าที่ของ platform engineering team นั่นเอง (ถ้าผมเข้าใจผิด ช่วย comment บอกด้วยนะครับ)
Privacy-focused web analytics (Assess)
พูดถึง tool ชื่อ Plausible ที่ช่วยแก้ปัญหาการทำ web analytic ในยุคที่กฏหมาย GDPR มีบทบาทอย่างมาก เเละทำให้หลายๆ web ต้องใช้ cookie กันอย่างหนักหน่วง
GitOps (HODL???)
มาถึง highlight ของ technique ที่ทำให้ผมถึงกับงงคือการ hold GitOps โดยบทความเน้นไปที่ Branching Strategy
สำหรับคนที่ไม่รู้จัก GitsOps อธิบายง่ายๆคือการที่เราใช้ Git เป็น source of truth ของการ deployment เราอยากจะ deploy app version ใหม่เราก็จะไปแก้ผ่านการทำ Pull Request ที่ Git นั่นเอง
บทความอธิบายว่าถ้าเราทำ Branch per environment การจะทำ change เราก็จะ merge code จาก branch ของ environment ที่ต่ำกว่าขึ้นมา (DEV → UAT → PRD) ซึ่งนำไปสู่ environment-specific configuration as a code ซึ่งคล้ายๆกับ long-lived feature branch
อ่านไปแล้วผมก็ไม่ค่อยเข้าใจอย่างเต็มที่ว่าปัญหาคืออะไรที่ทำให้ Thoughtworks ถึง Hold เพราะในมุมของผมถ้าเราทำ 12 factors app ดีๆ และ merge code อย่างสม่ำเสมอ ผมยังไม่เห็นถึงปัญหาว่ามันจะ environment-specific ยังไง
Naive password complexity requirements (Hold)
อันนี้ชอบมาก คือการให้หยุดตั้ง policy password ที่ประกอบไปด้วยนู่นนี่นั่นให้จำยาก เพราะ factor จริงๆของ password ที่ดีคือความยาวของ password
Separate code and pipeline ownership (Hold)
ตัวนี้ไม่พูดถึงไม่ได้ และผมชอบมากๆคือการที่ development team ควรที่จะจัดการทั้ง code และ deployment pipeline code ด้วยตัวเองเพื่อลด bottleneck และมี flexibilty ในการทำงาน แต่ความจริงแล้ว น่าจะมากกว่า 50% ของบริษัทที่มี DevOps team จะ delegate งานดู pipeline ไปให้ DevOps team ซึ่งอาจจะเป็นเรื่อง regulartory หรือคิดว่ามันทำให้ dev team ทำงานได้ง่ายขึ้น
แต่จริงๆแล้วในความคิดผม เราควรจะให้ development team ดูแล pipeline ของตัวเองเพราะ product team ควรจะเข้าใจ value stream ของ product ตัวเองอย่างถ่องแท้ เเละสามารถเพิ่ม ลด ตามความเหมาะสมของทีม
ในขณะเดียวกัน DevOps team สามารถให้คำแนะนำ สร้าง shared component เพื่อประหยัดแรง หรือ เติม security / quality requirement ให้ development team แทน
SAFE (Hold)
เป็นหนึ่งในหัวข้อที่ผมเห็นด้วยมากๆกับ radar เล่มนี้คือการชี้ให้เห็นถึงข้อเสียของ SAFE หรือ Scaled Agile Framework ซึ่งกำลังเป็นที่นิยมอย่างมากในบริษัทที่มี scale ขนาดใหญ่เเละทำ scrum of scrum
แต่โดยรวมของ SAFE นั้นกลับมีความ Top-down เป็นอย่างมาก เเละมี ceremony ต่างๆที่เป็น waste รวมถึงการ over standard ที่ทำให้ทีมมีอิสระน้อยลง (จากประสปกการณ์ของผม) ซึ่งทำให้ดูขัดแย้งกับคำว่า Agile ค่อนข้างมาก
Platform —
Kafka API without Kafka
ไม่ต้องอธิบายมากสำหรับ Kafka ซึ่งเป็นเหมือน de facto สำหรับ platform การ share data ด้วย event แต่ขณะเดียวกัน การใช้ Kafka ดูจะเป็นปัญหาสำหรับหลายๆคนเนื่องจาก Kafka มี component ที่ค่อนข้างซับซ้อน ถึงแม้ component พวกนี้จะทำให้ Kafka powerful แต่ขณะเดียวกันก็ทำให้ใช้ และดูแลยากเช่นกัน
Kafka API without Kafka คือ platform ที่ให้ client สามารถใช้ Kafka API โดย abstract implementation ด้านหลังที่อาจจะดูแลได้ง่ายกว่า บทความยกตัวอย่าง Kafka on Pulsar, Redpand และ Azure Event Hubs for Kafka
แต่เราต้องอย่าลืมว่า platform พวกนี้อาจจะไม่ support ทุก feature ของ Kafka ดังนั้นต้องขึ้นอยู่กับ trade-off ของแต่ละทีมว่าจะใช้ feature ไหนแค่ไหน เเละอะไรดูแลยากง่ายกว่ากันครับ
NATS
NATS เป็น Messaging queue อีกตัวนึง ซึ่งผมเคยเห็นใน CNCF project ซึ่งถูกเขียนขึ้นด้วยภาษา Go
NATS ดีกว่า messaging system อื่นตรงที่มันถูกออกแบบให้ scale ได้ดีกว่า เเละ NATS 2.0 ยัง support security และ access control framework ใน multi-tenant cluster อีกด้วย
Opstrace
Opstrace คือ Open-source Observability platform โดยบทความเทียบกับ Datadog โดยบอกว่าถ้าเราไม่อยากเสียตัง เราก็ต้องสร้าง monitoring system เองโดยใช้ open-source tool เช่น Grafana Prometheus Loki (Logging)ที่ทุกคนน่าจะรู้จักกัน โดยตัว Obstrace จะเป็น layer on top ของพวกนี้เพื่อ provide security / interface / API ให้อีกที
ก็น่าสนใจ เเละน่าจับตาดูครับว่ามันจะมาแย่งส่วนแบ่งของ Datadog ได้ไหม เนื่องจากประสปการณ์ที่เคยใช้ Datadog มาก็รู้ว่ามันแพงจริงๆ ถ้า Obstrace สามารถให้ feature ได้ใกล้เคียงก็น่าจับตามองมากๆครับ
Pulumi (Assess)
Pulumi เข้ามาใน area เดียวกับ Terraform คือ Infrastructure as a Code แต่แทนที่จะใช้ Mark up language เหมือน Terraform Pulumi ช่วยให้เราสามารถใช้ภาษา Programming ที่เราใช้เขียน service เช่น Java Go Javascript ในการทำ Infrastructure provisioning ซึ่งน่าติดตามมาก เพราะผมมองในมุมว่ามันจะช่วยทำลาย barrier to entry สำหรับ developer ทีมที่อยากจะเรียนรู้ infrastructure ได้ดีมาก
Tools
Sentry (Adopt)
Sentry ก็ถูก widely adopt โดยบริษัทจำนวนมากในการทำ front-end error reporting / monitoring และที่สำคัญ ถึงแม้จะมีบริการ SaaS แต่เราสามารถเข้าถึง code ของ sentry และทำการ self-hosted เองได้เช่นกัน
K6 (Assess)
เป็น load testing tool ที่ถูก mention ใน episode ที่แล้วและได้รับ feedback ที่ดีสำหรับการ integrate กับ ci/cd pipeline ก็สามารถลองนำไปใช้กันดูได้ครับ
Prowler (Trial)
Prowler เป็น command line tool สำหรับ scan เพื่อวิเคราะห์ความปลอดภัยของ AWS Configuration ของ account AWS ของเรา ซึ่งมันจะ scan ตาม CIS Amazon Web Services Foundations Benchmark ที่มีทั้งหมด 49 checks และ check อื่นๆอีกเป็น 100 check ทั้งในมุม GDPR และ ISO-27001
ส่วนตัวกำลังมองหา tool ที่ใช้ scan AWS account อยู่พอดีเเละจะนำไปลองใช้อยู่แน่นอน
Buildah and Podman (Assess)
คือคู่ที่ใช้ในการ Build และ Run container image เหมือนที่ Docker ทำได้
โดย Podman ใช้ concept ของ Daemonless (ตรงกันข้ามกับ Docker)ในการ run container ที่ทำตามมาตรฐานของ Open Container Initiatives
สำหรับคนที่สนใจใน detail สามารถไปอ่านเพิ่มเติมจาก blog ของพี่ปาได้
Graal Native Image (Assess)
Graal คือ tool ในการช่วย build Java application ให้กลายเป็น native executable จากปกติที่เราจะ build Java เป็น Jar file และต้องไปรันบนเครื่องที่มี JVM และใช้ Just In Time Compiler ในการรัน Graal ใช้ concept ของ Ahead of Time Compiler ในการสร้าง native image ส่งผลให้ Java application ของเรามีขนาดเล็กลงอย่างมาก และที่สำคัญ consume memory น้อยลงมากๆๆ เเละทำให้ image ของเราที่จะเอาไป deploy สามารถใช้ distroless ได้อีกด้วย (ไม่ต้องมี JVM)
Operator Framework (Assess)
คือ tool สำหรับสร้าง Kubernetes operator ซึ่งใช้ในการรวม knowledge ในการจัดการกับ application ของเรา ยกตัวเช่น การ back up การสร้าง การลบ component เมื่อมีเหตุการณ์เกิดขึ้น โดย operator framework จะทำการ automate งานพวกนี้โดยการคอยเฝ้า state ของ application ของเราเเละให้เราเขียน code เพื่อ handle เมื่อ event เกิดขึ้นนั่นเอง
