spinny:~/writing $ less platform-engineering-internal-developer-platform.md
12เมื่อระบบซอฟต์แวร์มีความซับซ้อนมากขึ้น - ไมโครเซอร์วิส, Kubernetes, มัลติคลาวด์, ไปป์ไลน์ CI/CD, สแตกการสังเกตการณ์ - นักพัฒนาใช้เวลากับโครงสร้างพื้นฐานมากขึ้นและใช้เวลาสร้างผลิตภัณฑ์น้อยลง **Platform Engineering** แก้ปัญหานี้โดยการสร้างแพลตฟอร์มภายในที่แยกความซับซ้อนออกไปและให้เครื่องมือบริการตนเองแก่นักพัฒนาเพื่อส่งมอบได้เร็วขึ้น34Gartner คาดการณ์ว่าภายในปี 2027 **องค์กรวิศวกรรมซอฟต์แวร์ 80%** จะจัดตั้งทีมแพลตฟอร์ม ในคู่มือนี้ เราจะสำรวจว่า Platform Engineering คืออะไร ทำไมถึงสำคัญ และวิธีสร้าง Internal Developer Platform ตั้งแต่ต้น56## Platform Engineering คืออะไร?78Platform Engineering คือศาสตร์ของการออกแบบและสร้าง toolchain และ workflow ที่เปิดใช้ความสามารถบริการตนเองสำหรับองค์กรวิศวกรรมซอฟต์แวร์ ผลลัพธ์คือ **Internal Developer Platform (IDP)** - ชั้นที่อยู่ระหว่างนักพัฒนาและโครงสร้างพื้นฐาน910```mermaid11graph TD12 subgraph "Developers"13 D1[Frontend Team]14 D2[Backend Team]15 D3[Data Team]16 end1718 subgraph "Internal Developer Platform"19 Portal[Developer Portal]20 Templates[Service Templates]21 CICD[CI/CD Pipelines]22 Infra[Infrastructure Abstraction]23 end2425 subgraph "Infrastructure"26 K8s[Kubernetes]27 Cloud[Cloud Services]28 DB[Databases]29 Monitor[Monitoring]30 end3132 D1 --> Portal33 D2 --> Portal34 D3 --> Portal35 Portal --> Templates36 Portal --> CICD37 Portal --> Infra38 Infra --> K8s39 Infra --> Cloud40 Infra --> DB41 CICD --> Monitor42```4344### Platform Engineering vs DevOps4546Platform Engineering ไม่ใช่การทดแทน DevOps - มันคือวิวัฒนาการขั้นถัดไป DevOps บอกว่า "คุณสร้าง คุณดูแล" Platform Engineering บอกว่า "เราจะทำให้การสร้างและดูแลเป็นเรื่องง่าย"4748| ด้าน | DevOps | Platform Engineering |49|------|--------|---------------------|50| **จุดเน้น** | วัฒนธรรมและแนวปฏิบัติ | ผลิตภัณฑ์และบริการตนเอง |51| **แนวทาง** | แต่ละทีมจัดการโครงสร้างพื้นฐาน | ทีมแพลตฟอร์มแยกโครงสร้างพื้นฐาน |52| **ภาระทางปัญญา** | สูง (แต่ละทีมเรียนรู้ทุกอย่าง) | ต่ำ (มี golden path ให้) |53| **ผลลัพธ์** | ไปป์ไลน์ CI/CD, สคริปต์ IaC | Internal Developer Platform |54| **ผู้ใช้** | วิศวกรรมทั้งหมด | ทีมแพลตฟอร์มให้บริการวิศวกรรม |5556## ทำไม Platform Engineering ถึงสำคัญ5758### ปัญหาภาระทางปัญญา5960ในองค์กรสมัยใหม่ทั่วไป นักพัฒนาต้องเข้าใจ:6162- เวิร์กโฟลว์ Git และกลยุทธ์การแตกสาขา63- การกำหนดค่าไปป์ไลน์ CI/CD64- การสร้างคอนเทนเนอร์และการจัดการ registry65- แมนิเฟสต์ Kubernetes และ Helm Charts66- บริการผู้ให้บริการคลาวด์ (AWS/GCP/Azure)67- เครือข่าย, DNS, ใบรับรอง TLS68- การตั้งค่าการตรวจสอบ การบันทึก การแจ้งเตือน69- การจัดเตรียมและย้ายฐานข้อมูล70- นโยบายความปลอดภัยและการปฏิบัติตามข้อกำหนด7172นี่คือภาระทางปัญญาอันมหาศาลที่ทำให้หันเหความสนใจจากผลิตภัณฑ์จริง7374### Golden Path7576Platform Engineering นำเสนอแนวคิด **golden path** - เส้นทางที่มีความเห็น ได้รับการสนับสนุนดี และมีเอกสารสำหรับงานทั่วไป Golden path ไม่ใช่คำสั่ง นักพัฒนา*สามารถ*เบี่ยงเบนได้ แต่แพลตฟอร์มทำให้สิ่งที่ถูกต้องเป็นสิ่งที่ง่าย7778```mermaid79flowchart LR80 Dev[Developer] -- "Create new service" --> Portal[Portal]81 Portal -- "Select template" --> Template[Service Template]82 Template -- "Auto-provision" --> Repo[Git Repository]83 Template --> Pipeline[CI/CD Pipeline]84 Template --> Infra[Kubernetes Namespace]85 Template --> Monitor[Dashboards + Alerts]86 Repo --> Ready[Ready to Code!]87```8889**ตัวอย่าง golden path สำหรับการสร้างไมโครเซอร์วิสใหม่:**901. นักพัฒนาเลือก "บริการ Backend ใหม่" ในพอร์ทัล912. เลือกภาษา/เฟรมเวิร์ก (Node.js, Go, Python)923. แพลตฟอร์มสร้างอัตโนมัติ: คลัง Git, ไปป์ไลน์ CI/CD, namespace Kubernetes, แดชบอร์ดการตรวจสอบ และกฎการแจ้งเตือน934. นักพัฒนาโคลนคลังและเริ่มเขียนโค้ดทันที9495## การสร้าง Internal Developer Platform9697### ชั้นที่ 1: Developer Portal9899พอร์ทัลเป็นจุดเข้าเดียวสำหรับนักพัฒนา ตัวเลือกโอเพนซอร์สที่นิยมมากที่สุดคือ **Backstage** (สร้างโดย Spotify ปัจจุบันเป็นโปรเจกต์ CNCF)100101คุณสมบัติหลัก:102- **แคตตาล็อกบริการ**: ทุกบริการ เจ้าของ เอกสาร และการพึ่งพา103- **เทมเพลตซอฟต์แวร์**: โครงสร้างสำหรับบริการใหม่พร้อมแนวปฏิบัติที่ดีที่สุดในตัว104- **เอกสารเทคนิค**: เอกสารเป็นโค้ด แสดงผลและค้นหาได้105- **ระบบนิเวศปลั๊กอิน**: ขยายได้ด้วยฟังก์ชันที่กำหนดเอง106107```yaml108# backstage/catalog-info.yaml109apiVersion: backstage.io/v1alpha1110kind: Component111metadata:112 name: user-service113 description: Manages user accounts and authentication114 annotations:115 github.com/project-slug: myorg/user-service116 backstage.io/techdocs-ref: dir:.117spec:118 type: service119 lifecycle: production120 owner: team-auth121 system: identity-platform122 dependsOn:123 - resource:postgresql-main124 providesApis:125 - user-api126```127128### ชั้นที่ 2: การแยกโครงสร้างพื้นฐาน129130นักพัฒนาไม่ควรเขียน Terraform หรือ Kubernetes YAML โดยตรง แพลตฟอร์มควรให้การแยกส่วน131132**เครื่องมือ:**133- **Crossplane**: การจัดเตรียมโครงสร้างพื้นฐานแบบ Kubernetes-native134- **Terraform พร้อมโมดูล**: โมดูลโครงสร้างพื้นฐานที่สร้างไว้ล่วงหน้าและทดสอบแล้ว135- **Pulumi**: โครงสร้างพื้นฐานเป็นโค้ดจริง (TypeScript, Python, Go)136137```yaml138# Example: Crossplane composition for a database139apiVersion: database.example.com/v1140kind: PostgreSQLInstance141metadata:142 name: user-db143spec:144 size: small # Abstraction: small = 2 vCPU, 4GB RAM145 version: "16"146 backup: daily147 team: auth-team148```149150แทนที่จะกำหนดค่าพารามิเตอร์ RDS, ซับเน็ต VPC, กลุ่มความปลอดภัย และนโยบายสำรองข้อมูล นักพัฒนาเพียงระบุ `size: small` และ `backup: daily` แพลตฟอร์มจัดการส่วนที่เหลือ151152### ชั้นที่ 3: การมาตรฐาน CI/CD153154มาตรฐาน CI/CD เพื่อไม่ให้แต่ละทีมสร้างไปป์ไลน์ของตัวเอง155156```yaml157# .github/workflows/platform-ci.yml158# Teams just include the shared workflow159name: Build and Deploy160on:161 push:162 branches: [main]163164jobs:165 pipeline:166 uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2167 with:168 language: node169 deploy-target: production170 secrets: inherit171```172173**แนวปฏิบัติสำคัญ:**174- เทมเพลต CI/CD ที่ใช้ร่วมกัน ทีมรวมเข้า (ไม่ใช่คัดลอก)175- การสแกนความปลอดภัยอัตโนมัติ (SAST, การตรวจสอบการพึ่งพา)176- กลยุทธ์การปรับใช้มาตรฐาน (canary, blue/green)177- การย้อนกลับอัตโนมัติเมื่อ health check ล้มเหลว178179### ชั้นที่ 4: การสังเกตการณ์180181การตรวจสอบที่กำหนดค่าไว้ล่วงหน้าเพื่อให้นักพัฒนาได้แดชบอร์ดและการแจ้งเตือนพร้อมใช้งาน182183- **เมตริก**: Prometheus + Grafana พร้อมแดชบอร์ดมาตรฐานต่อบริการ184- **การบันทึก**: การบันทึกแบบมีโครงสร้างพร้อมการรวบรวมจากศูนย์กลาง (Loki, ELK)185- **การติดตาม**: การติดตามแบบกระจายด้วย OpenTelemetry186- **การแจ้งเตือน**: การผสาน PagerDuty/Opsgenie พร้อมค่าเริ่มต้นที่เหมาะสม187188```mermaid189graph LR190 Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]191 Collector --> Prometheus[Prometheus]192 Collector --> Loki[Loki]193 Collector --> Tempo[Tempo]194 Prometheus --> Grafana[Grafana Dashboards]195 Loki --> Grafana196 Tempo --> Grafana197 Grafana --> PagerDuty[PagerDuty Alerts]198```199200## การวัดความสำเร็จ201202คุณจะรู้ได้อย่างไรว่าแพลตฟอร์มของคุณทำงานได้ดี? ติดตามเมตริกเหล่านี้:203204### เมตริก DORA205- **ความถี่ในการปรับใช้**: โค้ดไปถึง production บ่อยแค่ไหน206- **เวลานำสำหรับการเปลี่ยนแปลง**: เวลาจาก commit ถึง production207- **อัตราความล้มเหลวของการเปลี่ยนแปลง**: เปอร์เซ็นต์ของการปรับใช้ที่ทำให้เกิดความล้มเหลว208- **เวลาเฉลี่ยในการกู้คืน**: เวลาในการกู้คืนบริการหลังเหตุการณ์209210### เมตริกเฉพาะแพลตฟอร์ม211- **เวลาจนถึงการปรับใช้ครั้งแรก**: นานแค่ไหนจาก "บริการใหม่" ถึงการปรับใช้ production ครั้งแรก212- **ความพึงพอใจของนักพัฒนา (NPS)**: สำรวจผู้ใช้ของคุณเป็นประจำ213- **อัตราบริการตนเอง**: % ของคำขอโครงสร้างพื้นฐานที่จัดการโดยไม่ต้องมีตั๋ว214- **การยอมรับ golden path**: % ของบริการที่ทำตามเส้นทางที่แนะนำ215216## ข้อผิดพลาดที่พบบ่อย217218### 1. สร้างมากเกินไป เร็วเกินไป219เริ่มจากจุดที่เจ็บปวดที่สุด ไม่ใช่วิสัยทัศน์ยิ่งใหญ่ ถ้าการปรับใช้เจ็บปวด เริ่มจากตรงนั้น ถ้าการจัดเตรียมใช้เวลาหลายสัปดาห์ เริ่มจากตรงนั้น220221### 2. ไม่ปฏิบัติต่อแพลตฟอร์มเป็นผลิตภัณฑ์222ทีมแพลตฟอร์มต้องการ product manager การวิจัยผู้ใช้ และวงจรข้อมูลป้อนกลับ นักพัฒนาเป็นลูกค้าของคุณ - เข้าใจความต้องการของพวกเขา223224### 3. บังคับแทนที่จะดึงดูด225แพลตฟอร์มที่ดีที่สุดถูกยอมรับโดยสมัครใจเพราะทำให้ชีวิตนักพัฒนาง่ายขึ้น ถ้าคุณต้องบังคับการใช้งาน แพลตฟอร์มของคุณยังไม่ดีพอ226227### 4. ละเลยประสบการณ์นักพัฒนา228แพลตฟอร์มที่มี UX แย่จะไม่ถูกใช้งาน ลงทุนในเอกสารที่ชัดเจน ข้อความแสดงข้อผิดพลาดที่เป็นประโยชน์ และวงจรข้อมูลป้อนกลับที่รวดเร็ว229230## เริ่มต้น231232แผนงานปฏิบัติสำหรับการสร้าง IDP แรกของคุณ:233234```mermaid235flowchart TD236 A[Month 1-2: Discovery] --> B[Month 3-4: MVP]237 B --> C[Month 5-6: Iterate]238 C --> D[Month 7+: Scale]239240 A --> A1[Interview developers]241 A --> A2[Map pain points]242 A --> A3[Choose first golden path]243244 B --> B1[Deploy Backstage]245 B --> B2[First service template]246 B --> B3[Standardized CI/CD]247248 C --> C1[Gather feedback]249 C --> C2[Add infrastructure abstraction]250 C --> C3[Improve docs and onboarding]251252 D --> D1[More templates and golden paths]253 D --> D2[Self-service infrastructure]254 D --> D3[Advanced observability]255```256257### แพลตฟอร์มขั้นต่ำที่ใช้งานได้2582591. **แคตตาล็อกบริการ** (Backstage) - รู้ว่ามีอะไรอยู่และใครเป็นเจ้าของ2602. **เทมเพลตบริการหนึ่งอัน** - golden path สำหรับประเภทบริการที่พบบ่อยที่สุด2613. **CI/CD มาตรฐาน** - ไปป์ไลน์ที่ใช้ร่วมกัน ทีมรวมเข้า2624. **เอกสารพื้นฐาน** - วิธีใช้แพลตฟอร์ม หาความช่วยเหลือที่ไหน263264คุณสามารถสร้าง MVP นี้ได้ใน 2-3 เดือนด้วยทีม 2-3 วิศวกร265266## สรุป267268Platform Engineering ไม่ใช่การสร้างแพลตฟอร์มที่สมบูรณ์แบบตั้งแต่วันแรก มันคือการลดภาระทางปัญญาของนักพัฒนาทีละน้อยเพื่อให้พวกเขาสามารถมุ่งเน้นไปที่การสร้างผลิตภัณฑ์ เริ่มจากเล็กๆ วัดผลกระทบ และทำซ้ำตามข้อมูลป้อนกลับของนักพัฒนา269270องค์กรที่ลงทุนใน Platform Engineering จะมีข้อได้เปรียบในการแข่งขันอย่างมีนัยสำคัญ: การส่งมอบที่เร็วขึ้น นักพัฒนาที่มีความสุขมากขึ้น และระบบที่เชื่อถือได้มากขึ้น271272**แหล่งข้อมูล:**273- [Team Topologies](https://teamtopologies.com/) - หนังสือที่ทำให้ทีมแพลตฟอร์มเป็นที่นิยม274- [Backstage](https://backstage.io/) - พอร์ทัลนักพัฒนาโอเพนซอร์สของ Spotify275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) - คำจำกัดความของชุมชนและแนวปฏิบัติที่ดีที่สุด276- [platformengineering.org](https://platformengineering.org/) - ชุมชน กิจกรรม และแหล่งข้อมูล277
:Platform Engineering: วิธีสร้าง Internal Developer Platformlines 1-277 (END) — press q to close