Ke Istio dan seterusnya: Antarmuka Layanan Mesh Azure

Pengembangan aplikasi modern yang mengutamakan cloud, setidaknya di Azure, telah menjadi hampir bergantung pada Kubernetes. Teknologi seperti Kubelet Virtual, AKS (Azure Kubernetes Service), dan Azure Service Fabric Mesh adalah kunci untuk membangun aplikasi terdistribusi yang dapat diskalakan di Azure, menggunakan container untuk menerapkan dan mengelola layanan mikro.

Melihat alat Kubernetes Azure, jelas bahwa Microsoft melakukan banyak pekerjaan di dalam dan sekitar Cloud Native Computing Foundation, mengerjakan semua aspek kerangka kerja sumber terbuka. Kita tidak perlu heran; Microsoft mempekerjakan salah satu pendiri proyek Kubernetes dan kemudian mengakuisisi Deis, vendor penting. Tim Deis mendukung salah satu kontribusi Azure terbaru untuk ekosistem Kubernetes, Service Mesh Interface (SMI).

Memperkenalkan jerat layanan

Mungkin yang terbaik adalah terlebih dahulu menjelaskan apa itu service mesh dan mengapa itu penting untuk aplikasi berbasis Kubernetes.

Arsitektur IT modern adalah tentang abstraksi. Dengan layanan cloud, kami tidak perlu lagi memikirkan perangkat keras yang mendasarinya. Jika kami menggunakan IaaS, kami mendefinisikan mesin virtual sebagai host kode kami. Dengan PaaS, kami lebih jauh dari perangkat keras, menggunakan layanan dan API yang kami pilih, memilih tingkat kinerja yang sesuai untuk aplikasi dan anggaran kami. Dengan arsitektur berbasis kontainer seperti Kubernetes, kita berada pada titik di antara keduanya: menggunakan layanan seperti AKS kita dapat mendefinisikan mesin virtual yang mendasarinya, yang kemudian menghosting pod kontainer kita dan menskalakannya dengan perubahan dalam komputasi dan memori (dan sekarang dengan KEDA (penskalaan otomatis berbasis peristiwa Kubernetes), setelah menerima peristiwa).

Itu hanya salah satu aspek abstraksi. Layanan mikro Kubernetes, pada dasarnya, tidak memiliki kewarganegaraan; mereka menggunakan penyimpanan eksternal dan berada di atas jaringan fisik atau virtual. Aspek jaringan dalam menjalankan Kubernetes mungkin yang paling rumit: Saat layanan bertambah dan berkurang, Anda perlu memodifikasi jaringan Anda untuk menyesuaikan perubahan pada aplikasi Anda. Tetapi bagaimana Anda menjaga layanan tetap terhubung ketika aplikasi front end dan back end mungkin diskalakan pada tingkat yang berbeda?

Di situlah mesh layanan masuk. Mereka adalah lapisan abstraksi baru, lapisan yang mengangkat kode Anda dari jaringan yang mendasarinya dengan memanfaatkan kemampuan jaringan yang ditentukan perangkat lunak modern. Dengan bertindak sebagai sekumpulan proxy jaringan yang diterapkan dengan kode Anda, mesh layanan mengelola komunikasi layanan-ke-layanan tanpa kode Anda memerlukan kesadaran apa pun dari jaringan yang mendasarinya. Anda dapat menganggap service mesh sebagai bidang kontrol otomatis untuk jaringan aplikasi Anda, mengelola bidang kontrol yang mendasarinya saat Kubernetes menskalakan kode Anda ke atas dan ke bawah.

Jaringan yang ditentukan perangkat lunak untuk layanan mikro

Mungkin paling baik dianggap sebagai cara untuk mengimplementasikan load-balancing yang cerdas, sadar-latensi, dan dapat diskalakan bersamaan dengan penemuan layanan, mesh layanan pada dasarnya adalah router terdistribusi dengan aturan perutean dinamis yang dikelola sebagai bagian dari penerapan Kubernetes. Anda dapat menentukan aturan tambahan; misalnya, menjaga produksi dan sistem pengujian terpisah, atau menangani penerapan rilis baru dan perubahan antara versi penampung. Setiap pod dalam aplikasi memiliki instance mesh layanan yang berjalan sebagai bantuan, dengan penemuan layanan dan elemen berstatus lain yang berjalan di luar layanan Anda.

Dengan mesh layanan, Anda mendorong kecerdasan ke lapisan jaringan baru, jadi Anda tidak perlu memasukkannya ke layanan mikro. Perlu mengenkripsi koneksi? Itu pekerjaan untuk mesh layanan Anda. Perlu memberi otorisasi kepada klien? Tugas lain untuk mesh layanan.

Terlalu banyak jerat

Menggabungkan penerapan Kubernetes dengan mesh layanan sangat masuk akal. Namun ada satu masalah besar lagi: Yang mana yang Anda gunakan? Utusan? Istio? Linkerd? Aspen Mesh? Jika Anda memilih satu, apa yang menghentikan tim pengembangan di bagian lain dari bisnis Anda untuk memilih yang lain? Lalu apa yang terjadi jika perusahaan Anda memutuskan untuk melakukan standarisasi pada platform tertentu?

Itulah masalah yang ingin diselesaikan oleh Microsoft dengan Antarmuka Layanan Mesh. Alih-alih setiap mesh layanan memiliki kumpulan API-nya sendiri, SMI adalah cara untuk mengimplementasikan API umum yang bekerja di berbagai mesh layanan, mengelola jaringan pintar baru tersebut. Daripada mengunci kode Anda ke dalam mesh layanan tertentu dan API-nya, Anda dapat menulis kode yang menangani sebagian besar kasus penggunaan umum melalui API umum. Jika Anda perlu menukar mesh layanan — jika Anda mengubah penyedia atau menemukan penyedia yang bekerja lebih baik — tidak perlu mengubah kode Anda, selama mesh layanan mengimplementasikan SMI. Yang perlu Anda lakukan adalah mengubah sidecars mesh layanan Anda dan menerapkan ulang kode Anda.

SMI: API mesh layanan umum

Bekerja dengan perusahaan ekosistem Kubernetes seperti Hashicorp dan Buoyant, Microsoft telah menetapkan fitur utama untuk SMI yang mendukung permintaan umum dari pelanggannya. Dalam rilis awal ini difokuskan pada tiga bidang: kebijakan lalu lintas, telemetri lalu lintas, dan manajemen lalu lintas. Ketiga area ini dikontrol oleh sebagian besar jerat layanan, dan tujuannya adalah untuk menjadikannya spesifikasi yang mudah diterapkan tanpa mengubah aplikasi yang mendasarinya.

Dengan menjadikan SMI satu set API standar, tidak ada yang bisa menghentikan vendor mesh layanan untuk terus menawarkan API mereka sendiri atau fitur tambahan di luar yang ditentukan. Alternatifnya, mereka tidak perlu melakukan perubahan apa pun; pihak ketiga dapat membuat lapisan terjemahan yang berada di antara API SMI dan API layanan kepemilikan. Anda juga tidak memerlukan versi baru Kubernetes, karena SMI API diimplementasikan sebagai server API ekstensi dan definisi sumber daya khusus. Anda dapat melanjutkan dan menginstalnya di cluster mana pun, menggunakan alat manajemen yang ada. Hal itu akan membuat SMI mudah bagi Azure dan layanan Kubernetes yang dihosting di cloud lainnya untuk membuatnya menjadi layanan Kubernetes terkelola yang sudah ada.

Apakah Anda ingin menggunakan Linkerd atau Aspen Mesh atau VMware's NSX Service Mesh, dengan SMI Anda akan dapat memilih yang Anda sukai, meningkatkan portabilitas kode dan menghindari lock-in ke layanan cloud tertentu. Lalu ada peluang untuk mengganti jerat layanan tanpa memengaruhi kode Anda. Jika mesh layanan baru menawarkan performa yang lebih baik, yang perlu Anda lakukan hanyalah mengubah pipeline build Anda untuk menggunakan mesh baru, lalu menerapkan aplikasi yang diperbarui.

Sangat menarik untuk melihat Microsoft memimpin proyek seperti ini, bekerja dengan komunitas Kubernetes yang luas. Dengan mengambil pendekatan yang secara eksplisit tidak berfokus pada pembuatan mesh layanan, Azure dapat menawarkan layanan mesh yang berbeda sebagai bagian dari konfigurasi AKS, memungkinkan Anda memilih alat yang Anda inginkan tanpa perlu mengubah kode apa pun.