ในช่วงทศวรรษที่ผ่านมา DevOps คือคัมภีร์ที่ทุกองค์กรต้องทำตาม โดยมีสโลแกนหลักคือการพังกำแพงระหว่างคนเขียน Code (Dev) และคนดูแลระบบ (Ops) แต่เมื่อเทคโนโลยี Cloud Native ซับซ้อนขึ้นเรื่อยๆ สิ่งที่ตามมาคือภาวะ “Cognitive Overload” หรือการที่ Developer คนหนึ่งต้องรู้ทุกอย่างตั้งแต่ Logic ของแอปฯ ไปจนถึงการเขียน Kubernetes Manifest, จัดการ IAM Role และเซต CI/CD Pipeline

Platform Engineering จึงก้าวเข้ามาเพื่อแก้ปัญหานี้ ไม่ใช่เพื่อมาแทนที่ DevOps แต่เพื่อทำให้ DevOps “ใช้งานได้จริง” ในสเกลใหญ่ครับ

1. ปัญหาของ DevOps แบบเดิม: “You build it, you suffer it”

แนวคิด DevOps แบบดั้งเดิมที่เน้นให้ Dev ดูแล Infrastructure เองทั้งหมดเริ่มมีช่องโหว่:

• ความซับซ้อนที่ล้นมือ: Developer เสียเวลา 30-40% ไปกับการงมเรื่อง Infrastructure แทนที่จะได้เขียนฟีเจอร์ใหม่ๆ
• มาตรฐานที่กระจัดกระจาย: แต่ละทีมในบริษัทอาจใช้เครื่องมือไม่เหมือนกัน ทำให้การคุม Security และ Compliance ทำได้ยาก
• Shadow Ops: เกิดการที่ต้องมี “Dev คนหนึ่งในทีม” ที่เก่ง Infra เป็นพิเศษ จนกลายเป็นคอขวดของทีมเสียเอง

---

2. Platform Engineering คืออะไร?

Platform Engineering คือการสร้าง Internal Developer Platform (IDP) ซึ่งเปรียบเสมือน “ห้างสรรพสินค้าแบบบริการตนเอง (Self-Service)” สำหรับ Developer ภายในองค์กร

แทนที่ Dev จะต้องไปเขียน Terraform เองเพื่อขอฐานข้อมูล พวกเขาแค่เข้าไปที่หน้าเว็บ Portal แล้วกดปุ่ม “Request Database” ระบบเบื้องหลัง (ซึ่งถูกเซตโดย Platform Engineers) จะทำการสร้างฐานข้อมูลที่ถูกต้องตามมาตรฐานความปลอดภัยของบริษัทให้โดยอัตโนมัติ

---

3. “Golden Paths” หัวใจของการลดภาระ

คำศัพท์ที่คนสายนี้ต้องรู้คือ Golden Paths (หรือ Paved Roads) หมายถึง เส้นทางที่ราบรื่นและถูกรับรองโดยองค์กร:

• เส้นทางสีทอง: ถ้า Dev ทำตามมาตรฐานที่ Platform เตรียมไว้ ทุกอย่างจะง่าย รวดเร็ว และ Deploy ได้ทันที
• เส้นทางอิสระ: หาก Dev ต้องการใช้เทคโนโลยีที่แปลกออกไป เขายังทำได้ แต่ต้องยอมรับความเสี่ยงและดูแลตัวเอง (ซึ่งคนส่วนใหญ่จะเลือก Golden Path เพราะมันสะดวกกว่า)

---

4. ความแตกต่างระหว่าง DevOps และ Platform Engineering

เพื่อให้เห็นภาพชัดเจน เรามาดูข้อเปรียบเทียบในตารางนี้ครับ

ประเด็น	DevOps (Culture/Role)	Platform Engineering (Product)
เป้าหมาย	ลดช่องว่างระหว่าง Dev และ Ops	ลด Cognitive Overload ของ Dev
วิธีทำงาน	เน้นการสื่อสารและการทำงานร่วมกัน	สร้าง “Internal Product” ให้ Dev ใช้งาน
ผลลัพธ์	ความเร็วในการส่งมอบงาน (Velocity)	ความสามารถในการขยายระบบ (Scalability) และมาตรฐาน
สถานะ	คือ “แนวคิด” และ “วิธีการ”	คือ “เครื่องมือ” และ “แพลตฟอร์ม” ที่ทำให้แนวคิดนั้นเกิดขึ้นจริง

---

5. เครื่องมือที่เป็นตัวขับเคลื่อน (The Stack)

หากคุณอยากเริ่มต้นศึกษา Platform Engineering นี่คือเครื่องมือที่เป็นกระดูกสันหลัง:

• Backstage: พัฒนาโดย Spotify เป็น Open Platform สำหรับสร้าง Developer Portal ที่รวมเอา Documentation, Catalog และ Service ต่างๆ มาไว้ในที่เดียว
• Crossplane: เครื่องมือที่ช่วยจัดการ Cloud Infrastructure ผ่าน Kubernetes API ทำให้เราสามารถสร้าง “Abstract Layer” ให้ Dev ใช้งานได้ง่ายขึ้น
• Terraform / Pulumi: ยังคงเป็นพื้นฐานสำคัญในการทำ Infrastructure as Code (IaC) แต่จะถูกซ่อนอยู่เบื้องหลัง Platform อีกที

---

6. ก้าวต่อไป: จาก Administrator สู่ Product Manager

สิ่งที่ทำให้ Platform Engineering แตกต่างจากทีม Ops แบบเดิมคือ วิธีคิดแบบ “Platform as a Product” * คนทำ Platform ต้องมอง Developer เป็น “ลูกค้า”

• ต้องมีการเก็บ Feedback, มี Roadmap ของฟีเจอร์ และต้องทำให้ Platform “น่าใช้” จน Dev ไม่อยากหนีไปทำอย่างอื่นเอง

---

บทสรุป

Platform Engineering ไม่ได้มาเพื่อฆ่า DevOps แต่มาเพื่อ “Abstract ความซับซ้อน” ออกไปเพื่อให้ Developer กลับไปทำสิ่งที่ถนัดที่สุด นั่นคือการเขียน Code เพื่อสร้าง Value ให้ธุรกิจ โดยไม่ต้องกังวลว่า YAML ไฟล์ของพวกเขาจะมี Bug ในบรรทัดที่ 500 หรือไม่

“DevOps is the ‘What’ and ‘Why’, Platform Engineering is the ‘How’ at scale.”