Internal Developer Platform (IDP) คืออะไร? ทำไมบริษัทเทคโนโลยีถึงต้องมี?

บทความนี้ถูกย้ายมาจาก blog เก่าของผมบน Medium แต่ได้ถูกปรับปรุงและเรียบเรียงเนื้อหาใหม่แล้ว

หลังจากที่ผมได้เขียนบทความอธิบายเกี่ยวกับ platform engineering ไปแล้ว ในบทความนี้จะมาเจาะกันที่ platform หรือที่เรียกกันว่า internal developer platform (IDP) กันต่อ โดยผมจะอธิบายความหมาย, ประโยชน์ และ tools ที่ใช้ในการสร้าง IDP

Table of Contents

• บทนำ (Introduction)
• Internal Developer Platform (IDP) คืออะไร?
  • ตัวอย่างการใช้ Internal Developer Platform (IDP)
  • Use Cases อื่น ๆ ที่อาจมีใน Internal Developer Platform (IDP)
• ประโยชน์ของ Internal Developer Platform (IDP)
  • ประสิทธิภาพการทำงานดีขึ้น
  • การเริ่มต้นทำงาน (Onboarding) ของสมาชิกใหม่ง่ายขึ้น
  • ควบคุม Practices และ Standard ง่ายขึ้น
  • การทำงานร่วมกันที่ดีขึ้น
• ส่วนประกอบของ Internal Developer Platform (IDP)
• Tools ที่ใช้สร้าง Internal Developer Platform (IDP)
  • Cloud Native Operational Excellence (CNOE)
• บทสรุป (Conclusion)

บทนำ (Introduction)

ในยุค cloud native ที่รูปแบบการทำงานของ developer และ operations เริ่มเปลี่ยนไป ฝั่ง developer ต้องการความคล่องตัวมากขึ้น ในขณะที่ฝั่ง operations ก็ต้องการให้ resource ต่าง ๆ มีมาตรฐานและปลอดภัย ความต้องการของทั้ง 2 ฝ่ายนำไปสู่การเกิดขึ้นของ internal developer platform (IDP) และในบทความนี้เราจะมาทำความรู้จัก IDP กันครับ

Internal Developer Platform (IDP) คืออะไร?

สำหรับ internal developer platform (IDP) นั้น บางครั้งก็ถูกเรียกว่า developer portal จะเรียกอะไรก็ตามมันคือ self-service platform ซึ่งทำหน้าที่เป็นด่านหน้าที่ช่วยลดความซับซ้อนของการเตรียม infrastructure และ services ช่วยเพิ่มความเร็วในกระบวนการพัฒนา application ภายในบริษัท

Internal Developer Platform (IDP) คือ product ที่สร้างโดยทีม platform engineering โดยมี user เป็น developer ภายในบริษัทเดียวกัน

แทนที่ developer จะต้องรอทีม operations เตรียม infrastructure สำหรับการพัฒนา application ให้ การมี IDP ภายในองค์กรทำให้ developer สามารถที่จะจัดการกับ software ecosystem ต่าง ๆ ได้ด้วยตัวเองทันที ซึ่งอาจจะเป็น server, Kubernetes cluster, database, cache, message broker, queue, encryption key, email service, domain name, CI/CD pipeline และอื่น ๆ

ลองนึกถึงการเลือกซื้อเครื่องดื่มที่ตู้อัตโนมัติ(แบรนด์ ต.)เจ้าหนึ่งก็ได้ครับ มันง่าย มันถูกเตรียมและคิดมาเป็นอย่างดีแล้วว่ากาแฟลาเต้เย็นหรือโกโก้ปั่นแก้วหนึ่งต้องมีส่วนผสมของอะไรและเท่าไรบ้าง ลูกค้าแทบไม่จำเป็นต้องมีความรู้ความเข้าใจอะไรเกี่ยวกับเครื่องดื่มนั้นเลย

ตัวอย่างการใช้ Internal Developer Platform (IDP)

เช่นเดียวกับ IDP ที่ developer สามารถ login เข้าไปและเลือกสร้างสิ่งต่าง ๆ ที่ต้องใช้ในการพัฒนา application ผ่าน GUI (หรือ CLI และ API) ได้ตามต้องการ เช่น อยากได้ PostgreSQL database ขนาด 100 GB บน AWS ก็ใส่รายละเอียดตามที่กำหนดแล้วคลิกสร้างได้เลย ระบบจะ generate code ขึ้นมาใน Git repository จากนั้น CI/CD pipeline ก็จะถูก trigger เพื่อสร้าง database ขึ้นมา

Service catalog ก็เป็นส่วนหนึ่งของ internal developer platform (IDP)

โดย infrastructure หรือ services ที่สร้างขึ้นผ่าน IDP นั้นได้ถูกกำหนดและควบคุม policy ต่าง ๆ จากส่วนกลางอย่างทีม platform engineering ไว้หมดแล้ว เช่น ต้องสร้าง network แบบไหน, กำหนด firewall rules ยังไง, ต้อง backup ยังไง หรือจะต้อง tag อะไรบ้างใน resource นั้นเพื่อให้สามารถจัดการได้ง่าย เป็นต้น

และ IDP เองก็ไม่ได้มีความสามารถแค่เรื่อง self-service provisioning เท่านั้น ยังรวมไปถึงเรื่อง inventory (รู้ว่า application ไหนประกอบด้วย service อะไรบ้าง เกี่ยวข้องกันยังไง) หรือจะเป็นเรื่องของการเข้าถึงหรือ monitor service ที่สร้างขึ้น เช่น นอกจาก developer จะสร้าง Kubernetes cluster เองผ่าน IDP แล้ว อาจสามารถเข้าถึง cluster หรือดู status ได้ผ่านทาง IDP ด้วย

Use Cases อื่น ๆ ที่อาจมีใน Internal Developer Platform (IDP)

• สร้าง scaffold service (อย่าง repository, directory structure, Dockerfile, CI/CD pipelines และอื่น ๆ สำหรับ project ใหม่)
• สร้าง ephemeral environment (ชั่วคราว) เช่น Kubernetes cluster
• สร้าง cloud resources เช่น network, database, object storage, message broker, queue และอื่น ๆ
• สร้าง secrets และ ingest secrets
• จัดการ knowledge base เช่น documents หรือ guide
• การทำ day-2 operations ต่าง ๆ เช่น
  • ขอ temporary permission เพื่อเข้าถึง cluster หรือ services ชั่วคราว
  • การ deploy, restart, rollback services
  • การลบ cluster หรือ services
  • การ monitor เช่น cluster, services, CI/CD pipeline และอื่น ๆ

ประโยชน์ของ Internal Developer Platform (IDP)

ประสิทธิภาพการทำงานดีขึ้น

• ฝั่งทีม Developer: ทำงานได้อย่างมีประสิทธิภาพและรวดเร็วมากขึ้นด้วยการใช้แค่ platform interface เดียว ทำให้สามารถโฟกัสไปที่การเขียน code และ deploy application ได้โดยไม่ต้องกังวลเกี่ยวกับ infrastructure ไม่ติดคอขวดที่ทีม operations

• ฝั่งทีม Operations: ลด workload ของทีม operations ทำให้มีเวลาไปโฟกัสที่การคิดและกำหนด architecture, standard, policy หรือ compliance สำหรับ infrastructure ซึ่งเป็นเรื่องที่สำคัญกว่า(การ provisioning)

การเริ่มต้นทำงาน (Onboarding) ของสมาชิกใหม่ง่ายขึ้น

การมี internal developer platform (IDP) ช่วยให้สมาชิกหน้าใหม่ในทีม (โดยเฉพาะฝั่ง developer) สามารถเข้าใจและเริ่มต้นทำงานได้เร็วขึ้น เนื่องจากพวกเค้าแค่เรียนรู้การใช้ platform เดียวแทนที่จะต้องเรียนรู้​ tools หรือ practices หลาย ๆ ตัว

ควบคุม Practices และ Standard ง่ายขึ้น

บริษัทสามารถบังคับใช้ practices และ standard ได้ทั่วทั้งองค์กรง่ายขึ้น ลดโอกาสที่จะเกิดปัญหาต่าง ๆ ได้ เช่น ช่วยให้จัดการ resource utilization ได้ดีขึ้น, คุมค่าใช้จ่ายได้ดีขึ้น และโดยเฉพาะในมุม security เนื่องจาก policy ถูกกำหนดและควบคุมผ่าน platform จากกลุ่มคนที่มีความเข้าใจใน infrastructure จริง ๆ เพียงกลุ่มเดียว

การทำงานร่วมกันที่ดีขึ้น

ด้วยการรวมศูนย์ (centralized) กระบวนการและ tools ในการพัฒนา ช่วยให้การทำงานร่วมกันระหว่างสมาชิกในทีมและต่างทีมดีขึ้น เข้าใจกันง่ายขึ้น tools ต่าง ๆ มีความสอดคล้องและเข้ากันได้ ช่วยลดปัญหาจุกจิก (โดยเฉพาะการ integrate service ที่ต่างคนต่างทำเข้าด้วยกัน)

ส่วนประกอบของ Internal Developer Platform (IDP)

แน่นอนว่าไม่มีอะไรเป็น one-size-fits-all อยู่แล้ว แต่โดยทั่วไปมักจะมีส่วนประกอบ 5 ส่วนดังนี้

1. Control Plane: เป็นส่วนที่ developer ใช้งานโดยตรง เช่น developer portal, API/CLI, หรือ configuration ต่าง ๆ อย่าง Kubernetes manifest, Helm charts หรือ Terraform config
2. Integration Delivery Plane: ส่วนที่เชื่อมต่อระหว่าง control plane และ application runtime เช่น CI pipeline (build application code, run test และสร้าง artifact) หรือ CD pipeline (นำ artifact ไป deploy บน infrastructure)
3. Resource Plane: infrastructure หรือ services ต่าง ๆ ที่ application ต้องการ เข่น Kubernetes cluster, network หรือ database ซึ่งก็มักจะมาจาก cloud platform อย่าง AWS, Azure หรือ GCP
4. Security Plane: เกี่ยวข้องกับความปลอดภัย เช่น policy, compliance, secrets manager หรือ identity management
5. Observability Plane: เกี่ยวข้องกับ logs, metrics, หรือ traces ทั้งหมด

Tools ที่ใช้สร้าง Internal Developer Platform (IDP)

การสร้าง internal developer platform (IDP) เองทั้งหมดตั้งแต่เริ่มนั้นไม่ practical เท่าไร เราสามารถใช้ tools หรือ practices ที่มีอยู่ช่วยสร้าง IDP ที่ตรงตามความต้องการของบริษัทเราขึ้นมาได้

โดยใครที่สนใจสามารถไปศึกษาเพิ่มเติมได้ที่…

• เลือก tools จาก CNCF Tools Lanscape
• ดูแนวทางจากการสร้าง IDP จาก Platform Tooling Landscape จาก Platform Engineering
• ดูแนวทางจากการสร้าง IDP จาก Cloud Native Operational Excellence (CNOE)

เดี๋ยวขอยกตัวอย่างจากฝั่ง CNOE เพิ่มสักหน่อยแล้วกันครับ

Cloud Native Operational Excellence (CNOE)

• เป็นกลุ่ม community ที่ร่วมกันก่อตั้งโดย Adobe, AWS, Autodesk, Salesforce และ Twilio โดยมีเป้าหมายในการเลือก tools จาก CNCF เข้ามาช่วยยกระดับความสามารถในการพัฒนาของ developer ภายในองค์กร
• CNOE ช่วยองค์กรในการเลือกใช้ open-source software (OSS) เพื่อสร้าง internal developer platform (IDP) ในการแก้ไขปัญหาความท้าทายของ DevOps
• CNOE โฟกัสไปที่การเลือก tool ให้เข้ากับองค์กร โดยมุ่งหวังที่จะลดความซับซ้อนวุ่นวายในการเลือก tools, plugins หรือ configurations ลง

และนี่คือ tools แต่ละประเภทที่ CNOE แนะนำสำหรับการสร้าง IDP (ณ ปัจจุบัน)

• Code Repository: Git
• Config Repository: Git
• Artifact Registry: Container Registries
• Secret Repository: External Secrets (บวกกับ HashiCorp Vault และ AWS KMS)
• Validations: CNOE Validators
• Secret Management: External Secrets
• Infra as Code: Terraform, Crossplane
• Continuous Delivery: Argo CD, Flux
• Continuous Integrations: Argo Workflows, Tekton
• Identity & Access: KeyCloak
• Developer Portals: Backstage

บทสรุป (Conclusion)

ปัจจุบันการพัฒนา application มีความซับซ้อนมากขึ้น นอกจากการนำ DevOps เข้ามาใช้แล้ว การมี internal developer platform (IDP) ถือเป็นอีกหนึ่ง solution ที่ช่วยเพิ่มความรวดเร็วในกระบวนการพัฒนา application ของ developerม ช่วยให้ทีม operations ทำงานได้ง่ายและช่วยควบคุม standard ได้ดีขึ้นด้วย

แม้โดยทั่วไปแล้วหลายคนอาจมองว่าการลงทุนสร้าง IDP ในบริษัทขนาดเล็กที่มีทีมงานไม่กี่คนและระบบไม่ซับซ้อนมากอาจจะไม่คุ้มค่าเท่าไร เพราะ IDP อาจจะเหมาะกับบริษัทขนาดกลางขึ้นไปที่มีทีม developer และ operations ประมาณหนึ่งและมีการพัฒนา application หลายตัวภายในองค์กร แต่ส่วนตัวผมก็ยังมองว่าเราสามารถที่จะสร้าง IDP แบบ lite version ได้ และด้วย scale ขนาดเล็กของบริษัทก็อาจทำให้การพัฒนา IDP ไม่ได้ยุ่งยากขนาดนั้นก็ได้ (ถ้ามีคนว่างทำหนะนะ 😂) เพราะสุดท้ายแล้ว features ของ IDP นั้นไม่ตายตัว มันขึ้นอยู่กับบริบทของแต่ละองค์กรครับ