Gitpod ตัดสินใจออกจาก Kubernetes + เปิดตัว Gitpod Flex

• Gitpod ใช้งาน Kubernetes มา 6 ปีเพื่อสร้าง "แพลตฟอร์มสภาพแวดล้อมการพัฒนาระยะไกล" และปัจจุบันรองรับผู้ใช้ 1.5 ล้านคน พร้อมให้บริการสภาพแวดล้อมการพัฒนาหลายพันรายการต่อวัน
• แต่ก็ได้ตระหนักว่า Kubernetes ไม่เหมาะกับการสร้างสภาพแวดล้อมการพัฒนา
• นี่ไม่ใช่เรื่องว่าจะใช้ Kubernetes กับ production workload หรือไม่ และก็ไม่ใช่หัวข้อเกี่ยวกับวิธีสร้างประสบการณ์นักพัฒนาสำหรับการ deploy แอปพลิเคชันบน K8s
  → แต่เป็นเรื่องของวิธีสร้างสภาพแวดล้อมการพัฒนาบนคลาวด์ (หรือวิธีที่ไม่ควรทำ)

[ทำไมสภาพแวดล้อมการพัฒนาจึงพิเศษ]

• มี state จำนวนมากและมีการโต้ตอบสูง
  • ไม่สามารถย้ายข้าม node ได้
  • source code จำนวนมาก, build cache, Docker container, test data ฯลฯ เปลี่ยนแปลงบ่อยและมีต้นทุนในการย้ายสูง
  • ต่างจาก production service เพราะมีการโต้ตอบแบบ 1:1 ระหว่างนักพัฒนากับสภาพแวดล้อม
• นักพัฒนาเกี่ยวข้องกับ source code และการเปลี่ยนแปลงอย่างลึกซึ้ง
  • ไม่ชอบการสูญเสียการเปลี่ยนแปลงของ source code หรือการถูกระบบขัดขวาง
  • สภาพแวดล้อมการพัฒนาไวต่อความล้มเหลวเป็นพิเศษ
• มีรูปแบบการใช้ทรัพยากรที่คาดเดาไม่ได้
  • เวลาส่วนใหญ่ไม่ต้องการ CPU bandwidth มาก แต่ภายในไม่กี่ร้อย ms อาจต้องใช้หลายคอร์
  • ถ้าช้ากว่านั้นจะเกิดอาการหน่วงและไม่ตอบสนองที่ยอมรับไม่ได้
• ต้องการสิทธิ์และความสามารถที่กว้างขวาง
  • ต่างจาก production workload เพราะต้องการ root access และความสามารถในการดาวน์โหลด/ติดตั้งแพ็กเกจ
  • สิ่งที่ถือเป็นปัญหาด้านความปลอดภัยใน production workload กลับเป็นพฤติกรรมที่คาดหวังในสภาพแวดล้อมการพัฒนา (root access, ความสามารถเครือข่ายแบบขยาย, การ mount filesystem เพิ่มเติม ฯลฯ)
• คุณลักษณะเหล่านี้ทำให้มันแตกต่างจาก application workload ทั่วไป และส่งผลอย่างมากต่อการตัดสินใจด้านโครงสร้างพื้นฐาน

[ระบบปัจจุบัน: Kubernetes]

• ในช่วงแรกของ Gitpod, Kubernetes ดูเหมือนจะเป็นตัวเลือกด้านโครงสร้างพื้นฐานที่เหมาะสม
  • scalability, container orchestration และ ecosystem ที่อุดมสมบูรณ์ สอดคล้องกับวิสัยทัศน์เรื่องสภาพแวดล้อมการพัฒนาบนคลาวด์
• แต่เมื่อขยายขนาดและฐานผู้ใช้เพิ่มขึ้น ก็พบความยากลำบากด้านความปลอดภัยและการจัดการ state
  • Kubernetes ถูกออกแบบมาเพื่อรัน application workload ที่ควบคุมได้ดี ไม่ใช่สำหรับสภาพแวดล้อมการพัฒนาที่จัดการยาก
• การดูแล Kubernetes ในระดับขนาดใหญ่มีความซับซ้อน
  • managed service อย่าง GKE, EKS ช่วยบรรเทาปัญหาบางส่วน แต่ก็มีข้อจำกัดและขีดจำกัดของมันเอง
• หลายทีมที่ต้องการรัน CDE มักประเมินความซับซ้อนของ Kubernetes ต่ำเกินไป
  • สิ่งนี้นำไปสู่ภาระด้านการซัพพอร์ตอย่างมากในผลิตภัณฑ์ Gitpod แบบ self-managed ก่อนหน้านี้

ความยากของการจัดการทรัพยากร

• การจัดสรร CPU และ memory คือความท้าทายที่ใหญ่ที่สุด
• การแชร์สภาพแวดล้อมบน node เดียวกันดูน่าสนใจ แต่ในความเป็นจริงผลกระทบจาก noisy neighbor รุนแรงมาก
• ปัญหา CPU
  • สภาพแวดล้อมการพัฒนาอาจไม่ต้องใช้ CPU มากตลอดเวลา แต่บางช่วงก็ต้องการสูงแบบฉับพลัน
  • เคยทดลองทั้งโซลูชันที่อิง CFS และ custom controller แต่คาดการณ์ได้ยาก
  • แม้ใช้ static CPU limit ก็ยังเกิดปัญหาหลาย process แข่งขันกัน
• การจัดการ memory
  • การจัดสรร memory แบบคงที่ทำได้ง่ายแต่มีข้อจำกัด
  • การ overbook อาจนำไปสู่การ kill process
  • การเพิ่ม swap space ช่วยลดความจำเป็นในการ overbook ลงได้บางส่วน

การปรับแต่งประสิทธิภาพ storage

• IOPS และ latency ส่งผลต่อประสบการณ์ใช้งานสภาพแวดล้อมการพัฒนา
• ได้ทดลองหลายรูปแบบเพื่อหาสมดุลระหว่างความเร็ว, ความเสถียร, ต้นทุน และประสิทธิภาพ
  • SSD RAID 0
  • block storage เช่น EBS, persistent disk
  • PVC
• การ backup/restore เป็นงานที่มีต้นทุนสูง

การปรับแต่ง autoscaling และเวลาเริ่มต้น

• การลดเวลาเริ่มต้นให้ต่ำที่สุดคือเป้าหมายสูงสุด
• เคยคิดว่าการรัน workspace หลายตัวบน node เดียวจะช่วยให้เวลาเริ่มต้นดีขึ้นเพราะมี shared cache แต่ผลไม่เป็นเช่นนั้น
• Kubernetes กำหนดเพดานล่างของเวลาเริ่มต้นไว้
• วิวัฒนาการของวิธี scale-out
  • ทดลอง scale-out โดยใช้ ghost workspace, ballast pod ฯลฯ
  • การนำ autoscaler plugin มาใช้ช่วยปรับปรุงกลยุทธ์การขยายได้มาก
• proportional autoscaling สำหรับรองรับ peak load
  • เริ่ม pod ว่างไว้ล่วงหน้าเพื่อตอบสนองต่อความต้องการที่พุ่งขึ้นอย่างรวดเร็ว
• ความพยายามหลายแบบเพื่อปรับแต่ง image pull
  • DaemonSet pre-pull, การใช้ layer ซ้ำให้มากที่สุด, pre-baked image, Stargazer กับ lazy pulling, Registry-facade + IPFS

ความซับซ้อนด้านเครือข่าย

• การควบคุมการเข้าถึงสภาพแวดล้อมการพัฒนา
  • ต้องแยกจากกันอย่างสมบูรณ์ระหว่างแต่ละสภาพแวดล้อม
  • network policy ช่วยได้ แต่เมื่อจำนวน service มากขึ้นก็เกิดปัญหาด้านความน่าเชื่อถือ
• การแชร์ network bandwidth
  • บาง CNI รองรับ network shaping แต่ก็กลายเป็นอีกสิ่งที่ต้องควบคุม

ความปลอดภัยและการแยกขอบเขต: สมดุลระหว่างความยืดหยุ่นกับการปกป้อง

• ความท้าทายที่ใหญ่ที่สุดคือการมอบความยืดหยุ่นให้ผู้ใช้พร้อมกับรักษาสภาพแวดล้อมให้ปลอดภัย
• การให้สิทธิ์ root กับผู้ใช้มีข้อบกพร่องมาก
• user namespace เป็นทางออกที่ละเอียดกว่า
  • การแปลง filesystem UID, masked proc mount, รองรับ FUSE, ให้ความสามารถเครือข่าย, เปิดใช้งาน Docker
• ความยากของการนำ user namespace ไปใช้
  • ผลกระทบด้านประสิทธิภาพ, ปัญหาความเข้ากันได้, ความซับซ้อน, การรองรับเวอร์ชัน Kubernetes

[การทดลอง Micro VM]

• เมื่อรับรู้ถึงข้อจำกัดของ Kubernetes จึงเริ่มสำรวจเทคโนโลยี micro VM (uVM) เช่น Firecracker, Cloud Hypervisor, QEMU ในฐานะจุดกึ่งกลาง
• คาดหวังว่าจะยังคงข้อดีของ containerization เอาไว้ได้ พร้อมทั้งปรับปรุงการแยกทรัพยากร, ความเข้ากันได้กับ workload อื่น ๆ (เช่น Kubernetes) และเสริมความปลอดภัย
• ข้อดีของ micro VM
  • มอบจุดเด่นที่น่าสนใจซึ่งสอดคล้องอย่างมากกับเป้าหมายของ cloud development environment
  • การแยกทรัพยากรที่ดีขึ้น: แม้ความสามารถในการ overbook จะลดลง แต่การแยกทรัพยากรดีกว่า container ทำให้ไม่มีการแย่ง shared kernel resource และคาดการณ์ประสิทธิภาพของแต่ละสภาพแวดล้อมได้มากขึ้น
  • memory snapshot และการ resume อย่างรวดเร็ว: ฟีเจอร์ userfaultfd ของ Firecracker รองรับ memory snapshot ทำให้สามารถ resume ทั้งเครื่องได้แทบจะทันทีรวมถึง process ที่กำลังรันอยู่ จากมุมมองของนักพัฒนา การเริ่มสภาพแวดล้อมจะเร็วขึ้นมากและกลับมาทำงานต่อจากจุดที่ค้างไว้ได้ทันที
  • ขอบเขตความปลอดภัยที่ดีขึ้น: uVM สามารถเป็น security boundary ที่แข็งแรง ทำให้ไม่จำเป็นต้องใช้กลไก user namespace ที่ซับซ้อนซึ่งเคยสร้างบน Kubernetes อีกต่อไป และอาจเข้ากันได้อย่างสมบูรณ์กับ workload ที่กว้างขึ้น รวมถึง nested containerization (การรัน Docker หรือ Kubernetes ภายในสภาพแวดล้อมการพัฒนา)
• ความยากของ micro VM
  • แต่ผลการทดลอง micro VM ก็เผยให้เห็นความท้าทายสำคัญหลายอย่าง
  • overhead: แม้จะเป็น VM น้ำหนักเบา แต่ uVM ก็ยังมี overhead มากกว่า container ส่งผลทั้งต่อประสิทธิภาพและการใช้ทรัพยากร ซึ่งเป็นประเด็นสำคัญสำหรับแพลตฟอร์ม cloud development environment
  • การแปลง image: การแปลง OCI image ให้เป็น filesystem ที่ใช้ได้บน uVM ต้องพึ่งโซลูชันแบบ custom ทำให้ pipeline การจัดการ image ซับซ้อนขึ้นและอาจกระทบเวลาเริ่มต้น
  • ข้อจำกัดเฉพาะเทคโนโลยี
    • Firecracker: ไม่มี GPU support (ซึ่งสำคัญขึ้นเรื่อย ๆ สำหรับบาง workflow การพัฒนา), ไม่มี virtiofs support (จำกัดตัวเลือกการแชร์ filesystem อย่างมีประสิทธิภาพ)
    • Cloud Hypervisor: ไม่มี userfaultfd support ทำให้กระบวนการ snapshot และ restore ช้าลง (หักล้างข้อดีหลักของ uVM)
  • ปัญหาการเคลื่อนย้ายข้อมูล: uVM ทำให้ต้องจัดการ memory snapshot ขนาดใหญ่ จึงยิ่งทำให้การย้ายข้อมูลยากขึ้น ส่งผลทั้งต่อ scheduling และเวลาเริ่มต้น ซึ่งเป็นองค์ประกอบหลักของประสบการณ์ผู้ใช้ cloud development environment
  • ประเด็นด้าน storage: การทดลองเชื่อม EBS volume เข้ากับ micro VM เปิดความเป็นไปได้ใหม่ แต่ก็สร้างคำถามใหม่ตามมา
    • persistent storage: หากเก็บเนื้อหาของ workspace ไว้ใน volume ที่เชื่อมต่อ ก็ไม่จำเป็นต้องดึงข้อมูลซ้ำจาก S3 จึงคาดว่าจะช่วยลดเวลาเริ่มต้นและลดการใช้เครือข่าย
    • ข้อพิจารณาด้านประสิทธิภาพ: การแชร์ volume throughput สูงระหว่าง workspace อาจช่วยปรับปรุงประสิทธิภาพ I/O แต่ก็มีความกังวลเรื่องการทำ quota อย่างมีประสิทธิภาพ, การจัดการ latency และการรับประกัน scalability
• บทเรียนจากการทดลอง micro VM
  • แม้ท้ายที่สุด micro VM จะไม่ได้กลายเป็นโซลูชันโครงสร้างพื้นฐานหลัก แต่การทดลองนี้ให้ข้อมูลเชิงลึกที่มีคุณค่า
  • พวกเขาชอบประสบการณ์ของการ backup ทั้ง workspace และการ suspend/resume state ขณะรันสำหรับสภาพแวดล้อมการพัฒนา
  • นี่เป็นครั้งแรกที่เริ่มพิจารณาการออกจาก Kubernetes หลังจากพยายามผสาน KVM และ uVM เข้ากับ pod ก็เริ่มสำรวจทางเลือกนอก Kubernetes
  • มองเห็นอีกครั้งว่า storage คือองค์ประกอบหลักในการมอบทั้งประสิทธิภาพการเริ่มต้นที่คงที่, workspace ที่เสถียร (ป้องกันข้อมูลสูญหาย) และการใช้เครื่องอย่างเหมาะสมที่สุด

Kubernetes มีความท้าทายอย่างมากในฐานะแพลตฟอร์มสำหรับสภาพแวดล้อมการพัฒนา

• อย่างที่กล่าวไป earlier การรองรับสภาพแวดล้อมการพัฒนาต้องอาศัยระบบที่เคารพความเป็น stateful อันเป็นเอกลักษณ์ของมัน
• ต้องมอบสิทธิ์ที่นักพัฒนาจำเป็นต้องมีเพื่อทำงานได้อย่างมีประสิทธิภาพ พร้อมกับรับประกัน security boundary ที่ปลอดภัย
• ทั้งหมดนี้ต้องทำโดยรักษา operational overhead ให้ต่ำและไม่ประนีประนอมด้านความปลอดภัย
• ปัจจุบัน การทำทั้งหมดนี้ด้วย Kubernetes เป็นไปได้ แต่มีต้นทุนสูงมาก
• พวกเขาได้เรียนรู้ความแตกต่างระหว่าง application workload กับ system workload ผ่านประสบการณ์ตรงอันหนักหน่วง
• Kubernetes ยอดเยี่ยมอย่างน่าเหลือเชื่อ
• ได้สร้าง ecosystem ที่อุดมสมบูรณ์อย่างแท้จริงด้วยการสนับสนุนจากชุมชนที่เปี่ยมด้วยพลัง
• หากเป็นการรัน application workload, Kubernetes ก็ยังเป็นตัวเลือกที่ดี
• แต่สำหรับ system workload อย่างสภาพแวดล้อมการพัฒนา Kubernetes นำมาซึ่งความท้าทายมหาศาลทั้งด้านความปลอดภัยและ operational overhead
• micro VM และ budget ทรัพยากรที่ชัดเจนช่วยได้ แต่ต้นทุนกลับกลายเป็นปัจจัยที่เด่นกว่า
• ดังนั้น หลังจากใช้เวลาหลายปีในการย้อนออกแบบและฝืนทำให้สภาพแวดล้อมการพัฒนาทำงานบนแพลตฟอร์ม Kubernetes ได้อย่างมีประสิทธิภาพ พวกเขาจึงถอยกลับมาหนึ่งก้าวเพื่อคิดว่า developer architecture แห่งอนาคตควรมีหน้าตาอย่างไร
• ในเดือนมกราคม 2024 พวกเขาเริ่มสร้างสิ่งนี้ และในเดือนตุลาคมก็เปิดตัว Gitpod Flex
• ข้อมูลเชิงลึกที่ได้มาอย่างยากลำบากตลอดกว่า 6 ปีในการรันสภาพแวดล้อมการพัฒนาอย่างปลอดภัยในระดับอินเทอร์เน็ต ได้ถูกหลอมรวมไว้ในรากฐานของสถาปัตยกรรมนี้

อนาคตของสภาพแวดล้อมการพัฒนา

• ใน Gitpod Flex พวกเขารับเอาแก่นบางอย่างของ Kubernetes ได้แก่การประยุกต์ใช้ control theory อย่างยืดหยุ่นและ declarative API พร้อมกับทำให้สถาปัตยกรรมเรียบง่ายขึ้นและปรับปรุงรากฐานด้านความปลอดภัย
• ใช้ control plane ที่ได้รับแรงบันดาลใจอย่างมากจาก Kubernetes เพื่อทำ orchestration ของสภาพแวดล้อมการพัฒนา
• เพิ่ม abstraction layer ที่จำเป็นสำหรับสภาพแวดล้อมการพัฒนาโดยเฉพาะ และตัดความซับซ้อนของโครงสร้างพื้นฐานที่ไม่จำเป็นออกไปเกือบทั้งหมด
• ทั้งหมดนี้ทำโดยให้ zero-trust security เป็นลำดับความสำคัญสูงสุด
• สถาปัตยกรรมใหม่นี้ทำให้สามารถผสาน dev container ได้อย่างราบรื่น
• อีกทั้งยังเปิดความสามารถในการรันสภาพแวดล้อมการพัฒนาบนเดสก์ท็อปได้ด้วย
• ตอนนี้ไม่ต้องแบกรับภาระอันหนักของแพลตฟอร์ม Kubernetes อีกต่อไป Gitpod Flex จึงสามารถ deploy แบบ self-hosted ได้ภายใน 3 นาที และ deploy ได้ในจำนวน region ตามต้องการ
• สิ่งนี้ช่วยให้ควบคุมด้าน compliance ได้ละเอียดขึ้น และมีความยืดหยุ่นมากขึ้นในการจำลองขอบเขตและโดเมนขององค์กร

(เดิมทีเป็นคนละบทความ แต่คิดว่านำมารวมกันน่าจะดีกว่าเลยแปลมาด้วยกัน)

Gitpod Flex

• แพลตฟอร์ม automation ตัวแรกสำหรับสภาพแวดล้อมการพัฒนาแบบ zero trust
• ออกแบบมาให้รันได้บนแล็ปท็อป, คลาวด์ และ on-premise พร้อมเก็บ source code, data และทรัพย์สินทางปัญญาไว้ภายใน private network
• มอบ building block สำหรับการทำ automation ของวงจรชีวิตการพัฒนาซอฟต์แวร์ โดยเริ่มต้นจากสภาพแวดล้อมการพัฒนา
• Automations
  • งานและ service ที่เขียนโปรแกรมได้ ซึ่งกำหนดผ่าน repository หรือ API
  • สนับสนุนให้แก้ปัญหาได้ด้วยตัวนักพัฒนาเอง และช่วยให้ทีม developer productivity รวมศูนย์การปรับปรุงสภาพแวดล้อมการพัฒนาได้
  • ให้ความสามารถที่มากกว่าการรันสคริปต์แบบง่าย ๆ
  • สามารถทำได้ทั้ง provisioning และ seeding ฐานข้อมูล, ปรับแต่ง workflow ของนักพัฒนา, รัน cluster ชั่วคราว, ตั้งค่า workflow ของ agent ที่อิง LLM, บังคับใช้นโยบายความปลอดภัยและ compliance ระดับ global/region แบบรวมศูนย์ ฯลฯ
• Zero-trust environments
  • ตรวจสอบทุก actor และ service ภายใต้แนวคิด 'ไม่เคยเชื่อใจ แต่ตรวจสอบเสมอ'
  • ปิดกั้นผู้ไม่หวังดีได้อย่างสมบูรณ์ ลดพื้นที่เปิดรับการโจมตีลงอย่างมาก และลดความเสี่ยงจาก malware หรือการรั่วไหลของโค้ด
  • รวมถึงการประเมินอย่างต่อเนื่องและการตรวจสอบแบบชัดแจ้ง, การเข้ารหัสระดับองค์กรที่ผ่านการตรวจสอบแล้ว, การควบคุมการเข้าถึงแบบละเอียด, การควบคุมเครือข่ายอย่างสมบูรณ์ และ audit log แบบครบถ้วน
  • สิ่งที่สำคัญที่สุดคือการเก็บ source code, data และทรัพย์สินทางปัญญาไว้ภายใน private network
• Gitpod Desktop
  • ช่วยมาตรฐานและทำ automation ให้กับสภาพแวดล้อมการพัฒนาแบบ local ได้
  • เริ่มรองรับจาก Apple Silicon
  • มอบ zero latency, เป็นทางเลือกแทน Docker Desktop สำหรับงานพัฒนาที่เร็วกว่า เบากว่า และง่ายกว่า, ปรับต้นทุนให้เหมาะสมด้วยการใช้ local computing, และรองรับ disaster recovery เมื่อคลาวด์หรือ endpoint หยุดชะงัก
• รองรับ Development Container
  • ผสานข้อกำหนด Dev Container ได้อย่างสมบูรณ์
  • ใช้การตั้งค่า Dev Container เดิมได้โดยไม่ต้องแก้ไข
  • รองรับความเข้ากันได้กับ VS Code และเครื่องมืออื่น ๆ ที่รองรับ
  • ทำงานได้อย่างสม่ำเสมอทั้งบน local และ cloud
  • การยอมรับมาตรฐาน Dev Container ช่วยให้การกำหนด, แบ่งปัน และจัดการสภาพแวดล้อมการพัฒนาง่ายขึ้น

จะเป็นรากฐานของ automation ในการพัฒนาซอฟต์แวร์ตลอด 10 ปีข้างหน้า

• ที่ผ่านมาเรามองสภาพแวดล้อมการพัฒนาแคบเกินไป
• สภาพแวดล้อมการพัฒนาไม่ใช่แค่ IDE, dependency และเครื่องมือ แต่คือพื้นที่พื้นฐานที่ซอฟต์แวร์ถูกสร้างขึ้น
• เป็นที่สำหรับการทำ code prototype, การก่อรูปโดยมนุษย์และเครื่องจักร, การทดสอบ, refactoring, compilation, packaging, signing และ deployment
• มันมอบการเข้าถึงบริบทการพัฒนา, workflow และข้อมูลเชิงลึกอย่างหาที่เปรียบไม่ได้ จึงสร้างความสามารถที่แตกต่างจากแพลตฟอร์มพัฒนาอื่น
• วิสัยทัศน์ของผลิตภัณฑ์
  • continuous integration (CI) จะหลอมรวมเข้ากับสภาพแวดล้อมการพัฒนา
  • ทำหน้าที่เป็น system of record ของการพัฒนาซอฟต์แวร์
  • เป็นแพลตฟอร์มสำหรับเครื่องมือของนักพัฒนายุคถัดไป
• ไม่ได้หยุดแค่การปรับปรุงแนวปฏิบัติในการเขียนโค้ด แต่เป็นการสร้างวิธีที่เร็วและปลอดภัยที่สุดให้ธุรกิจตั้งแต่สตาร์ตอัปไปจนถึงบริษัท Fortune 50 สามารถขยายตัวและประสบความสำเร็จได้ในอีก 10 ปีข้างหน้า

[ahwjdekf]

บริษัทในประเทศที่อ้างเรื่องความปลอดภัยเป็นข้ออ้าง แล้วบังคับให้ใช้สเปกหน่วยความจำ 8GB สำหรับเดสก์ท็อปเสมือนกันถ้วนหน้า น่าขมขื่นนะ

[bus710]

แค่หาคนที่เชี่ยวชาญ Kubernetes ก็ยากอยู่แล้ว เลยรู้สึกว่าการหาคนที่เข้าใจและพยายามนำสิ่งที่เสนอเป็นทางเลือกที่นี่ไปลองใช้ น่าจะยิ่งยากกว่าอีกนะครับ

[xguru]

ความคิดเห็นจาก Hacker News

• นักพัฒนาควรเป็นเจ้าของอุปกรณ์สำหรับพัฒนาที่ตนใช้เอง หากต้องการสภาพแวดล้อมที่สม่ำเสมอ นักพัฒนาควรเป็นเจ้าของอุปกรณ์ของตนเองและได้รับอิมเมจ VM ที่เสถียร ความพยายามในการย้ายสภาพแวดล้อมการพัฒนาไปไว้บนโฮสต์ระยะไกลส่วนใหญ่มักล้มเหลว การจัดหาฮาร์ดแวร์ที่เหมาะสมให้นักพัฒนาคุ้มค่ากว่าทรัพยากรระยะไกล ควรรองรับการรันสแตกแบบโลคัล และสิ่งนี้ช่วยรักษาความสม่ำเสมอผ่านคอนเทนเนอร์ ต้องมีเครื่องมือที่สร้างข้อมูลในสภาพแวดล้อมโลคัลได้ ซึ่งสามารถทำให้เป็นอัตโนมัติได้ แม้การจัดการข้อมูลจะมีข้อเสีย แต่สำหรับบริษัทส่วนใหญ่ ความสามารถในการลงมือทำของทีมสำคัญกว่าซอร์สโค้ด

• การใช้ Kubernetes กับเวิร์กโหลดโปรดักชันเป็นอีกประเด็นหนึ่ง และนี่คือเรื่องของวิธีสร้างสภาพแวดล้อมการพัฒนาในคลาวด์ บทความที่น่าสนใจเกี่ยวกับ trade-off ทางวิศวกรรมที่ซับซ้อนของ Kubernetes

• อธิบายปัญหาของ Kubernetes และแนวทางแก้ที่ได้ลอง แต่ขาดคำอธิบายเกี่ยวกับทางเลือกที่เลือกในท้ายที่สุด มีการพูดถึงโซลูชันใหม่ชื่อ Gitpod Flex แต่มีข้อมูลเกี่ยวกับมันไม่มาก

• Kubernetes เหมาะกับเวิร์กโหลดแบบ stateless แต่ถ้ามี state แล้ว LXC จะเหมาะกว่า LXC สามารถทำคลัสเตอร์ได้คล้าย K8S และเปิดเผยเครื่องมือไปยัง data plane มอบ system instance ที่คล้าย VM และมีประสิทธิภาพใกล้เคียง Docker container ใช้ไวยากรณ์แบบ declarative และสามารถใช้เป็นชั้นพื้นฐานของคลัสเตอร์ Kubernetes ได้

• การเลือก Kubernetes ระหว่างสร้างโซลูชัน CI แสดงว่ายังเข้าใจปัญหาไม่ดีพอ ควรใช้เครื่องมืออย่าง Firecracker เพื่อจุดประสงค์ด้านความปลอดภัย

• Kubernetes ไม่เหมาะกับสภาพแวดล้อมการพัฒนา สภาพแวดล้อมการพัฒนามีสถานะที่เปลี่ยนแปลงอยู่ตลอดเวลา ไม่เข้าใจความจำเป็นของสภาพแวดล้อมการพัฒนาแบบคลาวด์ จุดประสงค์ของแอปที่ทำเป็นคอนเทนเนอร์คือการหลีกเลี่ยงการต้องซิงก์สภาพแวดล้อมการพัฒนาระหว่างทีม

• ในงานวิจัยของ Kubernetes มีการกล่าวถึงการผสมกันของเวิร์กโฟลว์ที่มีความหน่วงต่ำและความหน่วงสูงว่าเป็นกรณีใช้งานเดียว การพิจารณา Kubernetes สำหรับปัญหาของ Gitpod จึงยากจะหาเหตุผลมารองรับ

• เคยทำโปรเจกต์คล้าย Gitpod และไม่เข้าใจการใช้ micro VM มาแทน Kubernetes Kubernetes สามารถ orchestration คอนเทนเนอร์ภายนอกได้ และอาจใช้สำหรับรัน micro VM ได้ ปัญหาใหญ่ที่สุดคือปัญหาที่เกี่ยวกับสตอเรจ

• การสร้างสภาพแวดล้อมการพัฒนาบน Kubernetes เป็นการสิ้นเปลือง หากผลิตภัณฑ์เป็นแบบ self-hosted บนอินฟราของลูกค้า การดีบักและการซัพพอร์ตจะยาก การเปิดให้วิศวกรเห็นปัญหาเครือข่าย หน่วยความจำ คอมพิวต์ และสตอเรจโดยตรงมีประสิทธิภาพกว่า Kubernetes เป็นการอัปเกรดสำหรับทีมขนาดใหญ่