XConf Thailand 2023

Note Blog นี้จดแบบตื่นเต้นไปครับ และอยู่ไม่จนจบงานด้วย เช้าแวะไปหาหมอ เสร็จเร็วเลยแวะเข้างาน และบ่ายงานเข้า เลยเป็นที่มาว่า Blog ออกช้า สำหรับหัวข้อที่จดๆมามี

Green software: How can tech contribute to worldwide sustainability effort?

- (Thai) by Chakrit Riddhagni

Tech ปล่อย Carbon 2% ของโลก (carbon emission) พอกับอุตสาหกรรมการบิน โดยมาจากกลุ่มใหญ่ Data Center / Cloud

Green Software แนวคิด SW ลด carbon emission โดยมี 3 มุม Energy Efficiency / HW Efficiency/ และ Carbon Awareness เดี๋ยวจะมีแตกย่อยไปลง ซึ่งทำได้แต่ต้องมีวิธีวัดที่ชัดเจน (measurement)

• Carbon equivalent - วัดหลายด้านนะ ไม่ใช่ tech แปลงหน่วยกลาง co2eq วัดยังไง ?
  Note: Cloud หลายๆเจ้าจะมีบอกนะ cloud carbon footprint (multi-cloud+ Report)
• Software Carbon Intensity
  - นอกจากเรื่องนี้ มันถอยกลับมา SW Design / Architecture Design
  - เลือก Logic / HW / Workload ที่รับไป / Energy Sourceเค้ามีสูตรให้นะ อารมณ์แบ Big O จากสูตรเน้น per unit

Green Software: Energy Efficiency

• Reduce overhead ปกติ DC จะวัดจาก PUE (power usage eff.) ดังนั้นใช้ให้คุ้ม HW Utilization ใข้ให้คุ้ม แต่มีจุดสมดุลเผื่อ scale???
• Optimize SW
  - Cache static data
  - Storage Retention Policy อะไรที่ไม่ใช่เก็บ 5ส
  - Serverless
  - Queue non-urgent request
  - Optimize Image Size ใช้ให้เหมาะ มือถือ ใหญ่ไปใช้พลังงานเยอะ
• จริงๆ มีอีกนะ Catalog | Green Software Patterns

Green Software: HW Efficiency

• Embodied Carbon - HW สร้าง Carbon ขนาดไหนตอนสร้าง
• Amortization - ใช้ให้คุ้ม spec กำหนด 3 ปีที่ให้ครบอายุ หรือยึดเวลาไปหน่อยใช้ 5 ปี

Green Software: Carbon Awareness

1kw ไม่เท่ากัน Spatial Facfor โรงไฟฟ้า solar ถ่านหนิน

• Time factor Demand กลางวัน solar กลางคืนไม่มี
• *** Carbon aware computing - ทำงานตอนพลังงานสะอาด มี SDK ด้วยนะ

Carbon Hack 2022 project น่าสนใจ

• Capybara ให้ GitHub Action ทำงานช่วยที่ใช้พลังงานสะอาดให้ได้มากที่สุด
• Carbon Aware DNN Training
• Green Courier - Deploy Serverless Region ที่ Green
• Branch Magazine: A Sustainable and Just Internet for All - Branch (climateaction.tech) แสดงผลตาม Power Source

Org Carbon Model

• Scope1 CARBON ลำหนับ Run BIZ เราจะเน้น Domain ตัวเองแ
• Scope2 Power Source
• Scope3 Indirect ของ 1 เช่น พนักงานขับรถมา / supply chain co2
• Fact
  - พบว่า SC3 เยอะสุด อ๋อ WFH ลด SC3 ได้ แต่การลด เอา IT มาข่วยทำให้มัน Visibility
  - Terrascope ดู Scope3 นะ

ถ้าสนใจด้านนี้

• Green Software Patterns
• Data Skill - จาก Paris agreement องค์กรใหญ่ๆ อาจจะมีให้ report เช่น กลต สั่ง นั้นแสดงว่างาน data จะสำคัญขึ้น

Self-service for delivery value with platform engineering

-(Thai) Bhuridech Sudsee and Variya Sirilertworakul

ทำไมต้องทำ Platform Engineering ฟังแล้วเออมันจริงงงงงง

• เดิม อยากขอ resource อะไร ผ่าน ticket กรอกข้อมูล รอ Solution Arch Approve 》 Ops Deploy สรุปปัญหาได้ประมาณนี้
  • Ticket dancing workflow
  • Duplicate Task งานเอกสาร
  • Numerous Meeting
• DevOps (Your BUILT it / Run it)ลดปัญหาได้ แต่ทว่าลดได้มีปัญหาใหม่ เพราะ Tools มันเยอะมาก เอามาใช้ อาจจะติด policy.
  • Cognitive Load - Tools เยอะ แนวคิดเยอะ จะใช้อะไร
  • Cross Functional Team แต่ Scale ยังไง ไม่ทัน งานอาจจะกอง Ops แทน Workload bottleneck / Lack of Product Ownership เอาคนมาถมต้องเรียนรู้
• Platform Engineering (Self-Service + Paved Road + Guard Rail) - ภาพผม Portal ครอบ infra มัยจะมีเป็น mini set of service / cloud นะ

Platform Engineering: Self-Service

• Develop / infra / Product มาปรับจูนตาม Controllability / Cognitive Load
• คนทำ Self-Service มาจาก Platform Team โดยมองชัดขึ้นแลตามพฤติกรรมของ Product จะได้มาปรับจูนให้ได้ ลดงาน ad-hoc ของ Platform Team โดยจะได้ IDP (Internal Developmemt Platform)

Platform Engineering: Paved Road

• Options - ไม่ force Design ไป
• Abstraction by transparent - พวกการอะไรขึ้นไปเป็น Seft-Service
• Extensible - ปรับได้ตลอด ไม่บังคับ แต่สุดท้าย Know-How มา update paved road

Platform Engineering: Guard Rail

• ทำ Governance ตาม Set ของ Rule ที่กำหนดไว้ / ลด Risk

Use Case

• UC1: Inconsistency Log - เอา PT มาช่วย ทำให้ Pattern การทำงานของ Dev ไปทิศทางเดียวกัน Log Structure / Lib จจะได้ทำ Observability ง่ายด้วย
  Value: Fast Issue Resolution / Standardization / Increase Integrability
• UC2: Policy Control เอา Service ขึ้นใน K8S เดียวกัน ทำให้บาง Service กิน Resource จนกระทบ อีก Service
  แก้ โดยทำ policies control - เช่น verify image / ดู resource request จาก load ที่ขอ ทำเป็น Guard Rail
• UC3: Mixing of Concerns in delivery setup - tools เยอะ อาจจะมาแก้ไข config ผิด
  แก้ abstract resource as component แบบขอ DB เราเตรียม Set VNET / Iam / backup.
  Value: Simplification of Complexity / Reduced Time to market / Increase scalability
• UC4: Observability System มันขึ้นยาก เอา set อะไรมาแปะด้วย เอออันนี้จริง แล้วมีหลายระบบ .. Observability ของใครของมัน จะไม่เห็นภาพ
  แก้ ทำ Global Dashboard เป็น Plug Play ด้วย มองภาพรวม และภาพย่อยของแต่ละ Product / Pod มันเหมือน Link ไป Session แรกนะ Terrascope
  Value: Cost Efficiency / Reduced Time to market

Criteria ในทำ Self Service

• Common Case ที่เกิด และ on top ทำ abstraction.
• คุ้มค่าที่จะทำไหม Economic of scale เช่นถ้าทำ IOC อาจจะทำ Terraform Module มาแชร์ให้ใช้ได้

Our adventure in building an internal developer platform

-(English) Michael Longerich and Raksit Mantanacharu

สำหรับ Session นี้ เรียกว่ายังไงดี หลังจาก Session ก่อนหน้าที่ปูพื้นในส่วนของ Platform Engineering แล้ว การจะทำ Platform Engineering ขึ้นมา เรามี

• Capabilities ที่ต้องการจะแก้ปัญหาเต็มไปหมด แต่ทว่า เราต้องเลือกทำ ทำหมดคนไม่พอ และไม่ทันการณ์ด้วย
• Choice Paradox and Satisfaction - แนวคิด The Paradox of Choice รักพี่เสียดายน้อง
  - พอมีตัวเลือกมากไป หรือ ไม่มี ผลออกมา ไม่ได้ทำอะไรสักอย่าง หรือทำออกมาแล้วไม่ดี
  - มีตัวเลือกที่เหมาะสม จะดีกว่า //Guard Rail จากหัวข้อที่แล้ว

อันนี้มาเล่าว่า การจะสร้าง Platform Engineering โดยมีการทำแบบ thin vertical slices จากมุมนึงจะเลือกเรื่องการ CI/CD Pipeline as a Service ขึ้นมาก่อน โดยมี 4 ขั้นตอนใหญ่ๆ

-1.Assess and Recommend

อย่างแรกเลยต้องมาดูก่อนว่า อะไรเป็นปัญหาที่ Platform Engineering เข้ามา และ Underestimate Potential of risk โดยควรจะตาม Platform Team key

• Consume first
• Paved Road
• Enabler over gatekeeper เช่น ปรับจูนให้เกิดการพัฒนา เช่น เรื่อง test coverage policy คุยกันบ้าง
• Product over project

พอได้รายละเอียด เราจะได้ List Capabilities ขึ้นมาเลือก Improve ตาม Priority และเลือกทำตามแนวคิด thin vertical slices แบ่งชิ้นงานเล็ก มา Delivery โดยควรดูตาม desirable + usable + functional ด้วย

ก่อนทำงาน เราต้องมาวัดผลกันก่อน (Measure of Success) โดยวัดผลตาม Accelerate Metrics (4 DORA metrics) / SPACE Metrics / Net Promoter Score (ประสบการณ์ลูกค้า ในที่นี้ developer)
Capability voluntary adoption rate

Approaches - Research + User Interviews เพื่อให้ได้ Develop Needs / Best Practices / Experiences มาเป็น Input ในการทำต่อ

-2.Baseline and Prove (MVP)

Challenge > Standard / Foundation

• ทุก Product มันจะมี Challenge ของมันแตกต่างกันไป
• สร้าง Paved Road ดูจากรองรับสิ่งที่ Common ก่อน (support majority) มันจะได้มี framework Platform Engineer maintain น้อย
• แต่ถ้าไม่เข้า Scope ทาง Platform Engineer มาให้คำแนะนำ
• เพราะสุดท้ายแล้ว มันจะเป็นสร้าง capabilities ขึ้นมา จนสุดท้ายจะได้เป็น knowledge ที่สามารถ Guide และแนะนำต่อได้

Build the right abstractions

• Cohesive Language + Mental Model
• Shield the user from the underlying complexity และที่สำคัญต้องให้ผู้ใช้เข้าใจด้วยนะ ไม่ใช่ซ่อนหมดจนคนใช้งานเข้าใจผิดไป (misled) //เออจริงๆหลักการ Framework ทำแบบนี้นะ

Establish empathy with user (Developer / Product Manager)

• เพิ่ม Feedback channels ให้กับ early adopters.
• Strategy: Developer Friendly

-3.Seed and Scale

รับฟัง requirements ใหม่ จากกลุ่ม user ใหม่ (new adopters) และแก้ไขปัญหาที่พบ (Challenge)

• ไม่รู้ว่ามี Platform
  Improve: Do marketing (ขายของ) Naming, branding Demo/showcase Newsletter
• Inconsistence / inefficiency platform use
  Improve:
  - Knowledge sharing - Case studies & success stories for example
  - Documentation (สำหรับทุกคน นึกถึงคนสายต่างๆใน Humanistic Software Architecture) มี 4 แบบ tutorial (Learning Oriented) / How to (Task Oriented) / Explanation (Understand Oriented) / Reference (Information Oriented)

เน้นทำให้เกิด constructive feedback

Versioning - ป้องกันลูกค้าหนีหาย จาก Bug ต่างๆ

Adoption Dashboard เอามาวัด Measure of Success 4 หมวดที่กำหนดไว้ และเป็นการประชาสัมพันธ์ด้วย ว่าคนอื่นใช้แล้วดี มาลองกันได้

-4.Evolve and Support

• Iterative feedback and Improve.

อะไรที่ Platform Engineering เข้ามาช่วย

Key takeaways > Developers are our users / standard over individual customization / Treating platform as product

Successful digital transformation: Outcome-driven teams, reward and metrics

- (English) by Vijay Iyer, Shyaamkumaar Krishnamoorthy

หัวข้อนี้ออกตัวก่อนเลย Speaker พูดไวมาก อาจจะหลุดได้หลายช่วง โดยเริ่มต้นจาก 3 คำถาม และมา

1.Why do digital transformation fail ?

• จากการสำรวจ digital transformation มันจะเป็นที่หลายๆองค์กรกำลังทำ แต่ทว่า 70% fail หลุด objective ไป
• หรือ ไม่ Pilot ผ่าน แต่ Scale แล้วพัง
• Barrier หลักๆของการทำ digital transformation คือ People / Culture

2.How can teams help here

• Right Mind Set
  - Customer-Value Focus
  - Experimentation Culture (Fail Fast) ถ้าผ่นแล้วค่อยๆ Scale
  - Responsiveness to market shifts ปรับ process ได้ตามสถานการณ์
• Right Ownership & Empowerment Level

3.How do we set teams up for success

• outcome driven team ให้เข้าใจร่วมกัน ว่าทำไปเพื่อให้ได้อะไร ไม่ใช้หัวหน้าสั่งบอกให้ทำ
• Cascading Ownership - OKR // Individual Contribution > Collective outcomes

> Vision & Strategic Objective 
>>> Goal (SMART Outcome - Specific, Measurable, Attainable, Relevant, and Timely.) 
>>>>> Bets & Initiatives

• Change Adoption Framework

The more we test, the worse?

- (English) Pongpipat Kawlerk, Xudong Yang

Session นี้เป็นอันนี้ที่ผมอ่านหัวข้อ แล้วอยากลองมาฟัง เริ่มต้นด้วยว่าทำ Test มันช่วยให้ดีขึ้นไหม ?

• Therac-25 - ไม่ทำ Test ใช้ไปสักพักมีปัญหา
• PonoMusic - ทำ Test มาอย่างดี แต่ Release ไม่ทันตลาด เจ๊งไป

เวลาที่ระบบมีปัญหา สิ่งที่ทาง Tester / QA เจอคำถามแบบนี้

1. Why doesn’t your test detect the issue?
2. Our automated tests take a long time and are flaky
3. The metrics are good, but I don’t feel it

ปัญหาอยู่ที่ Quality แล้วนิยามของมันควรจะเป็นอย่างไร ? - จะเอาตาม ISO 9000 เลยไหม หรือจริงๆ แล้ว Build-in quality เข้าไปใน Product แต่แรกตั้งแต่ Business > Software ข้างล่างน่าจะเป็น Quote ประมาณนี้ //อาจจะฟังมาผิด

“Inspection to improve quality is too late, ineffective, costly.
Quality comes not from inspection, but from the improvement of the production process.”

― W. Edwards Deming,

ดังนั้น สิ่งที่เราควรถามกลับไปแทน

1. Can such issue have prevented in earlier phase ?
2. Are users using our software as we expected?
3. Is our codebase still healthy as we go ?

ปรับ Mindset กันใหม่ และทำให้มันดีขึ้น มาตอบกลับ Why doesn’t your test detect the issue? โดย

• Don't work in silo!
• Quality != no bug //Test ให้ครบ 100% ใช่ว่าจะไม่เจอ Bug
• Understand your user
• Prevent defect, instead of finding defect //Care leading factor เช่น Codebase Health

ต่อมาเป็นส่วน 2 Our automated tests take a long time (ช้า) and are flaky (ผีเข้า ผีออก) และปัญหายังคงอยู่ ปรับโดย

• ดูก่อนว่า Testing Strategy ตอนนี้ Anti-patterns อย่างพวก Ice cream cone, cupcake อยู่ หรือปาว
  - ทำให้เน้น Manual Test มาครอบคุม + Regression ยาก
• วาง Test ผิดที่ อยู่หรือป่าว ไปเน้น Automate E2E ทั้งที่มันใช้ Unit Test ตอบโจทย์อยู่แล้ว
  - พอไปใช้ E2E เกิด flaky ต้องมาคุม Environment / ช้า
• Law of instrument - No Silver Bullet ทุกปัญหาไม่ใช่จะเอาพาราแก้ได้หมด 55 ในที่นี้น่าจะสื่อถือ การเพิ่ม Test ทำ E2E /Manual Test
• ปรับไป Testing Strategy เป็น Test Pyramid / Test Trophy

ส่วนสุดท้าย The metrics are good, but I don’t feel it เคยเจอ KPI พวกนี้ไหม แทนที่จะช่วยกัน กลับต้องมาถาเถียงกัน

Tester KPI: find 30 bugs in 1 Iteration
Dev KPI: no more than 3 major bugs reported in 1 iteration

Let's Fight KPI 555

หรือ อีกตัวอย่างของ Dev เรื่อง Code Coverage - ตัวอย่างจี้จริง เคยเจอเขียน Code และ Test ให้มันผ่านแหละ แต่ไม่มีคุณค่า ไม่ตรงกับ business ดังนั้น

• เลือก Metric ให้ดี ตัวอย่าง DORA Metric 4 ตัว Lead Time / Deployment Freq / Mean Time to Restore / Change Fail Percentage
• Always stay vigilant, even if you get good numbers

Key Take Aways

• Quality != No Bug
• Quality is Everyone's Responsibility
• Quality (Test) comes with a cost.
  - Don't repeat same tests - //คหสต Code Coverage ช่วยตรงนี้ได้
  - Find, what needs to be tested //คหสต Business need
• Metric can be helpful and harmful.

FinOps: Principles and cloud cost observability

-(Thai) by Athakorn Ongsiriporn

สำหรับใน Session จะมาเล่าจากมุมมองของ SRE ว่าทำไม observability ถึงสำคัญ และแนวคิด FinOps เข้ามาได้ยังไง โดยเริ่มจากกำหนดปัญหา

อยากรู้ว่าะไรเกิดขึ้นบน Cloud บ้าง และ Cost เท่าไหร่ จากตัว Workload ต่าง เช่นตัว k8s cluster

จากนั้นตั้ง Goal สร้าง หรือ หาเครื่องมือมาช่วงเห็นภาพ เพื่อนำไปใช้วางแผนลด cost ให้สมเหตุ/สมผล เพราะการจะลด Cost มัน ดูจาก IT ไม่ได้ ต้องเอาทาง Business มาคุยด้วย

เริ่มต้นจากมาดูของเดิมกันก่อนว่ามี Cluster อะไรอยู่บ้าง ปรากฏว่ามีท้่งในส่วนของ Development / Test / ML / Data / มีแยก Environment PROD ด้วย และมี Centralized Observability Cluster อีกชุดที่เอามา Monitor Cost / Resource ของ Cluster อื่นๆ โดยทาง SRE

นอกจาก Design Optimize Performance ให้คิดถึง Cost ด้วย !!!

ต่อไปเริ่ม Optimized Cost โดยทาง Speaker จะเริ่มในส่วนของ Data เพราะใช้เยอะ เช่น งาน ETL / Workflow ถ้า Run Pipeline แล้ว Fail มันเสียเงินนะ ถ้าลด Cost ได้ efficiency ยังเท่าเดิม จะเป็น Success Case ให้ฝ่ายอื่นๆ ลองมาแจมด้วย

• Hypothensis: ถ้าเรารู้ metric ใช้ cpu mem เราสามารถเห็นจุดสามารถลด Cost
• Measure: reduce cost / efficiency (Testing สำคัญนะ มา Validate ว่าพังไหม)

FinOps = Finance + DevOps (The FinOps Foundation)

- ถ้าไม่สนใจ FinOps - แนวโน้มค่าใช้จ่าย cloud สูงขึ้น

- Definitions

- FinOps Principles

• Team Collaboration (Finance หาโปรลับ / Dev Optimize Code)
• Decision are driven by business value of cloud - ย้ายไปทำไม / เพื่ออะไ
• Everyond takes ownership of cloud usage
• FinOps Data should be accessible and timely ต้องสามารถให้ทุกทีมเค้าถึง เพื่อที่จะได้ทราบแนวโน้ม และ optimize.
• A centralized team drives FinOps - ออกแนวทางให้ไปในการเดียวกัน และแนะนำทีมอื่นๆ ถ้ามีคนน้อย อาจจะกำหนด Champions ให้คนนั้นมาดูแทน ก่อน Scale.
• Take advantage of variable cost model of cloud - ใช้เท่าที่ใช้

- FinOps Phase

• Inform - ทำ Observability + Data Visualization เพื่อให้เห็นภาพที่
  - SRE ดู Cost (Cluster / Node) และ Resource CPU/Mem
  - รวมถึงคำถามจากฝั่ง Data ด้วย เช่น Cost / Resource ของ Workflow
• Optimize - Code / Relocate ไปใช้ทือื่น เป็นต้น
• Operate - Continuous Improvement & Maintain

Note: enough solution for fast feedback อาจจะเริ่มที่ Dashboard ใช้ของที่มีก่อน ถ้าจะเอาเยอะกว่านี้ค่อย Build you own

Key Takeaways - FinOps ต้องมีแล้ว จะได้ทราบ Cost เข้าใจ Workload ที่ใช้งาน / FinOps is nerver ending journey

Democratizing data access through LLM

-(Thai) by Pee Tankulrat

ในยุคนี้เราสามารถเข้าถึง Data ได้ง่ายขึ้นหากเทียบกับสมัยก่อน จากการพิมพ์ มาจนถึงการเข้ามาของ internet ทำให้ Knowledge Access เข้าถึงง่ายขึ้น ตอนนี้ยุคของ ChatGPT
ถ้ามา Recap ตอนนี้เราทำอะไรกับ Data ได้แก่

• Text
• Voice - meeting minute / index
• Picture QA - ถามจากภาพ มันช่วยให้ผู้พิการรู้ว่ามีอะไน
• Defog - Schema โยนเข้าไป มันแนะนำ SQL

-ตอนนี้ Generative AI ถึงไหนแล้ว

1. GPT Model เติมคำ
2. Decoding LLM - auto-complete เอาคนมาตรวจ เก็บคะแนน ให้ได้คำตอบที่เหมาะสมใช้ Cost เยอะ
3. Retrieval augmented generation (RAG) - fine-tuned and its internal knowledge with LLM

-Limitation

• พวก Generative AI ตอบตาม prompt ยังไงต้องมาตรวจด้วยนะ เพราะ modelมั่นใจมาก
• Guardrail data มาจากหลายแหล่ง อาจจะดี หรือไม่ดี หรือ เพื่อให้ได้ตาม Goal ซื้อ AI ลดแลกแจกแถมจนล้มละลายไป

Key Takeaways AI ที่ดี มาจาก Data ที่ดี

Legacy modernization made practical: A example of modernization patterns

- (Thai) by Salah Chalermthai and Wanichnun Sinpitak

Legacy - โบราณ
Modernizationแ บูรณะ ทำให้มันใช้ได้ต่อ

Why legacy modernization is hard? ทำแบบค่อยเป็นค่อยไป โดยมีสิ่งที่ต้อง concern

• User Impact
• Complex domain knowledge - คนทำไม่อยู่แล้ว ต้องสกัดออกไป
• Outdated tech
• Unsafe refactoring ต้องมี Test ทำไปเราจะมั่นใจได้ไง ว่ามันจะออกมาเหมือนเดิม หรือได้อสุรกายใหม่ (New Monster)

ถ้าทำ legacy modernization ต้องมาสนใจหลักๆ 4 เรื่อง ได้แก่ Modernize Strategy > Decompose Pattern > Data Migration Pattern > Measure of success เดี๋ยวจะแตกนย่อยลงไปในแต่พ

-Modernize Strategy

• ต้องล้อกับ business ด้วย และย้ายแบบไหน ย้ายแล้วทำอะไรเพิ่ม เพื่อเพิ่ม Business Value
• จากนั้นคุยกับ domain expert ต่างๆ เพื่อให้ได้ภาษาถิ่น และ วนไปดู Code base Apply DDD ให้ Code มันแยกออกมา มี boundary ชัดเจน บางเคสอาจะต้องมาแตก sub domain ออกมา เช่น product ในมุมของ user / inventory

พอได้ boundary ชัดเจน มาดูแนวทาง มี 6R

• Repurchase
• Refactor - Code / Architect
• Re-platform
• Rehost
• Retain
• Retire

Thin vertical slices Approach - Business Lead แล้วมาดู ระบบส่วนไหนเกี่ยวบ้าง แล้ว modernize ขึ้น ถ้ามีหลายอัน ต้องมาชั่งตาม Value / Priority พอจัดเป็นแผนช่วยแรกๆ นาน เพราะเป็น Foundation ของ New System

-Decompose Pattern มีหลายแบบ ตัวอย่างจะเป็น

• Strangulation Pattern - ไม่ได้ทำ big bang ค่อยทำ
  - เพิ่ม Indirection layer พวก api gw เอาไว้ reroute path ไปหา service ใหม่ อ๋อ พวก ngix traefik
  - จากนั้นแยกไปเรื่อยๆ
• การทำแบบนี้ต้องมีแบบแผน มี Test มี CI/CD ระหว่างการย้าย rollback plan

-Data Migration Pattern

• Step
  - Analysis - ใช้ DB แบบไหน และปลายทางเป็นอะไร / Schema เปลี่ยนไปไหม
  - Migration- ทำอย่างไร Migration Pattern แบบไหน
  - Reconcile - ตรวจสอบ
• Migration Pattern
  - One-off ปิดระบบย้าย data มี downtime แต่ดูระบบเดียว
  - Migration on demand - อาจจะเหมาะกับบาง use case เช่น ย้ายระบบไป cloud ตอน login มีแจ้งให้ user ทราบ ถ้า accept ย้าย
  - Initial with deltas - เอา backup มาก่อน ค่อยเติม data เหมาะกับงานไม่ Realtime
  - Change Data Capture (CDC) - Realtime Tools Debezium

-Measure of success

• Behavior Verification - Test บน Production แต่ต้องทำให้ปลอดภัย โดยทำระบบขึ้นขนานกัน ParallelChange (martinfowler.com) โดยต้อง
  - return ผลจากของเก่าให้ user นะ ฅ
  - และเอาผลลัพธ์ เก่า ใหม่ มาเทียบ แล้วลง log
  - คหสต สรุปที่อื่นทำแบบนี้เหมือนกัน แต่ที่ผมเคยลอง user บ่นๆช้า 555
• DORA 4 key metric
• Build it right
• Build the right thing
• และ ทำ Modernization Score Card ให้เห็นว่า Tech / Biz มัยไปในทางเดียวกัน

DEMO: Legacy modernization

1. Add Indirection layer (Proxy)
2. Prepare Sync DB Debezium + Kafka
3. เพิ่ม consume พอรับ Kafka ลง db ใหม่ และ deploy service ใหม่ reconcile เท่ากันแล้ว
4. แก้ proxy ย้าย read ไปอ่าน DB ใหม่ ลองดูว่าบึ้มไหม ถ้าไม่ทำต่อ แต่ต้องดูความถี่ของ biz ด้วยนะ ถ้าแข่งกันกดโปร รอ read อาจจะไม่ทัน อาจจะต้องหลอก UI Calc / บังคับรอ Read Ver ใหม่
5. ย้าย write ไป
6. ไปทำ service อื่นๆ
   ** ทำที่ละ step ไปจนครบ

Key takeaways

• ทำแบบ Thin Vertical Slice ผ่าตัดทีละชิ้น เล็กๆ (breaking modernization to small / release slices)
• อย่ากลัว การทำ Modernization ถ้าไม่ทำจะเจอปัญหา disrupt หรือ พัง ในอนาคตได้ (Prone to Failure) เช่นกัน
• IT (ใช้ Engineering Practise) และ Non-IT ต้องร่วมมือกันให้สำเร็จ จะได้ไม่กระทบกับ Business

You should stop writing code

-(Thai) by Peerapong Maitriwong

ทุกวันนี้เรา Software มาอยู่กับชีวิตประจำวันของเรามากขึ้น ถ้าเกิด Software มันทำงานผิดพลาดขึ้ยมาหละ นี่แหละทำไม Software Quality ถึงสำคัญ Test / Review และ CI/CD โดยเน้นที่ Code Quality นานเข้ามันกลายเป็น Code-centric mindset จนมองไม่เห็นทางเลือกอื่นๆ โดยมันสะสมมาจาก

• Course เรียน Roadmap Code
• ทำงานวนกับ Code > Review Code

• อ๋อเข้าใจและ นอกจาก Code แล้ว เราควร focus biz หรือ big picture เรามองว่า Code วิธีการสื่อสารในการส่งต่อความเข้าใจจากรุ่นสู่รุ่น (Code serves as a way to communication)

Code ตอบ Product
=> Product ตอบ Business Strategy
=>Business Strategy ตอบ Business ต้องการรายได้

• รายได้มาจากผู้คน ดังนั้น เราต้องคุยกับคนมากขึ้น เพื่อให้ได้ insight และมาปรับ Code ให้สอดคล้อง

ปรับจาก Code-centric มาสนใจ People-centric มากขึ้น ไปทาง DDD ไม่ได้ทิ้ง Code นะ

• เริ่มต้นด้วยการถาม
• และปรับ mindset เริ่มปรับจากวิธีการ
  - learning
  - communication - Contribute to the Conversation
  - collaboration
  - และทำแบบ incremental และวนซ้ำไป

เริ่มคนเดียวไม่ได้ องค์กรต้อง support ดังนั้น

• มองทุกคนเท่ากัน ไม่ใช่ว่ามอง Dev คุยไม่รู้เรื่องแล้วปล่อยไป
• พยายามให้ communication loop สั้นลง ลด Gossip Effect
• จูนด้วยกัน
• ลดความซับซ้อนขององค์กร (Flatten Org structure)

สำหรับอีก 2 หัวข้อ Why organizations fail in investing in research and design (without Ops)? / Panel discussion: Agile in the modern age ผมไม่ได้ฟัง กลับไปแก้ + เป็นมิ่งขวัญ เคสไฟไหม้ช่วงเย็น เสียดายเหมือนกัน

Update 2023-10-06: มีบันทึกย้อนหลังนะครับ XConf Thailand 2023 - YouTube

Blog ของท่านอื่นๆ

• XConf Thailand 2023 (narze.live)

Reference

• XConf Thailand 2023 | Thoughtworks
• XConf Thailand, Fri, Sep 29, 2023, 9:00 AM | Meetup