บทที่ 4: Choosing Technologies Across the Data Engineering Lifecycle
1 min readThe Embarrassment of Riches
มี data technologies มากเกินไป — engineers หลงกับ bleeding-edge tools จนลืม core purpose ต้องตอบคำถามเดียว: มันเพิ่ม value ให้ data product และ business หรือไม่?
เกณฑ์การประเมิน Technology
| ปัจจัย | รายละเอียด |
|---|---|
| Team Size & Capabilities | ทีมเล็ก → managed/SaaS (Software as a Service) tools, อย่า cargo-cult big tech (เลียนแบบ big tech โดยไม่จำเป็น) |
| Speed to Market | delivery เร็ว wins |
| Interoperability | ทำงานกับระบบอื่นได้ดีแค่ไหน? |
| Cost (TCO + TOCO) | TCO (Total Cost of Ownership — ต้นทุนรวม) + TOCO (Total Opportunity Cost of Ownership — ค่าเสียโอกาสจากการถูก lock-in) |
| Today vs Future | Immutable technologies (object storage, SQL, bash — ใช้ Lindy effect) vs Transitory (มาแล้วไป) |
| Build vs Buy | build เมื่อมันสร้าง competitive advantage เท่านั้น |
| Monolith vs Modular | modular = flexibility สูงกว่า แต่ orchestration complexity สูง |
| Serverless vs Servers | abstraction ชนะ — ใช้ serverless ก่อน ย้ายมา servers เมื่อโตเกิน |
| Benchmark Wars | caveat emptor — ระวัง apples-to-oranges comparisons |
Open Source vs Managed vs Proprietary
- Community OSS: ฟรีแต่ maintain เอง — ดู mindshare, maturity, community
- Commercial OSS (COSS): Databricks, Confluent, dbt Labs — จ่ายให้คนอื่น manage
- Proprietary: interoperable หรือ vendor lock-in?
- คำแนะนำ: favor OSS และ COSS เป็น default, custom เฉพาะที่สร้าง competitive advantage
The Golden Rule
Architecture is strategic; tools are tactical — Architecture first, technology second