Kubernetes, Jaringan, dan Menemukan VMware Cloud Native

Thomas Graf adalah salah satu pendiri dan CTO dari isovalen, dan pencipta teknologi jaringan open source (dan cloud native) populer yang disebut silia. Cilium dibangun di atas teknologi Linux tingkat kernel yang disebut eGMP.

Dalam wawancara ini, Graf membahas peran yang dimainkan Cilium dan eBPF dalam ekosistem jaringan cloud-native yang berkembang, serta beberapa tren yang lebih luas seputar adopsi dan evolusi Kubernetes. Dia menjelaskan siapa yang menggunakan dan membeli Kubernetes dalam perusahaan besar, di mana infrastruktur asli cloud masih perlu ditingkatkan, dan bagaimana keinginan untuk standardisasi mendorong inovasi.

---

MASA DEPAN: Bagaimana seharusnya kita berpikir tentang eBPF dan Cilium dalam konteks komputasi dan jaringan, secara umum, dan kemudian secara khusus dalam konteks ekosistem asli awan?

GRAF THOMAS: Secara keseluruhan, eBPF adalah teknologinya, dan levelnya sangat rendah. Itu dirancang untuk pengembang kernel, dan latar belakang saya dalam pengembangan kernel. eBPF adalah untuk kernel, untuk sistem operasi, apa JavaScript untuk browser. Itu membuat sistem operasi dapat diprogram seperti JavaScript membuat browser dapat diprogram. Di masa lalu, kami harus meningkatkan versi browser kami untuk benar-benar menggunakan situs web tertentu. Dan kemudian JavaScript datang, dan tiba-tiba tim aplikasi dan pengembang dapat membangun aplikasi besar — ​​sampai pada titik di mana aplikasi pengolah kata paling populer digantikan oleh aplikasi dalam browser. Ini menyebabkan gelombang besar inovasi. 

Hal yang sama terjadi pada eBPF, meskipun pada level sistem operasi, karena tiba-tiba kita dapat melakukan sesuatu di kernel atau level sistem operasi di mana kita melihat semuanya dan mengontrol semuanya — yang sangat penting untuk keamanan — tanpa harus mengubah kernel Kode sumber. Kami pada dasarnya dapat memuat program ke dalam kernel untuk memperluas fungsionalitasnya dan membawa kemampuan baru dengannya. Ini juga telah membuka gelombang besar inovasi. Hyperscaler seperti Facebook, Google, dan Netflix menggunakan ini sendiri, secara langsung, dengan tim kernel mereka sendiri. 

Apa yang dibawa Cilium ke meja adalah menggunakan teknologi eBPF tingkat rendah untuk pada dasarnya menyediakan gelombang baru infrastruktur perangkat lunak, terutama untuk gelombang asli cloud. Pikirkan ini seperti jaringan yang ditentukan perangkat lunak dan apa yang dilakukan Nicira, yang menjadi VMware NSX, untuk industri virtualisasi. Kami melakukan hal yang sama untuk cloud native, yang merupakan gabungan dari penyedia cloud atau infrastruktur cloud publik, serta infrastruktur lokal. Dan kami sedang memecahkan kasus penggunaan jaringan, keamanan, dan observabilitas dengan itu di lapisan infrastruktur.

Dan Cilium Service Mesh, yang baru saja dirilis, merupakan evolusi dari kemampuan ini?

Yang terjadi saat ini, sejak sekitar setahun yang lalu, adalah kedua ruang tersebut bertabrakan. Apa yang telah dilakukan Cilium sejauh ini berfokus pada jaringan, jaringan virtual, dan kemudian jaringan asli cloud — tetapi tetap jaringan. Tapi kemudian, dari atas ke bawah, tim aplikasi di Twitter dan Google melakukannya jaring layanan hal-hal — dalam aplikasi terlebih dahulu, dan kemudian model berbasis sespan, model berbasis proxy, yang seperti proyek Istio mengantarkan. Dan sekarang kedua lapisan ini semakin dekat karena perusahaan tradisional memasuki dunia asli cloud, dan mereka memiliki persyaratan jaringan perusahaan, tetapi tim aplikasi mereka juga menginginkan jaringan layanan. 

Gartner menyebut lapisan baru ini sebagai "konektivitas layanan" — kita akan melihat apakah istilah itu sesuai — tetapi pada dasarnya ini adalah lapisan yang mencakup bagian jaringan perusahaan dan bagian mesh layanan yang berasal dari tim aplikasi. Dan karena itulah yang diminta pelanggan, kami telah menambahkan kemampuan ke dalam Cilium itu sendiri. Jadi, pada dasarnya, Cilium naik dari sisi jaringan perusahaan dan jerat layanan turun ke lebih banyak sisi jaringan.

Mengapa ada begitu banyak fokus pada tingkat jaringan dan mesh layanan dari tumpukan Kubernetes?

Karena dengan keinginan untuk berjalan di banyak cloud dan untuk memisahkan aplikasi ke dalam wadah, lapisan konektivitas menjadi pusat. Apa yang dulunya mungkin komunikasi antar-proses dan middleware sekarang menjadi jaringan, sehingga jaringan menjadi sangat penting bagi aplikasi untuk berbicara satu sama lain dan untuk aliran data. 

Dan di cloud native, khususnya, multi-cloud menjadi sangat penting. Semua penyedia cloud memiliki lapisan jaringan mereka sendiri, tetapi, tentu saja, disesuaikan dengan cloud mereka sendiri. Mereka memang memiliki penawaran lokal, tetapi mereka tidak benar-benar multi-cloud. Cilium dan eBPF menghadirkan lapisan agnostik multi-cloud itu. Ini berperilaku sama persis di tempat seperti di cloud publik. Beberapa penyedia cloud publik menggunakan Cilium di bawah kap untuk penawaran Kubernetes terkelola mereka, dan perusahaan telekomunikasi menggunakannya untuk infrastruktur 5G lokal. Ini tentang berbicara kedua bahasa dan menghubungkan dunia ini bersama-sama.

Itulah mengapa ada begitu banyak fokus pada hal ini: karena salah satu cara termudah bagi penyedia cloud untuk mengunci pelanggan adalah dengan memiliki lapisan konektivitas itu. Saya pikir dari perspektif infrastruktur strategis, sama seperti lapisan virtualisasi adalah kuncinya, sekarang lapisan konektivitas dan jaringan adalah kuncinya.

Sumber inovasi [masa depan] akan menjadi open-source, dan pelanggan dan pengguna yang mendorong permintaan akan menjadi perusahaan satu tingkat di bawah hyperscaler — perusahaan yang sudah cukup besar yang masih sangat mengganggu.

Kubernetes cukup diterima dan diadopsi secara luas pada saat ini, tetapi masih ada pembicaraan di beberapa kalangan bahwa itu berlebihan. Menurut Anda, untuk siapa Kubernetes, dan ekosistem asli cloud secara keseluruhan?

Ini untuk tim aplikasi modern. Saya pikir realisasinya telah dimulai bahwa jika Anda ingin menarik tim aplikasi modern, dan dapat memiliki waktu masuk ke pasar yang cepat, Anda perlu menyediakan infrastruktur asli cloud kepada mereka. Kami sering melihat pembuatan prototipe — awal, pra-MVP, bahkan membuktikan konsep atau menjual secara internal — tanpa server, seperti Lambda. Dan kemudian di Kubernetes, karena tim aplikasi dapat memiliki infrastruktur secara langsung. Dan kemudian, saat bergerak ke produksi, mereka pergi ke perusahaan, distribusi Kubernetes lokal. Tapi itu sebenarnya bagian yang relatif kecil dari keseluruhan infrastruktur, mungkin persentase dua digit tunggal atau rendah. 

Ini jelas akan menjadi standar baru. Sama seperti adopsi virtualisasi pada awalnya sangat lambat dan orang-orang mengatakan itu berlebihan — tetapi seiring waktu, tentu saja, itu mulai menggantikan sebagian besar hal — kita akan melihat hal yang sama di sini. Atau seperti halnya dengan bahasa modern. Orang-orang mengatakan Java itu berlebihan, dan mungkin masih untuk banyak aplikasi, tetapi ada saat di mana menjadi sangat sulit untuk melakukan pengembangan aplikasi apa pun di luar Java karena itulah yang dapat ditulis oleh sebagian besar pengembang aplikasi. Hal yang sama akan benar untuk tim aplikasi modern: mereka akan berharap memiliki Kubernetes untuk mengembangkan lebih gesit dan membawa produk ke pasar dengan cepat.

Di sisi infrastruktur, mungkin sedikit berlebihan, tetapi jika alternatifnya adalah menulis ulang aplikasi dari tanpa server menjadi lokal, itu adalah tugas besar. Jadi Kubernetes adalah jalan tengah di sana, yang sangat menarik. 

Bagaimana dengan gagasan bahwa Kubernetes masih membutuhkan pengalaman pengembang yang lebih baik?

Jika kita melihat OpenShift asli, sebelum di-rebase ke Kubernetes, ini dia. Itu bahkan lebih dekat dengan tim aplikasi dan merupakan pengalaman pengembang aplikasi yang lebih baik. Anda dapat mendorong ke Git dan itu akan secara otomatis digunakan. Heroku juga mencoba ini, tetapi berbasis SaaS. 

Kubernetes mundur selangkah dan berkata, “Kita perlu menjaga beberapa aspek operasional di dalamnya dan membuatnya sedikit lebih dekat dengan apa yang diharapkan sysadmin juga. Kami tidak bisa hanya disesuaikan dengan aplikasi.” Ini adalah jalan tengahnya: Ini perlu memiliki daya tarik yang cukup untuk tim aplikasi, tetapi masih harus memungkinkan untuk menjalankan aplikasi itu di luar lingkungan tertentu, dan mengelolanya oleh orang selain pengembang aplikasi.

Saya akan mengatakan langkah terbesar antara Docker dan Kubernetes adalah bahwa Docker adalah tentang pengalaman pengembang. Itu memecahkan bagian itu, tetapi tidak menyelesaikan bagian ekosistem cloud publik.

Bagaimana kita sampai ke titik ini? Apakah ini evolusi alami dari platform-as-a-service (PaaS) dan wadah aplikasi?

Itu adalah gambar Docker dan aspek pengemasan Docker. Sekolah lama adalah cara menyebarkan ke mesin virtual, dan ada segala macam otomatisasi di sekitarnya. Dan kemudian ada apa yang dilakukan Facebook dengan Tupperware — sangat dibuat khusus dan untuk skala yang sangat besar. Dan kemudian Docker datang dan pada dasarnya menyediakan gambar wadah ini dan semua orang dapat memperlakukannya seperti VM mini. Saya sekarang dapat mendistribusikan aplikasi saya dan alih-alih gambar virtual 600MB, sekarang menjadi wadah 10MB. Tetapi Anda dapat memperlakukannya sama, ia memiliki semua yang dibutuhkannya. 

Itu membuka kemampuan untuk menghadirkan orkestra seperti Kubernetes yang masih memungkinkan Anda untuk memperlakukan aplikasi seperti VM mini, tetapi kemudian juga mengambil satu langkah lebih jauh dan benar-benar memperlakukannya sebagai layanan mikro. Ini memungkinkan Anda untuk melakukan keduanya.

Saya akan mengatakan langkah terbesar antara Docker dan Kubernetes adalah bahwa Docker adalah tentang pengalaman pengembang. Itu memecahkan bagian itu, tetapi tidak menyelesaikan bagian ekosistem cloud publik. Itu tidak memiliki, atau tentu menginginkan, integrasi yang erat dengan penyedia cloud. Kubernetes memecahkan itu. 

Siapa yang Anda lihat menjalankan Kubernetes di dalam perusahaan? Apakah itu tim aplikasi individu?

Ada perubahan menarik yang terjadi dengan cloud native, yaitu bahwa kami memiliki "tim platform", saya akan menyebutnya. Mereka bukan insinyur aplikasi. Mereka memiliki sedikit pengetahuan operasi jaringan dan mereka memiliki sedikit pengetahuan keamanan. Mereka memiliki pengetahuan SRE dan mereka tahu bagaimana melakukan otomatisasi cloud. Mereka menyediakan platform untuk tim aplikasi, dan memperlakukan tim aplikasi tersebut sebagai pelanggan mereka.

Tim platform adalah yang membeli Kubernetes dan teknologi terkait, yang mereka gunakan karena mereka bertugas menyediakan infrastruktur generasi berikutnya untuk membuat tim aplikasi modern senang.

Saya pikir pasti ada ruang untuk serverless, khususnya untuk pengembangan aplikasi yang sangat cepat. Namun di perusahaan, kami melihat cloud native sebagai lapisan baru di atas virtualisasi

Apakah itu net-new buyer atau net-new team? Atau apakah tim platform seperti sesuatu yang ada di tempat-tempat seperti Google atau Facebook dan sekarang menjadi arus utama?

Mereka kebanyakan tim baru. Saya pikir mereka, sampai batas tertentu, seperti tim SRE di Google dan Facebook. Namun, tim aplikasi mungkin memiliki lebih banyak penerapan aplikasi di perusahaan, karena perusahaan tidak memiliki perbedaan yang sangat jelas antara insinyur perangkat lunak dan SRE seperti Google dan Facebook. Saya akan mengatakan evolusi ini sangat mirip dengan bagaimana Anda memiliki tim virtualisasi, dan kemudian banyak operasi jaringan bermigrasi dari — atau berevolusi atau maju dari — menjadi tentang jaringan perangkat keras menjadi tentang jaringan virtualisasi. Dan tim-tim ini, misalnya, mulai mengoperasikan VMware NSX. Hal yang sama terjadi di sini. 

Padahal, anggaran itu belum tentu baru. Kami melihat anggaran bergeser dari keamanan dan jaringan ke tim platform ini, misalnya, karena pengeluaran cloud meningkat dan lebih sedikit yang dihabiskan untuk perangkat keras jaringan. Mereka sering beroperasi dengan tim keamanan dan dengan tim operasi jaringan untuk mendapatkan dukungan, tetapi mereka sebenarnya memiliki anggaran yang cukup besar.

Bagaimana Anda melihat Yayasan Komputasi Asli Cloud berkembang, dan apakah Kubernetes akan selalu menjadi pusatnya — atau pergerakan native cloud secara keseluruhan?

Kubernetes adalah yang memicu CNCF, dan dalam beberapa tahun pertama semuanya tentang Kubernetes dan cloud publik. Apa yang telah kami lihat sejak sekitar setahun yang lalu adalah bahwa sekarang bukan lagi hanya tentang Kubernetes, ini sebenarnya lebih tentang cloud native prinsip-prinsip. Ini sebenarnya berarti tidak harus cloud lagi, bahkan bukan cloud pribadi. Seringkali bahkan jaringan perusahaan tradisional, infrastruktur lokal yang membosankan, server bare-metal, dan semua itu, tetapi dengan prinsip-prinsip asli cloud bawaan. 

Norma baru sekarang hibrida dan mencakup beberapa penyedia cloud publik, serta infrastruktur lokal. Perusahaan ingin memberikan kelincahan pengembang aplikasi yang sama, atau menyediakan observabilitas dengan alat asli cloud modern, atau melakukan keamanan dengan alat asli cloud modern — misalnya, autentikasi, bukan hanya segmentasi atau penegakan berbasis identitas — semua konsep asli cloud baru di infrastruktur yang ada. 

Kami melihat permintaan yang sangat kuat untuk tetap terhubung ke dunia lama dan berbicara tentang MPLS, VLAN, sFlow, dan NetFlow — seluruh rangkaian persyaratan perusahaan yang ada. Tak satu pun dari mereka telah pergi.

Sekitar satu dekade ke dalamnya, ruang asli cloud tampaknya tidak menjadi tren. Berapa banyak ruang yang ada untuk terus berkembang?

Pasti ada waktu di mana itu seperti, "Oh, Kubernetes mungkin berumur pendek, dan tanpa server akan menjadi lapisan berikutnya." Atau, “Kubernetes mirip dengan OpenStack. Atau, "Itu akan hilang dan itu akan menjadi detail implementasi." Dan itu tidak terjadi. 

Saya pikir pasti ada ruang untuk serverless, khususnya untuk pengembangan aplikasi yang sangat cepat. Namun di perusahaan, kami melihat cloud native sebagai lapisan baru di atas virtualisasi, dan kami yakin ini memiliki umur simpan yang sama dengan virtualisasi. Artinya, kita berada di awal migrasi native cloud.

Masalah besar apa yang masih perlu diselesaikan di tingkat infrastruktur?

Kami melihat perusahaan dalam situasi di mana, tiba-tiba, apakah mereka menginginkannya atau tidak, mereka membutuhkan strategi multi-cloud. Karena mereka juga memiliki infrastruktur di tempat, mereka sekarang membutuhkan strategi cloud hybrid di atas itu. Dan mereka perlu mencari cara untuk melakukan keamanan dan fungsi lainnya secara universal di seluruh infrastruktur ini tanpa mengunci diri ke cloud publik tertentu. 

Jadi ini adalah tantangan besar berikutnya: Siapa yang akan menjadi lapisan agnostik untuk multi-cloud dan cloud native, seperti apa jadinya VMware? Siapa yang akan menjadi VMware untuk cloud native?

Saya pikir realisasinya telah dimulai bahwa jika Anda ingin menarik tim aplikasi modern, dan dapat memiliki waktu masuk ke pasar yang cepat, Anda perlu menyediakan infrastruktur asli cloud kepada mereka.

Dan meskipun adopsi asli cloud mungkin relatif mudah bagi perusahaan web modern yang merupakan pengadopsi awal, tantangan dari perspektif Anda adalah membangun teknologi baru yang menjembatani kesenjangan antara dunia modern ini dengan alat dan sistem perusahaan yang ada?

Bagian yang sulit adalah bahwa tim aplikasi modern terbiasa dengan lapisan infrastruktur yang berkembang secepat mereka. Dan ini memaksa lapisan infrastruktur menjadi lebih dapat diprogram, lebih dapat disesuaikan. Itu sebabnya kami benar-benar melihat lapisan jaringan dan lapisan keamanan di atas lapisan jaringan awan. Tetapi sekarang kami memiliki perusahaan yang masuk, dan kami melihat permintaan yang sangat kuat untuk tetap terhubung ke dunia lama dan berbicara tentang MPLS, VLAN, sFlow, dan NetFlow — seluruh rangkaian persyaratan perusahaan yang ada. Tak satu pun dari mereka telah pergi, semua aturan kepatuhan masih sama. Dan bahkan beberapa perusahaan SaaS modern sekarang menghadapi tantangan ini saat mereka tumbuh lebih besar dan mereka peduli dengan kepatuhan dan seterusnya. 

Dari perspektif teknologi, ini tentang bagaimana menghubungkan dunia asli cloud yang baru dengan persyaratan perusahaan yang ada. Karena banyak dari masalah ini disembunyikan oleh penyedia cloud publik. Penyedia cloud publik memecahkan masalah kepatuhan, tetapi mereka tidak membuka sumber atau mempublikasikan semua itu; mereka memecahkannya sendiri. Itu bagian dari nilai cloud. Perusahaan sekarang perlu membangun kembali dan membelinya jika mereka tidak ingin mengunci diri dalam penawaran cloud publik.

Dari mana Anda melihat gelombang inovasi asli cloud berikutnya? Apakah masih berasal dari perusahaan seperti Google, atau ada jenis perusahaan baru yang memimpin?

Itu sangat menarik. Saya akan mengatakan itu mungkin tidak datang dari Google dan Facebook. Sumber inovasi akan menjadi open-source, dan pelanggan serta pengguna yang mendorong permintaan akan menjadi perusahaan satu tingkat di bawah hyperscaler — perusahaan yang sudah cukup besar yang masih sangat mengganggu, seperti Adobe, Shopify, atau GitHub. Tetapi juga perusahaan yang berisiko terganggu oleh teknologi, seperti layanan keuangan, penyedia asuransi, dan telekomunikasi. Semua perusahaan ini memiliki kepentingan bersama dalam menstandardisasi infrastruktur dengan model pembangunan dan infrastruktur yang dapat diulang.

Diposting 26 Juli 2022