Layanan Mikro - ledakan kombinatorial versi

Halo, Habr! Saya mempersembahkan kepada Anda terjemahan penulis dari artikel Microservices - Combinatorial Explosion of Versi .

Di masa ketika dunia TI secara bertahap pindah ke layanan-layanan dan perangkat-perangkat mikro seperti Kubernetes, hanya satu masalah yang menjadi lebih nyata. Masalah ini adalah ledakan kombinatorial dari versi layanan mikro. Namun demikian, komunitas TI percaya bahwa situasi saat ini jauh lebih baik daripada neraka Ketergantungan generasi teknologi sebelumnya. Namun, kontrol versi dari layanan microser adalah masalah yang sangat kompleks. Salah satu bukti dari ini dapat ditemukan dalam artikel seperti "Kembalikan Monolith Saya ke Saya" .

Jika Anda membaca teks ini namun belum memahami masalahnya, izinkan saya menjelaskannya. Misalkan produk Anda terdiri dari 10 layanan microser. Sekarang anggaplah bahwa untuk masing-masing layanan microser ini 1 versi baru dirilis. Hanya versi 1 - Saya harap kita semua bisa setuju bahwa ini adalah fakta yang sangat sepele dan tidak penting. Namun, sekarang lihat produk kami lagi. Dengan hanya satu versi baru dari masing-masing komponen, kami sekarang memiliki 2 ^ 10 - atau 1024 permutasi tentang bagaimana produk kami dapat disusun.

Jika masih ada kesalahpahaman, izinkan saya memperluas matematika. Jadi, kami memiliki 10 layanan mikro, masing-masing menerima satu pembaruan. Artinya, kami mendapatkan 2 versi yang memungkinkan untuk setiap layanan Microsoft (baik lama atau baru). Sekarang, untuk masing-masing komponen produk, kita dapat menggunakan salah satu dari dua versi ini. Secara matematis, ini sama seperti jika kita memiliki angka biner 10 karakter. Sebagai contoh, katakanlah 1 adalah versi baru, dan 0 adalah versi lama - maka satu permutasi yang mungkin dapat ditetapkan sebagai 1001000000 - di mana komponen 1 dan 4 diperbarui, tetapi sisanya tidak. Dari matematika, kita tahu bahwa angka biner 10 karakter dapat memiliki nilai 2 ^ 10 atau 1024. Artinya, kami telah mengkonfirmasi skala nomor yang dihadapinya.

Kami melanjutkan diskusi lebih lanjut - dan apa yang terjadi jika kami memiliki 100 layanan Microsoft dan masing-masing memiliki 10 versi yang memungkinkan? Seluruh situasi menjadi sangat tidak menyenangkan - sekarang kita memiliki 10 ^ 100 permutasi - dan ini adalah jumlah yang sangat besar. Namun demikian, saya lebih suka menggambarkan situasi ini begitu saja, karena sekarang kita tidak bersembunyi di balik kata-kata seperti "kubernetes", tetapi kita menghadapi masalah seperti itu.

Mengapa masalah ini begitu menarik bagi saya? Sebagian karena bekerja lebih awal di dunia NLP dan AI, kami membahas banyak masalah ledakan kombinatorial sekitar 5-6 tahun yang lalu. Hanya alih-alih versi kami memiliki kata-kata yang terpisah, dan alih-alih produk kami memiliki kalimat dan paragraf. Meskipun masalah NLP dan AI sebagian besar masih belum terselesaikan, kita harus mengakui bahwa kemajuan signifikan telah dibuat selama beberapa tahun terakhir.(Dalam pandangan saya, kemajuan dapat digunakan untuk lshim jika orang-orang di industri sedikit kurang memperhatikan pembelajaran mesin dan teknik lainnya sedikit lebih - tetapi ini di luar topik).

Saya akan kembali ke dunia DevOps dan microservices. Kami dihadapkan dengan masalah besar, menyamar sebagai gajah di Kunstkamera - karena apa yang sering saya dengar adalah "ambil kubernet dan helm, dan semuanya akan baik-baik saja!" Tapi tidak, semuanya tidak akan baik-baik saja jika semuanya dibiarkan apa adanya. Selain itu, solusi analitis untuk masalah ini tampaknya tidak dapat diterima mengingat kompleksitasnya. Seperti dalam NLP, pertama-tama kita harus mendekati masalah ini dengan mempersempit ruang lingkup pencarian - dalam hal ini, dengan menghilangkan permutasi usang.

Salah satu hal yang dapat membantu - saya menulis tahun lalutentang perlunya mempertahankan spread minimum antara versi yang disediakan untuk pelanggan . Penting juga untuk dicatat bahwa proses CI / CD yang dikembangkan dengan baik sangat membantu dalam mengurangi variasi. Namun, keadaan saat ini dengan CI / CD tidak cukup baik untuk menyelesaikan masalah permutasi tanpa alat tambahan untuk merekam dan melacak komponen.

Yang kami butuhkan adalah sistem eksperimen pada tahap integrasi, di mana kami dapat menentukan faktor risiko untuk setiap komponen, dan juga memiliki proses otomatis untuk memperbarui berbagai komponen dan pengujian tanpa intervensi operator - untuk melihat mana yang berhasil dan yang tidak.

Sistem eksperimen seperti itu dapat terlihat seperti ini:

1. ( — — ).
2. () CI — , CI
3. « » CI - , . , . , — .
4. CD , « » . .

Kesimpulannya, bagi saya salah satu masalah terbesar sekarang adalah tidak adanya "Sistem Integrasi Cerdas" yang akan menghubungkan berbagai komponen ke dalam produk dan dengan demikian memungkinkan Anda melacak bagaimana produk secara keseluruhan disusun. Saya akan tertarik pada pemikiran komunitas tentang hal ini (spoiler - Saya saat ini sedang mengerjakan proyek Reliza , yang bisa menjadi sistem integrasi yang cerdas).

Satu hal terakhir yang ingin saya sebutkan adalah bahwa bagi saya monolit tidak dapat diterima untuk proyek apa pun yang setidaknya berukuran sedang. Bagi saya, ada keraguan besar tentang upaya untuk mempercepat waktu implementasi dan kualitas pengembangan dengan kembali ke monolith. Pertama, monolith memiliki masalah yang sama dalam manajemen komponen - di antara berbagai perpustakaan yang ada di dalamnya, namun, semua ini tidak begitu terlihat dan memanifestasikan dirinya terutama pada waktu yang dihabiskan pengembang. Konsekuensi dari masalah monolit adalah kenyataan bahwa tidak mungkin untuk membuat perubahan pada kode - dan kecepatan pengembangannya sangat lambat.

Layanan Microsoft memperbaiki situasi, tetapi kemudian arsitektur layanan mikro menghadapi masalah ledakan kombinatorial pada tahap integrasi. Ya, secara umum, kami telah memindahkan masalah yang sama - dari tahap pengembangan ke tahap integrasi. Namun, menurut pendapat saya, pendekatan layanan mikro masih mengarah pada hasil yang lebih baik, dan tim mencapai hasil lebih cepat (mungkin terutama karena pengurangan ukuran unit pengembangan - atau ukuran batch ). Namun, transisi dari monolit ke layanan mikro belum memberikan peningkatan proses yang memadai - ledakan kombinatorial versi layanan mikro adalah masalah besar, dan kami memiliki potensi besar untuk memperbaiki situasi saat diselesaikan.