Kubernetes เครือข่าย และการค้นหา VMware ของ Cloud Native

Thomas Graf เป็นผู้ร่วมก่อตั้งและ CTO ของ ไอโซวาเลนท์และผู้สร้างเทคโนโลยีเครือข่ายโอเพ่นซอร์ส (และคลาวด์เนทีฟ) ยอดนิยมที่เรียกว่า ซีเลีย. Cilium สร้างขึ้นบนเทคโนโลยี Linux ระดับเคอร์เนลที่เรียกว่า eGMP.

ในบทสัมภาษณ์นี้ Graf กล่าวถึงบทบาทที่ Cilium และ eBPF เล่นในระบบนิเวศเครือข่ายคลาวด์เนทีฟที่กำลังเติบโต รวมถึงแนวโน้มที่กว้างขึ้นเกี่ยวกับการปรับใช้และวิวัฒนาการของ Kubernetes เขาอธิบายว่าใครกำลังใช้และซื้อ Kubernetes ภายในองค์กรขนาดใหญ่ ที่โครงสร้างพื้นฐานของระบบคลาวด์ยังคงต้องปรับปรุง และความปรารถนาในการสร้างมาตรฐานกำลังขับเคลื่อนนวัตกรรมอย่างไร

---

อนาคต: เราควรคิดอย่างไรเกี่ยวกับ eBPF และ Cilium ในบริบทของการคำนวณและเครือข่าย โดยทั่วไปแล้วโดยเฉพาะในบริบทของ ระบบนิเวศพื้นเมืองบนคลาวด์?

โทมัสกราฟ: โดยรวมแล้ว eBPF เป็นเทคโนโลยีและอยู่ในระดับต่ำมาก มันถูกออกแบบมาสำหรับนักพัฒนาเคอร์เนล และพื้นหลังของฉันอยู่ในการพัฒนาเคอร์เนล eBPF คือเคอร์เนล ระบบปฏิบัติการ จาวาสคริปต์สำหรับเบราว์เซอร์ ทำให้ระบบปฏิบัติการสามารถตั้งโปรแกรมได้เช่นเดียวกับ JavaScript ทำให้เบราว์เซอร์สามารถตั้งโปรแกรมได้ ในอดีต เราต้องอัปเกรดเวอร์ชันเบราว์เซอร์เพื่อใช้งานบางเว็บไซต์จริงๆ จากนั้น JavaScript ก็มาถึง ทีมแอปพลิเคชันและนักพัฒนาทั้งหมดสามารถสร้างแอปพลิเคชันขนาดใหญ่ได้ จนถึงจุดที่แอปพลิเคชันประมวลผลคำที่ได้รับความนิยมมากที่สุดถูกแทนที่ด้วยแอปพลิเคชันในเบราว์เซอร์ มันนำไปสู่คลื่นนวัตกรรมขนาดใหญ่ 

eBPF ก็เกิดเช่นเดียวกัน แม้ว่าในระดับระบบปฏิบัติการก็ตาม เพราะในทันใด เราก็สามารถทำสิ่งต่างๆ ได้ในระดับเคอร์เนลหรือระบบปฏิบัติการที่เราเห็นทุกอย่างและควบคุมทุกอย่าง ซึ่งสำคัญมากสำหรับการรักษาความปลอดภัย โดยไม่ต้องเปลี่ยนเคอร์เนล รหัสแหล่งที่มา. โดยพื้นฐานแล้วเราสามารถโหลดโปรแกรมลงในเคอร์เนลเพื่อขยายฟังก์ชันการทำงานและนำความสามารถใหม่ๆ มาด้วย นอกจากนี้ยังได้ปลดล็อกคลื่นนวัตกรรมขนาดใหญ่อีกด้วย Hyperscaler เช่น Facebook, Google และ Netflix ใช้สิ่งนี้ด้วยตนเองโดยตรงกับทีมเคอร์เนลของตนเอง 

สิ่งที่ Cilium นำเสนอในตารางคือการใช้เทคโนโลยี eBPF ระดับต่ำเพื่อจัดหาโครงสร้างพื้นฐานซอฟต์แวร์คลื่นลูกใหม่ โดยเฉพาะอย่างยิ่งสำหรับคลื่นคลาวด์เนทีฟ ลองนึกถึงสิ่งนี้ เช่น ระบบเครือข่ายที่กำหนดโดยซอฟต์แวร์ และสิ่งที่ Nicira ซึ่งต่อมาได้กลายเป็น VMware NSX ทำเพื่ออุตสาหกรรมการจำลองเสมือน เรากำลังดำเนินการเช่นเดียวกันกับระบบคลาวด์เนทีฟ ซึ่งเป็นการผสมผสานระหว่างผู้ให้บริการคลาวด์หรือโครงสร้างพื้นฐานคลาวด์สาธารณะ รวมถึงโครงสร้างพื้นฐานภายในองค์กร และเรากำลังแก้ไขกรณีการใช้งานเครือข่าย การรักษาความปลอดภัย และความสามารถในการสังเกตที่เลเยอร์โครงสร้างพื้นฐาน

และ Cilium Service Mesh ที่เพิ่งเปิดตัวเป็นวิวัฒนาการของความสามารถเหล่านี้หรือไม่?

สิ่งที่เกิดขึ้นเมื่อประมาณหนึ่งปีที่แล้วคือทั้งสองช่องชนกัน สิ่งที่ Cilium ได้ทำมาจนถึงตอนนี้คือมุ่งเน้นไปที่ระบบเครือข่าย เครือข่ายเสมือนจริง และเครือข่ายคลาวด์เนทีฟ — แต่ยังเป็นเครือข่าย แต่แล้วจากบนลงล่างคือทีมแอปพลิเคชันที่ Twitter และ Google ทำ ตาข่ายบริการ สิ่งของต่างๆ — ในแอปพลิเคชันก่อน และจากนั้นโมเดลแบบ sidecar-based, proxy-based model ซึ่งเป็นสิ่งที่โปรเจกต์ชอบ อิสติโอ ส่งมอบ. และตอนนี้ชั้นสองนี้กำลังใกล้เข้ามาเพราะ องค์กรแบบดั้งเดิมกำลังเข้าสู่โลกของคลาวด์ และพวกเขามีข้อกำหนดด้านเครือข่ายองค์กร แต่ทีมแอปของพวกเขาก็ต้องการตาข่ายบริการเช่นกัน. 

Gartner เรียกเลเยอร์ใหม่นี้ว่า "การเชื่อมต่อบริการ" - เราจะดูว่าคำนั้นจับได้หรือไม่ - แต่โดยพื้นฐานแล้วเป็นเลเยอร์ที่รวมชิ้นส่วนเครือข่ายขององค์กรและชิ้นส่วนบริการที่มาจากทีมแอปพลิเคชัน และเนื่องจากนั่นคือสิ่งที่ลูกค้าต้องการ เราจึงได้เพิ่มความสามารถลงใน Cilium เอง โดยพื้นฐานแล้ว Cilium กำลังก้าวขึ้นจากด้านเครือข่ายองค์กรและเครือข่ายบริการจะลดลงไปสู่ด้านเครือข่ายมากขึ้น

เหตุใดจึงให้ความสำคัญกับระดับเครือข่ายและการบริการของสแต็ก Kubernetes อย่างมาก

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

และโดยเฉพาะในคลาวด์เนทีฟ มัลติคลาวด์กลายเป็นสิ่งสำคัญอย่างยิ่ง. ผู้ให้บริการคลาวด์ทุกรายมีเลเยอร์เครือข่ายของตัวเอง แต่แน่นอนว่าถูกปรับให้เข้ากับคลาวด์ของพวกเขาเอง พวกเขามีข้อเสนอในองค์กร แต่ไม่ใช่มัลติคลาวด์อย่างแท้จริง Cilium และ eBPF นำเสนอเลเยอร์แบบหลายคลาวด์ที่ไม่เชื่อเรื่องพระเจ้า มันทำงานเหมือนกันทุกประการในองค์กรเช่นเดียวกับในคลาวด์สาธารณะ ผู้ให้บริการคลาวด์สาธารณะหลายรายกำลังใช้ Cilium ภายใต้ประทุนสำหรับข้อเสนอ Kubernetes ที่มีการจัดการ และผู้ให้บริการโทรคมนาคมกำลังใช้ Cilium สำหรับโครงสร้างพื้นฐาน 5G ภายในองค์กร มันเป็นเรื่องของการพูดทั้งสองภาษาและเชื่อมโยงโลกเหล่านี้เข้าด้วยกัน

นั่นเป็นเหตุผลที่เน้นเรื่องนี้มาก: เพราะหนึ่งในวิธีที่ง่ายที่สุดสำหรับผู้ให้บริการระบบคลาวด์ในการล็อคลูกค้าคือการเป็นเจ้าของเลเยอร์การเชื่อมต่อนั้น ฉันคิดว่าจากมุมมองของโครงสร้างพื้นฐานเชิงกลยุทธ์ เช่นเดียวกับเลเยอร์การจำลองเสมือนเป็นกุญแจสำคัญ ตอนนี้การเชื่อมต่อและเลเยอร์เครือข่ายเป็นกุญแจสำคัญอย่างยิ่ง

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

Kubernetes ได้รับการยอมรับอย่างกว้างขวางและนำมาใช้ ณ จุดนี้ แต่ก็ยังมีการพูดคุยกันในบางวงการว่าเกินความสามารถ คุณคิดว่า Kubernetes และระบบนิเวศของระบบคลาวด์โดยรวมมีไว้เพื่อใคร

สำหรับทีมแอปพลิเคชันที่ทันสมัย ฉันคิดว่าการตระหนักรู้ได้เริ่มต้นขึ้นแล้วว่า หากคุณต้องการดึงดูดทีมแอปพลิเคชันสมัยใหม่ และสามารถเข้าสู่ตลาดได้อย่างรวดเร็ว คุณจะต้องจัดหาโครงสร้างพื้นฐานแบบคลาวด์เนทีฟให้พวกเขา เรามักจะเห็นการสร้างต้นแบบ — เบื้องต้น, ก่อน MVP, แม้แต่การพิสูจน์แนวคิดหรือการขายภายใน — บนเซิร์ฟเวอร์แบบไร้เซิร์ฟเวอร์ อย่างเช่น Lambda จากนั้นใน Kubernetes เนื่องจากทีมแอปสามารถเป็นเจ้าของโครงสร้างพื้นฐานได้โดยตรง จากนั้น เมื่อมันเคลื่อนไปสู่การผลิต พวกเขาไปที่องค์กร การกระจาย Kubernetes ภายในองค์กร แต่นั่นเป็นส่วนที่ค่อนข้างเล็กของโครงสร้างพื้นฐานทั้งหมด อาจเป็นเปอร์เซ็นต์สองหลักเดียวหรือสองหลักต่ำ 

มันจะเป็นมาตรฐานใหม่อย่างชัดเจน เช่นเดียวกับการนำ virtualization มาใช้ช้ามากในตอนแรกและผู้คนบอกว่ามันเกินความจำเป็น แต่เมื่อเวลาผ่านไป มันเริ่มเข้ามาแทนที่ส่วนใหญ่ของสิ่งต่าง ๆ เราจะเห็นเช่นเดียวกันที่นี่ หรือเหมือนกับภาษาสมัยใหม่ ผู้คนกล่าวว่า Java นั้นใช้ยากเกินไป และมันอาจจะยังคงมีไว้สำหรับแอปพลิเคชันจำนวนมาก แต่ก็มีบางครั้งที่การพัฒนาแอปพลิเคชันภายนอก Java กลายเป็นเรื่องยากมาก เพราะนั่นคือสิ่งที่นักพัฒนาแอปพลิเคชันส่วนใหญ่สามารถเขียนได้ เช่นเดียวกัน เป็นจริงสำหรับทีมแอปพลิเคชันสมัยใหม่: พวกเขาคาดหวังว่าจะมี Kubernetes อยู่รอบตัวเพื่อพัฒนาความคล่องตัวมากขึ้นและนำผลิตภัณฑ์ออกสู่ตลาดอย่างรวดเร็ว

ในด้านโครงสร้างพื้นฐาน มันอาจจะใช้ทักษะมากเกินไป แต่ถ้าทางเลือกอื่นคือการเขียนแอปพลิเคชันใหม่จากเซิร์ฟเวอร์แบบไร้เซิร์ฟเวอร์ไปยังภายในองค์กร นั่นเป็นงานใหญ่ ดังนั้น Kubernetes จึงเป็นพื้นกลางที่นั่น ซึ่งน่าสนใจมาก 

แล้วแนวคิดที่ว่า Kubernetes ยังคงต้องการประสบการณ์สำหรับนักพัฒนาที่ดีกว่านี้ล่ะ

หากเราดู OpenShift ดั้งเดิมก่อนที่จะใช้ Kubernetes ใหม่ มันคือสิ่งนี้ มันใกล้ชิดกับทีมแอปพลิเคชันมากยิ่งขึ้นและเป็นประสบการณ์นักพัฒนาแอปพลิเคชันที่ดียิ่งขึ้น คุณสามารถกดไปที่ Git และมันจะปรับใช้โดยอัตโนมัติ Heroku ก็ลองสิ่งนี้เช่นกัน แต่ใช้ SaaS 

Kubernetes ถอยหลังหนึ่งก้าวและกล่าวว่า "เราจำเป็นต้องรักษาแง่มุมการดำเนินงานบางอย่างไว้ และทำให้ใกล้ชิดกับสิ่งที่ผู้ดูแลระบบคาดหวังมากขึ้นเช่นกัน เราไม่สามารถปรับให้เหมาะกับแอปพลิเคชันเท่านั้น” เป็นเรื่องกลาง: จำเป็นต้องมีความน่าดึงดูดใจเพียงพอสำหรับทีมแอปพลิเคชัน แต่ก็ยังต้องสามารถเรียกใช้แอปนั้นนอกสภาพแวดล้อมเฉพาะ และเพื่อให้คนอื่นจัดการแอปที่ไม่ใช่นักพัฒนาแอปพลิเคชัน

ฉันจะบอกว่าขั้นตอนที่ใหญ่ที่สุดระหว่าง Docker และ Kubernetes คือ Docker นั้นเกี่ยวกับประสบการณ์ของนักพัฒนา มันแก้ไขส่วนนั้น แต่ไม่ได้แก้ไขส่วนระบบนิเวศคลาวด์สาธารณะ

เรามาถึงจุดนี้ได้อย่างไร? นี่เป็นวิวัฒนาการตามธรรมชาติจาก platform-as-a-service (PaaS) และคอนเทนเนอร์แอปพลิเคชันหรือไม่

มันเป็นภาพนักเทียบท่าและด้านบรรจุภัณฑ์ของนักเทียบท่า โรงเรียนเก่าคือวิธีการปรับใช้ในเครื่องเสมือนและมีระบบอัตโนมัติทุกประเภท และจากนั้นก็มีสิ่งที่ Facebook ทำกับทัปเปอร์แวร์ — สร้างขึ้นโดยเฉพาะและมีขนาดใหญ่มาก จากนั้น Docker ก็เข้ามาและจัดเตรียมอิมเมจคอนเทนเนอร์นี้โดยพื้นฐานแล้วทุกคนสามารถปฏิบัติต่อมันเหมือน VM ขนาดเล็ก ตอนนี้ฉันสามารถเผยแพร่แอปของฉันและแทนที่จะเป็นอิมเมจเสมือน 600MB ตอนนี้เป็นคอนเทนเนอร์ 10MB แต่คุณสามารถรักษามันได้เหมือนกัน มันมีทุกอย่างที่ต้องการ 

ซึ่งปลดล็อกความสามารถในการนำ orchestrator เช่น Kubernetes เข้ามา ที่ยังคงให้คุณจัดการแอปพลิเคชัน เช่น mini VM ได้ แต่จากนั้นก็ก้าวไปอีกขั้นหนึ่งและถือว่าเป็นไมโครเซอร์วิสจริงๆ ช่วยให้คุณทำทั้งสองอย่าง

ฉันจะบอกว่าขั้นตอนที่ใหญ่ที่สุดระหว่าง Docker และ Kubernetes คือ Docker นั้นเกี่ยวกับประสบการณ์ของนักพัฒนา มันแก้ไขส่วนนั้น แต่ไม่ได้แก้ไขส่วนระบบนิเวศคลาวด์สาธารณะ มันไม่ได้มีการบูรณาการอย่างใกล้ชิดกับผู้ให้บริการคลาวด์ Kubernetes แก้ปัญหานั้น 

คุณเห็นใครใช้งาน Kubernetes ภายในบริษัทบ้าง? เป็นทีมแอปพลิเคชันส่วนบุคคลหรือไม่?

มีการเปลี่ยนแปลงที่น่าสนใจที่เกิดขึ้นกับคลาวด์เนทีฟ นั่นคือเรามี “ทีมแพลตฟอร์ม” ขึ้นมา ฉันจะเรียกมันว่า พวกเขาไม่ใช่วิศวกรแอปพลิเคชัน พวกเขามีความรู้ด้านเครือข่ายเล็กน้อยและมีความรู้ด้านความปลอดภัยค่อนข้างน้อย พวกเขามีความรู้ด้าน SRE และรู้วิธีทำระบบอัตโนมัติบนระบบคลาวด์ พวกเขากำลังจัดหาแพลตฟอร์มสำหรับทีมแอปพลิเคชันและปฏิบัติต่อทีมแอปพลิเคชันเหล่านั้นในฐานะลูกค้าของพวกเขา

ทีมแพลตฟอร์มคือทีมที่ซื้อ Kubernetes และเทคโนโลยีที่เกี่ยวข้อง ซึ่งพวกเขาใช้เพราะพวกเขาได้รับมอบหมายให้จัดหาโครงสร้างพื้นฐานรุ่นต่อไปเพื่อให้ทีมแอปสมัยใหม่มีความสุข

ฉันคิดว่ามีพื้นที่ว่างสำหรับเซิร์ฟเวอร์โดยเฉพาะอย่างยิ่งสำหรับการพัฒนาแอปพลิเคชันที่รวดเร็วมาก แต่ในองค์กรต่างๆ เราเห็นคลาวด์เนทีฟเป็นเลเยอร์ใหม่ที่ด้านบนของเวอร์ชวลไลเซชัน

นั่นคือผู้ซื้อรายใหม่หรือทีมใหม่ หรือทีมแพลตฟอร์มเป็นเหมือนสิ่งที่มีอยู่ในสถานที่เช่น Google หรือ Facebook และตอนนี้กำลังเข้าสู่กระแสหลัก?

ส่วนใหญ่เป็นทีมใหม่ ฉันคิดว่าพวกเขาเป็นเหมือนทีม SRE ของ Google และ Facebook ในระดับหนึ่ง อย่างไรก็ตาม ทีมแอปพลิเคชันอาจเป็นเจ้าของการปรับใช้แอปในองค์กรมากกว่า เนื่องจากองค์กรไม่มีความแตกต่างที่ชัดเจนมากระหว่างวิศวกรซอฟต์แวร์และ SRE เช่น Google และ Facebook ฉันจะบอกว่าวิวัฒนาการนี้คล้ายกับที่คุณมีทีมเวอร์ช่วลไลเซชั่นมาก และจากนั้น ops เครือข่ายจำนวนมากถูกย้ายจาก — หรือพัฒนาหรือขั้นสูงจาก — เป็นเกี่ยวกับเครือข่าย ฮาร์ดแวร์ เป็นเรื่องเกี่ยวกับเครือข่าย virtualization. และทีมเหล่านี้ เช่น เริ่มใช้งาน VMware NSX สิ่งเดียวกันกำลังเกิดขึ้นที่นี่ 

แม้ว่าจะไม่จำเป็นต้องเป็นงบประมาณใหม่ก็ตาม เราเห็นงบประมาณที่เปลี่ยนจากการรักษาความปลอดภัยและเครือข่ายไปยังทีมแพลตฟอร์มนี้ เช่น การใช้จ่ายบนคลาวด์เพิ่มขึ้นและใช้ฮาร์ดแวร์เครือข่ายน้อยลง พวกเขามักจะทำงานกับทีมรักษาความปลอดภัยและทีมปฏิบัติการเครือข่ายเพื่อขอซื้อ แต่จริงๆ แล้วพวกเขามีงบประมาณค่อนข้างมาก

คุณเห็นเป็นอย่างไร มูลนิธิ Cloud Native Computing การพัฒนาและ Kubernetes จะเป็นศูนย์กลางของมันเสมอ - หรือการเคลื่อนไหวของคลาวด์เนทีฟโดยรวม?

Kubernetes คือสิ่งที่จุดประกายให้ CNCF และในช่วงสองสามปีแรก มันเป็นเรื่องของ Kubernetes และระบบคลาวด์สาธารณะ สิ่งที่เราเห็นเมื่อประมาณหนึ่งปีที่แล้วคือตอนนี้ไม่ใช่แค่ Kubernetes อีกต่อไป แต่จริงๆ แล้วเกี่ยวกับ Cloud Native มากกว่า หลักการ. นี่หมายความว่าไม่จำเป็นต้องเป็นคลาวด์อีกต่อไป แม้แต่คลาวด์ส่วนตัว มักจะเป็นเครือข่ายองค์กรแบบดั้งเดิม โครงสร้างพื้นฐานภายในองค์กรที่น่าเบื่อ เซิร์ฟเวอร์ Bare-Metal และทั้งหมดนั้น แต่ด้วยหลักการดั้งเดิมของระบบคลาวด์ในตัว 

บรรทัดฐานใหม่ในขณะนี้เป็นแบบไฮบริดและรวมถึงผู้ให้บริการคลาวด์สาธารณะหลายราย เช่นเดียวกับโครงสร้างพื้นฐานในองค์กร บริษัทต่างๆ ต้องการให้นักพัฒนาแอปพลิเคชันมีความคล่องตัวเหมือนกัน หรือจัดให้มีเครื่องมือ Cloud Native ที่ทันสมัยในการสังเกตการณ์ หรือรักษาความปลอดภัยด้วยเครื่องมือ Cloud Native ที่ทันสมัย ​​เช่น การพิสูจน์ตัวตน แทนที่จะเป็นเพียงแค่การแบ่งส่วนหรือการบังคับใช้ตามข้อมูลประจำตัว — แนวคิด Cloud Native ใหม่ทั้งหมดเหล่านี้ โครงสร้างพื้นฐานที่มีอยู่ 

เราเห็นความต้องการที่แข็งแกร่งมากในการเชื่อมต่อกับโลกเก่าและพูดคุย MPLS, VLAN, sFlow และ NetFlow ซึ่งเป็นข้อกำหนดขององค์กรที่มีอยู่ทั้งหมด ไม่มีพวกเขาหายไป

ประมาณหนึ่งทศวรรษที่ผ่านมา พื้นที่บนระบบคลาวด์ดูเหมือนจะไม่เป็นที่นิยม จะมีที่ว่างให้พัฒนาต่อไปอีกแค่ไหน?

มีช่วงเวลาหนึ่งที่ดูเหมือนว่า "โอ้ Kubernetes น่าจะอายุสั้น และไม่มีเซิร์ฟเวอร์จะเป็นเลเยอร์ถัดไป" หรือ “Kubernetes คล้ายกับ OpenStack หรือ “มันจะหายไปและมันจะเป็นรายละเอียดการใช้งาน” และนั่นไม่ได้เกิดขึ้น 

ฉันคิดว่ามีพื้นที่ว่างสำหรับเซิร์ฟเวอร์โดยเฉพาะอย่างยิ่งสำหรับการพัฒนาแอปพลิเคชันที่รวดเร็วมาก แต่ในองค์กรต่างๆ เราเห็นคลาวด์เนทีฟเป็นเลเยอร์ใหม่ที่ด้านบนของเวอร์ชวลไลเซชั่น และเราเชื่อว่ามันมีอายุการเก็บรักษาที่ใกล้เคียงกับเวอร์ชวลไลเซชั่น ซึ่งหมายความว่าเราอยู่ในช่วงเริ่มต้นของการโยกย้ายระบบคลาวด์

ปัญหาใหญ่อะไรที่ยังต้องแก้ไขในระดับโครงสร้างพื้นฐาน?

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

ดังนั้นนี่คือความท้าทายที่ยิ่งใหญ่ครั้งต่อไป: ใครกันที่จะเป็นเลเยอร์ที่ไม่เชื่อเรื่องพระเจ้าสำหรับมัลติคลาวด์และคลาวด์เนทีฟ อย่างที่ VMware กลายเป็น? ใครจะเป็น VMware สำหรับคลาวด์เนทีฟ?

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

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

ส่วนที่ยากคือทีมแอปสมัยใหม่คุ้นเคยกับการทำให้ชั้นโครงสร้างพื้นฐานมีวิวัฒนาการเร็วพอๆ กับพวกเขา และสิ่งนี้ทำให้เลเยอร์โครงสร้างพื้นฐานสามารถตั้งโปรแกรมได้มากขึ้น ปรับได้มากขึ้น นั่นเป็นเหตุผลที่เราเห็นเลเยอร์เครือข่ายและเลเยอร์ความปลอดภัยที่ด้านบนของเลเยอร์เครือข่ายคลาวด์ แต่ตอนนี้เรามีองค์กรเข้ามาแล้ว และเราเห็นความต้องการที่แข็งแกร่งมากในการเชื่อมต่อกับโลกเก่าและพูดคุย MPLS, VLAN, sFlow และ NetFlow ซึ่งเป็นข้อกำหนดขององค์กรที่มีอยู่ทั้งหมด ไม่มีสิ่งใดหายไป กฎการปฏิบัติตามทั้งหมดยังคงเหมือนเดิม และ แม้แต่บริษัท SaaS สมัยใหม่บางแห่งก็เผชิญกับความท้าทายเหล่านี้เมื่อบริษัทเติบโตขึ้นและให้ความสำคัญกับการปฏิบัติตามข้อกำหนด เป็นต้น 

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

คุณเห็นคลื่นลูกต่อไปของนวัตกรรมคลาวด์เนทีฟมาจากไหน? ยังมาจากบริษัทอย่าง Google หรือเปล่า หรือมีบริษัทรูปแบบใหม่เป็นผู้นำในการคิดค่าใช้จ่ายหรือไม่?

มันน่าสนใจสุด ๆ. ฉันจะบอกว่ามันอาจจะไม่ได้มาจาก Googles และ Facebooks แหล่งที่มาของนวัตกรรมจะเป็นโอเพ่นซอร์ส และลูกค้าและผู้ใช้ที่ขับเคลื่อนความต้องการจะเป็นบริษัทหนึ่งระดับที่ลดลงจากกลุ่มไฮเปอร์สเกลอร์ ซึ่งเป็นบริษัทขนาดใหญ่อยู่แล้วที่ยังคงก่อกวนสูง เช่น Adobe, Shopify หรือ GitHub แต่ยังรวมถึงบริษัทที่เสี่ยงต่อการถูกรบกวนจากเทคโนโลยี เช่น บริการทางการเงิน ผู้ให้บริการประกันภัย และโทรคมนาคม บริษัทเหล่านี้ล้วนมีความสนใจร่วมกันในการสร้างมาตรฐานโครงสร้างพื้นฐานด้วยรูปแบบการพัฒนาและโครงสร้างพื้นฐานที่ทำซ้ำได้

เผยแพร่ 26 กรกฎาคม 2022