บทที่ 4: Choosing Technologies Across the Data Engineering Lifecycle
2 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 (มาแล้วไป เช่น Hive ถูกแทนด้วย Presto) — คำแนะนำ: ประเมิน tech stack ใหม่ทุก 2 ปี ใช้ immutable technology เป็นฐานแล้วสร้าง transitory tools ล้อมรอบ |
| Location | On-Premises (คุมเองแต่ scale ช้า) vs Cloud (IaaS → PaaS → SaaS, opex) vs Hybrid Cloud vs Multicloud — เริ่มจาก single-cloud ก่อน ถ้าไม่มีเหตุผลจำเป็นจริงๆ อย่าเพิ่งไป multicloud |
| Build vs Buy | build เมื่อมันสร้าง competitive advantage เท่านั้น |
| Monolith vs Modular | Monolith = ง่ายต่อการเข้าใจแต่เปราะบาง (จุดเดียวพังกระทบทั้งระบบ), Modular = flexibility สูงกว่า สลับ tool ได้ (polyglot) แต่ orchestration complexity สูง |
| Serverless vs Servers | abstraction ชนะ — ใช้ serverless ก่อน ย้ายมา servers เมื่อ usage สูงจนต้นทุนต่อ event แซงการรัน server เอง |
| Benchmark Wars | caveat emptor — ระวัง apples-to-oranges comparisons |
Figure 4-2. ใช้ time horizon 2 ปีในการประเมิน technology ใหม่ — หา immutable tech เป็นฐานก่อนค่อยเพิ่ม transitory tools
Figure 4-3. Hybrid cloud data flow model — ส่งข้อมูลขึ้น cloud ทางเดียวเพื่อลด data egress cost
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
Monolith vs Modular ในทางปฏิบัติ
Figure 4-4. Monolith — ทุก service ผูกกันแน่นในระบบเดียว
Figure 4-5. Modular — แต่ละ service แยกจากกัน สลับเปลี่ยนได้อิสระ
- Distributed Monolith: ระบบ distributed แต่ node ยังแชร์ dependency/codebase ร่วมกัน (เช่น Hadoop cluster, Airflow) — แก้ด้วย ephemeral infrastructure (สร้าง cluster ใหม่ต่อ job) หรือ containers
Figure 4-6. จุดตัดต้นทุนระหว่าง serverless กับการรัน server เอง — usage ยิ่งสูง serverless ยิ่งแพงกว่า
The Golden Rule
Architecture is strategic; tools are tactical — Architecture first, technology second