Halo, Habr! Saya persembahkan untuk perhatian Anda terjemahan artikel oleh penulis .
Pada saat dunia TI secara bertahap beralih ke layanan mikro dan alat seperti Kubernetes, hanya ada satu masalah yang semakin terlihat. Masalah ini - versi layanan mikro. Namun, komunitas TI percaya bahwa situasi saat ini jauh lebih baik daripada situasi saat ini teknologi generasi sebelumnya. Namun, pembuatan versi layanan mikro adalah masalah yang sangat kompleks. Salah satu buktinya bisa berupa artikel seperti .
Jika Anda masih belum memahami masalahnya dengan membaca teks ini, izinkan saya menjelaskannya. Misalkan produk Anda terdiri dari 10 layanan mikro. Sekarang mari kita asumsikan bahwa 1 versi baru dirilis untuk masing-masing layanan mikro ini. Hanya 1 versi - Saya harap kita semua bisa sepakat bahwa ini adalah fakta yang sangat sepele dan tidak penting. Namun sekarang, mari kita lihat lagi produk kita. Hanya dengan satu versi baru dari setiap komponen, kami sekarang memiliki 2^10 - atau 1024 permutasi tentang bagaimana produk kami dapat dibuat.
Jika masih ada kesalahpahaman, izinkan saya menguraikan matematikanya. Jadi kami memiliki 10 layanan mikro, masing-masing menerima satu pembaruan. Artinya, kami mendapatkan 2 kemungkinan versi untuk setiap layanan mikro (lama atau baru). Sekarang, untuk setiap komponen produk, kita dapat menggunakan salah satu dari dua versi ini. Secara matematis sama seperti kita mempunyai bilangan biner yang terdiri dari 10 digit. Sebagai contoh, katakanlah 1 adalah versi baru, dan 0 adalah versi lama - maka satu kemungkinan permutasi dapat dinyatakan sebagai 1001000000 - dengan komponen ke-1 dan ke-4 diperbarui, dan komponen lainnya tidak. Dari matematika kita mengetahui bahwa bilangan biner 10 digit dapat memiliki nilai 2^10 atau 1024. Artinya, kami sudah memastikan skala jumlah yang kami hadapi.
Mari kita lanjutkan alasan kita lebih jauh - apa yang akan terjadi jika kita memiliki 100 layanan mikro dan masing-masing layanan memiliki 10 versi yang memungkinkan? Seluruh situasi menjadi sangat tidak menyenangkan - kita sekarang memiliki 10^100 permutasi - yang merupakan jumlah yang sangat besar. Namun, saya lebih suka memberi label situasi ini seperti ini, karena sekarang kita tidak lagi bersembunyi di balik kata-kata seperti “kubernetes”, melainkan menghadapi masalah apa adanya.
Mengapa saya begitu terpesona dengan masalah ini? Salah satunya karena, setelah sebelumnya berkecimpung di dunia NLP dan AI, kami banyak membahas masalah ledakan kombinatorial sekitar 5-6 tahun yang lalu. Hanya saja, alih-alih versi, kami memiliki kata-kata tersendiri, dan alih-alih produk, kami memiliki kalimat dan paragraf. Meskipun sebagian besar masalah NLP dan AI masih belum terselesaikan, harus diakui bahwa kemajuan signifikan telah dicapai dalam beberapa tahun terakhir. (menurut saya, kemajuan bisa dicapaiоAkan lebih baik jika orang-orang di industri ini kurang memperhatikan pembelajaran mesin dan lebih memperhatikan teknik lainnya - tetapi ini sudah di luar topik).
Mari kembali ke dunia DevOps dan layanan mikro. Kita dihadapkan pada masalah besar, menyamar sebagai gajah di Kunstkamera - karena yang sering saya dengar adalah “ambil saja kubernet dan kemudi, dan semuanya akan baik-baik saja!” Tapi tidak, semuanya tidak akan baik-baik saja jika dibiarkan apa adanya. Selain itu, solusi analitis terhadap masalah ini tampaknya tidak dapat diterima karena kompleksitasnya. Seperti di NLP, pertama-tama kita harus mengatasi masalah ini dengan mempersempit cakupan pencarian—dalam hal ini, dengan menghilangkan permutasi yang sudah ketinggalan zaman.
Salah satu hal yang mungkin bisa membantu adalah sesuatu yang saya tulis tahun lalu . Penting juga untuk dicatat bahwa proses CI/CD yang dirancang dengan baik sangat membantu mengurangi variasi. Namun, keadaan CI/CD saat ini tidak cukup baik untuk menyelesaikan masalah permutasi tanpa alat tambahan untuk akuntansi dan pelacakan komponen.
Yang kita butuhkan adalah sistem eksperimen pada tahap integrasi, di mana kita dapat menentukan faktor risiko untuk setiap komponen, dan juga memiliki proses otomatis untuk memperbarui berbagai komponen dan pengujian tanpa campur tangan operator – untuk melihat mana yang berhasil dan mana yang tidak.
Sistem eksperimen seperti itu akan terlihat seperti ini:
- Pengembang menulis pengujian (ini adalah tahap kritis - karena jika tidak, kami tidak memiliki kriteria evaluasi - ini seperti memberi label pada data dalam pembelajaran mesin).
- Setiap komponen (proyek) menerima sistem CI-nya sendiri - proses ini sekarang telah dikembangkan dengan baik, dan masalah pembuatan sistem CI untuk satu komponen sebagian besar telah teratasi
- “Sistem integrasi cerdas” mengumpulkan hasil dari berbagai sistem CI dan merakit proyek komponen menjadi produk akhir, menjalankan pengujian dan akhirnya menghitung jalur terpendek untuk mendapatkan fungsionalitas produk yang diinginkan berdasarkan komponen yang ada dan faktor risiko. Jika pembaruan tidak memungkinkan, sistem ini akan memberi tahu pengembang tentang komponen yang ada dan komponen mana yang menyebabkan kesalahan. Sekali lagi, sistem pengujian sangat penting di sini - karena sistem integrasi menggunakan pengujian sebagai kriteria evaluasi.
- Sistem CD, yang kemudian menerima data dari Sistem Integrasi Cerdas dan melakukan pembaruan secara langsung. Tahap ini mengakhiri siklus.
Ringkasnya, bagi saya salah satu masalah terbesar saat ini adalah kurangnya “Sistem Integrasi Cerdas” yang dapat menghubungkan berbagai komponen ke dalam suatu produk sehingga memungkinkan Anda melacak bagaimana produk secara keseluruhan disatukan. Saya akan tertarik dengan pemikiran komunitas mengenai hal ini (spoiler - Saya sedang mengerjakan sebuah proyek , yang dapat menjadi sistem integrasi yang cerdas).
Satu hal lagi yang ingin saya sampaikan adalah, bagi saya, monolit tidak dapat diterima untuk proyek apa pun, bahkan yang berukuran sedang. Bagi saya, upaya untuk mempercepat waktu pelaksanaan dan kualitas pembangunan dengan kembali ke monolit menimbulkan skeptisisme yang besar. Pertama, monolit memiliki masalah serupa dalam mengelola komponen - di antara berbagai perpustakaan yang dikandungnya, namun semua ini tidak begitu terlihat dan memanifestasikan dirinya terutama dalam waktu yang dihabiskan oleh pengembang. Konsekuensi dari masalah monolit adalah ketidakmungkinan untuk membuat perubahan pada kode - dan kecepatan pengembangan yang sangat lambat.
Layanan mikro memperbaiki situasi, tetapi 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 memberikan hasil yang lebih baik, dan tim mencapai hasil lebih cepat (mungkin terutama karena pengurangan ukuran unit pengembangan - atau ukuran batch). Namun, peralihan dari monolit ke layanan mikro belum cukup memperbaiki prosesnya - ledakan kombinatorial versi layanan mikro adalah masalah besar, dan kami memiliki banyak potensi untuk memperbaiki situasi saat kami menyelesaikannya.
Sumber: www.habr.com