โครงการที่คุ้นเคยยังคงเปิดตัวในองค์กรเทคโนโลยีที่มีการกำกับดูแลจำนวนมาก ทีมแพลตฟอร์มถูกจัดตั้งขึ้นเพื่อ “เป็นเจ้าของ Kubernetes” อีกหนึ่งสายงานได้รับงบเพื่อ “ทำให้ Istio เป็นอุตสาหกรรม” แผนงานยืดเยื้อข้ามปีงบประมาณ คณะกรรมการได้ยินเรื่อง maturity model, golden path และการเป็นเจ้าของ control plane ขณะที่ทีมผลิตภัณฑ์ยังคงรอ namespaces, certificates และ east-west policy ที่คู่แข่งใช้เป็นผลิตภัณฑ์ไปแล้ว ความจริงที่ไม่สบายใจไม่ใช่ว่า Istio อ่อนแอ แต่เป็นเพราะตลาดได้ทำให้ความสามารถเดียวกันนี้เป็นผลิตภัณฑ์แล้ว และคุณกำลังจ่ายเงินเพื่อสร้างใหม่ซึ่งไม่สร้างความแตกต่างอีกต่อไป
Kubernetes перест เป็นเทคโนโลยีแนวหน้าไปหลายปีแล้ว การสำรวจประจำปี 2025 ของ CNCF ระบุว่า 82% ขององค์กรที่ใช้ container ใช้งาน Kubernetes ใน production Service Mesh ก็เดินตามเส้นทางเดียวกัน จากการบุกเบิก sidecar estate ไปสู่โครงการที่ CNCF จบการศึกษา ไปจนถึง ambient และ eBPF data plane, การแจกจ่ายสำหรับองค์กร และ add-on จาก hyperscaler การมองทั้งสองอย่างเป็น moonshot หลายปีจึงไม่ใช่ความระมัดระวังอีกต่อไป แต่เป็นนิสัยที่แพง
ปัญหา: Plumbing เชิงพาณิชย์ถูกมองเป็น moonshot
Istio ยังคงเป็น mesh ที่มีความสามารถสูง มันจบการศึกษาจาก CNCF ในเดือนกรกฎาคม 2023 Ambient mode เปิดให้ใช้งานทั่วไปพร้อม Istio 1.24 ในเดือนพฤศจิกายน 2024 โดยแทนที่ภาษี Envoy sidecar ต่อ pod ด้วย ztunnel ระดับโหนดสำหรับ Layer 4 และ waypoint proxy สำหรับ Layer 7 เมื่อจำเป็น แต่ทั้งหมดนี้ไม่ได้แก้คำถามระดับองค์กร ความสามารถไม่ได้บังคับให้คุณต้องประดิษฐ์ operating model ใหม่ขึ้นมา บริษัทจำนวนมากยังคงจัดตั้งโครงการแพลตฟอร์มขนาดใหญ่เพื่อสร้างสิ่งที่ Google Cloud Service Mesh (เดิมคือ Anthos Service Mesh), AKS Istio add-on, commercial multi-zone mesh และทางเลือกโอเพ่นซอร์สอื่น ๆ จัดส่งมาพร้อมสัญญาการสนับสนุน เส้นทางการอัปเกรด และการควบคุม blast-radius ที่มีเอกสารครบถ้วน
ต้นทุนที่แท้จริงไม่ใช่ค่าลิขสิทธิ์โอเพ่นซอร์ส เพราะส่วนใหญ่ไม่มีเลย ต้นทุนคือหลายปีของ platform engineering, การหมุนเวียน on-call รอบการอัปเกรด, การเชื่อมต่อ certificate และ identity และงานผลิตภัณฑ์ที่ล่าช้าขณะที่ mesh “成熟” ความเห็นอิสระเกี่ยวกับ internal developer platform แบบสร้างเองพบซ้ำ ๆ ว่าจำนวนคนและ opportunity cost มากกว่าค่า compute มาก การวิเคราะห์ของ The New Stack เกี่ยวกับแพลตฟอร์มสร้างเองระบุว่าแพลตฟอร์มองค์กรเต็มรูปแบบมีต้นทุนหลายสิบล้านดอลลาร์ต่อปีเมื่อนับ payroll อย่างซื่อสัตย์ แม้ตัวเลขคร่าว ๆ จะสำคัญน้อยกว่าลักษณะที่เกิดขึ้น: คุณกำลังใช้วิศวกรที่มีจำกัดไปกับ plumbing ที่อุตสาหกรรมขายอยู่แล้ว
เหตุใด Istio จึงกลายเป็นค่าเริ่มต้น และเหตุใดจึงไม่ใช่คำตอบอีกต่อไป
Istio ได้เปรียบในช่วงแรกด้วยเหตุผลที่ชัดเจน Envoy ในฐานะ data plane, นโยบาย Layer 7 ที่สมบูรณ์ และแรงดึงดูดจาก Google และ IBM ทำให้มันเป็นคำตอบเริ่มต้นในห้องประชุมและการทบทวนสถาปัตยกรรม ในช่วงหนึ่ง การเลือก Istio ดูเหมือนการเลือกตลาดเอง ประวัตินี้ยังคงสำคัญเมื่อคุณจ้างงานและประเมิน managed offering ที่สร้างบน API เดียวกัน แต่ไม่ได้หมายความว่าธนาคารทุกแห่งควรจัดสรรงบประมาณถาวรสำหรับโครงการสร้าง Istio
Ambient mode ลดภาษี sidecar ที่ทำให้ Istio มีชื่อเสียงเรื่องการใช้หน่วยความจำและการอัปเกรดที่ยุ่งยาก เอกสารประสิทธิภาพอย่างเป็นทางการของ Istio และ benchmark จากผู้ขายแสดงให้เห็นถึงการประหยัดทรัพยากรอย่างมีนัยสำคัญเมื่อ L4 ทำงานใน ztunnel และ L7 ถูกเรียกเก็บเฉพาะที่จำเป็นต้องใช้ waypoint นั่นคือการพัฒนาที่แท้จริง แต่ไม่ได้ลดความซับซ้อนของ control plane, งาน federation ข้ามคลัสเตอร์, วินัยในการเขียน policy หรือความต้องการคนที่เข้าใจ failure mode เมื่อ traffic policy ล้มเหลวตอนตีสอง Mesh ในปัจจุบันคือความสามารถที่คุณบริโภค การประดิษฐ์ขึ้นภายในองค์กรเป็นเรื่องเลือกได้ สำหรับองค์กร regulated multi-cloud ส่วนใหญ่ การเลือกสร้างเองไม่ใช่ค่าเริ่มต้นที่ถูกต้อง
ตลาดได้สร้างทางเลือกเหล่านั้นไว้แล้ว
ชั้นวางโอเพ่นซอร์สเต็มไปด้วยตัวเลือกที่มีประโยชน์ Istio (ทั้ง sidecar และ ambient), Linkerd ด้วย Rust micro-proxy, Cilium service mesh ที่ใช้ eBPF, HashiCorp Consul และ Kuma ต่างก็แก้ปัญหาการเชื่อมต่อ, mutual TLS และ traffic policy ด้วยการแลกเปลี่ยนที่แตกต่างกัน Linkerd ยังคงเป็นมาตรฐานความเรียบง่ายสำหรับองค์กรที่ใช้เฉพาะ Kubernetes ซึ่งต้องการ mTLS อัตโนมัติและ golden-signal metrics ด้วยพื้นที่ปฏิบัติการที่แคบ Cilium มักเป็นทางเลือกที่เหมาะสมเมื่อมันเป็น CNI ของคลัสเตอร์อยู่แล้ว และ eBPF สามารถครอบคลุม identity, policy และ observability โดยไม่ต้องมี control plane ที่สอง Consul ยังเหมาะกับองค์กรที่ใช้ HashiCorp stack ลึก ๆ และต้องการ multi-datacentre
ผลิตภัณฑ์สำหรับองค์กรและ multi-zone นั่งอยู่บนพื้นฐานนั้น Kong Mesh สร้างบน Kuma และ Envoy พร้อม multi-zone control, การรองรับ FIPS 140-2 ผ่านโหมด BoringSSL ของ Envoy, Open Policy Agent แบบฝังตัว (MeshOPA) เพื่อให้ Rego ทำงานใน data plane แทนที่จะเป็น sidecar เพิ่มเติม, การควบคุมที่เน้น audit และการเชื่อมโยงกับ Kong Gateway สำหรับผู้ปฏิบัติงานที่ต้องการ north-south และ east-west policy ภายใต้ความสัมพันธ์กับผู้ขายเพียงรายเดียว ชุดความสามารถนี้เหมาะสมกับองค์กร hybrid ที่ผสม Kubernetes กับ VM และต้องการ global control plane ที่ได้รับการสนับสนุนข้ามโซนและคลาวด์
Hyperscaler ยังทำให้การใช้งาน Istio เป็นผลิตภัณฑ์ Google Cloud Service Mesh จัดการ lifecycle ของ control plane บน GKE fleet Microsoft’s Istio-based service mesh add-on สำหรับ AKS ให้ version compatibility ที่ผ่านการทดสอบ, การปรับขนาด control plane แบบ managed และการสนับสนุนอย่างเป็นทางการจาก Azure บน Amazon EKS ลักษณะจะเน้น marketplace มากกว่า: add-on และ distribution จากผู้ขายเฉพาะทางมากกว่าการจัดการ Istio control plane แบบ first-party เดียวกับ Azure “มีให้ใช้อย่างแพร่หลาย” สำหรับองค์กร regulated multi-cloud ในปัจจุบัน หมายความว่าคุณสามารถซื้อ mesh ที่ได้รับการสนับสนุนบนคลาวด์หลักแต่ละแห่ง ใช้โอเพ่นซอร์สพร้อม commercial support หรือใช้งานผลิตภัณฑ์ multi-zone ที่ครอบคลุมทั้ง Kubernetes และ VM โดยไม่ต้องแสร้งว่าทุก workload อยู่ในคลัสเตอร์ greenfield เดียว
วิธีอ่านตัวเลือกโดยไม่ต้องจัด beauty contest
เริ่มจาก data plane Sidecar Envoy ยังคงเป็น L7 workhorse ที่成熟 Ambient mode และเส้นทาง eBPF ของ Cilium ลด overhead ต่อ pod Linkerd’s Rust proxy รักษาโมเดล sidecar แต่ทำให้ binary และขอบเขตฟีเจอร์แคบลง ไม่มีตัวใดเหนือกว่าอย่างสิ้นเชิง แต่ละตัวเปลี่ยนแปลงการใช้หน่วยความจำ, การหยุดชะงักจากการอัปเกรด และปริมาณ L7 policy ที่สามารถแสดงได้โดยไม่ต้องติดตั้งส่วนเสริม
จากนั้นพิจารณาขอบเขต Mesh ที่จำกัดเฉพาะ Kubernetes (Linkerd แบบคลาสสิก, ambient Istio จำนวนมาก, Cilium บนคลัสเตอร์) เหมาะสมเมื่อองค์กรเป็น container บน Kubernetes จริง ๆ ผลิตภัณฑ์ multi-zone เช่น Kong Mesh บน Kuma มีความสำคัญเมื่อคุณยังใช้งาน VM ต้องการ identity ข้ามโซน และไม่ต้องการ mesh ที่แตกต่างกันบนทุกคลาวด์ Hyperscaler-managed Istio ยอดเยี่ยมเมื่อคุณมาตรฐานบนคลาวด์เดียวและต้องการให้ Microsoft หรือ Google เป็นเจ้าของการอัปเกรด control plane แต่เป็นคำตอบที่อ่อนแอกว่าเมื่อกลยุทธ์ระบุ multi-cloud และทีม audit ถามว่ากราฟนโยบายเดียวกันได้รับการพิสูจน์บน Azure, AWS และ Kubernetes ส่วนตัวอย่างไร
การดำเนินงานและ governance เป็นตัวปิดกรอบ ถามว่าการอัปเกรดและ blast radius ต้องการ platform engineer กี่คน ถามว่า mutual TLS, workload identity, policy-as-code และ audit trail มาพร้อมเป็นฟีเจอร์ของผลิตภัณฑ์หรือเป็นโครงการภายในสองปี Commercial support ไม่ใช่ความล้มเหลวทางศีลธรรม สำหรับผู้ประกอบการที่มีการกำกับดูแล มันคือวิธีแปลงความสามารถโอเพ่นซอร์สให้เป็นสิ่งที่คุณสามารถป้องกันต่อหน้าผู้ตรวจสอบบัญชีเมื่อการควบคุมล้มเหลว
สิ่งที่เหมาะสมกับธนาคารและบริษัทประกันภัย
Hybrid และ multi-cloud คือสภาพปกติ ไม่ใช่สถานะในอนาคต Workload อยู่บนมากกว่าหนึ่ง hyperscaler รวมถึง Kubernetes ส่วนตัวและ VM ที่ดื้อรั้นซึ่งจะไม่หายไปเพราะสไลด์แพลตฟอร์มบอกว่า “cloud native” Zero-trust east-west traffic, cryptographic workload identity และหลักฐานสำหรับผู้ตรวจสอบคือสิ่งพื้นฐาน ความบริสุทธิ์ของ single-cluster greenfield คือภาพลวงตาที่เผาผลาญงบประมาณ
รูปแบบนี้สนับสนุน control plane ที่ได้รับการสนับสนุนและครอบคลุมโซนมากกว่า mesh เดียวคลาวด์ที่คุณต้องอธิบายใหม่บนทุกแพลตฟอร์มอื่น Kong Mesh และผลิตภัณฑ์ multi-zone ที่คล้ายกันสอดคล้องกับความเป็นจริงนี้: policy และ identity ที่เดินทางข้าม Kubernetes และ VM, ตัวเลือก crypto ที่เน้น FIPS, OPA แบบฝังตัวสำหรับหลักฐานการอนุญาต และเส้นทางการสนับสนุนเชิงพาณิชย์ พวกมันไม่ได้เป็นเวทมนตร์ แต่เป็น plumbing ที่ซื้อครั้งเดียวแทนการสร้างใหม่ทุกคลาวด์
ทางเลือกเฉพาะพื้นที่ยังคงชนะในกรณีที่มีขอบเขตจำกัด Linkerd มักดีกว่าเมื่อปัญหาคือองค์กร Kubernetes ล้วน ทีมต้องการภาระ day-two ที่น้อยที่สุด และมีงบประมาณสำหรับ Buoyant Enterprise support (stable release artefacts สำหรับองค์กรขนาดใหญ่ถูกย้ายไปอยู่หลัง subscription model ตั้งแต่ต้นปี 2024) Cilium ยังคงเป็นทางเลือกท้องถิ่นที่ดีกว่าเมื่อมันเป็น CNI อยู่แล้วและ eBPF ครอบคลุมความลึกของ mTLS และ policy โดยไม่นำเสนอ surface ทั้งหมดของ Istio Hyperscaler-managed Istio add-on ยังคงเป็นทางเลือกท้องถิ่นที่ดีกว่าถ้าคุณใช้งาน GKE หรือ AKS ลึก ๆ ยินดีให้ผู้ให้บริการเป็นเจ้าของ control plane และไม่ได้พยายามรัน mesh control story เดียวกันโดยไม่เปลี่ยนแปลงข้ามสามคลาวด์ การเลือกอย่างยุติธรรมดีกว่าความภักดีต่อแบรนด์
บิลที่ซ่อนอยู่จากการสร้าง Kubernetes และ Istio จากศูนย์
Platform headcount คือรายการที่มองเห็นได้ On-call rotation, upgrade theatre, การดำเนินงาน certificate authority, ความล้มเหลวในการ rollout sidecar หรือ ambient และ backlog ถาวรของตั๋ว “ทำให้ mesh ปลอดภัยยิ่งขึ้น” คือรายการที่เงียบกว่า บทความอุตสาหกรรมเกี่ยวกับ total cost of ownership ของ Istio พบซ้ำ ๆ ว่าต้นทุนการดำเนินงานสูงกว่าค่า compute ของ sidecar สำหรับองค์กรขนาดกลาง ส่วนที่แพงคือคนที่เข้าใจระบบเมื่อมันทำงานผิดปกติ DIY Kubernetes platform ขยายการคำนวณเดียวกันนี้ไปยัง networking, ingress, observability และ security tooling
Opportunity cost ยิ่งแย่ลง วิศวกรทุกคนที่แก้ไขปัญหา injection failure หรือร่าง Istio operator ภายในอีกตัวหนึ่งไม่ได้ส่งมอบ risk model, customer journey, claims automation หรืองาน resilience ที่ส่งผลต่อ P&L การวิจารณ์แพลตฟอร์ม DIY ของ The New Stack ระบุช่องว่างความเร็วอย่างตรงไปตรงมา: ผู้ขายยังคงส่งมอบต่อเนื่อง ขณะที่โครงการสร้างของคุณไล่ตามเป้าหมายที่เคลื่อนไหว มักล้าหลัง roadmap เชิงพาณิชย์หนึ่งปีหรือมากกว่า Lock-in ที่เจ็บปวดที่สุดไม่ใช่โลโก้ผู้ขาย แต่เป็นการถูกล็อกกับแพลตฟอร์มที่ยังไม่เสร็จของคุณ: config, runbook และความรู้เฉพาะกลุ่มที่ใช้ได้เฉพาะใน stack ที่ไม่มีใครสนับสนุนเมื่อทีมเดิมลาออก
ปล่อยนักพัฒนาให้เป็นอิสระ
ซื้อ Kubernetes เชิงพาณิชย์เมื่อ managed หรือ supported distribution ดีพอ ซื้อ mesh ที่ได้รับการสนับสนุนซึ่งตรงกับรูปแบบองค์กร: ผลิตภัณฑ์ multi-zone เช่น Kong Mesh เมื่อ hybrid และ multi-cloud policy ต้องถูกนำไปใช้เพียงครั้งเดียว Linkerd, Cilium หรือ hyperscaler-managed Istio เมื่อขอบเขตท้องถิ่นชัดเจนและแคบกว่า นำเวลาวิศวกรรมไปใช้กับการออกแบบ policy, data classification, customer journey และความยืดหยุ่นของธุรกิจ ไม่ใช่การประดิษฐ์การจัดการ configuration ของ Envoy ใหม่
CTO หรือ CIO สามารถตัดสินใจชุดสั้น ๆ ได้ในไตรมาสนี้ ประการแรก ประกาศในกลยุทธ์เทคโนโลยีว่า Kubernetes และ service mesh คือ plumbing เชิงพาณิชย์ พร้อมห้ามโครงการสร้างใหม่หลายปีใหม่โดยไม่มีข้อยกเว้นเป็นลายลักษณ์อักษร ประการที่สอง สำรวจว่าต้องการ mesh สำหรับ zero-trust east-west ที่ไหน และที่ไหนเป็นเพียง cargo cult ประการที่สาม เลือกค่าเริ่มต้น: multi-zone supported mesh สำหรับโดเมนข้ามคลาวด์และผสม VM managed Istio, Linkerd หรือ Cilium สำหรับเกาะ Kubernetes ที่มีขอบเขตจำกัด ประการที่สี่ จัดสรรงบสำหรับ policy-as-code, identity และ audit evidence ในฐานะผลิตภัณฑ์แพลตฟอร์ม ไม่ใช่ “Istio YAML เพิ่มเติม” ประการที่ห้า วัดความสำเร็จของแพลตฟอร์มด้วยเวลาในการนำ workload ที่มี governance ไปใช้และการกู้คืน policy ข้ามคลาวด์ ไม่ใช่ด้วยจำนวนบรรทัดโค้ด control-plane ภายใน
หยุดสร้าง mesh ใหม่ อุตสาหกรรมขายท่อเหล่านี้อยู่แล้ว ธนาคารและบริษัทประกันภัยที่ซื้อท่อเหล่านี้จะใช้เวลาหลายปีข้างหน้าบนปัญหาที่สร้างความแตกต่างได้จริง ส่วนผู้ที่ยังคงมอง Istio และ Kubernetes เป็น moonshot จะยังคงจัดคนไปทำ plumbing และเรียกมันว่ากลยุทธ์