Mengapa ukuran bangunan menjadi masalah?

Saya sering mendengar (dari orang-orang, tetapi juga dari CLI informatif) bahwa "ukuran build / slug besar". Ini khususnya terjadi ketika build berukuran 0,5 - 2 GB

Mengapa (atau dalam kondisi apa) membangun ukuran sedemikian memprihatinkan?

Catatan: alasan saya bertanya adalah karena saya melihat sumber daya seperti penyimpanan dan menghitung sebagai relatif murah dibandingkan di masa lalu, jadi, jika ada, saya berharap ukuran bangunan menjadi lebih sedikit masalah sekarang daripada di masa lalu

Ketika saya mengangkat masalah ukuran bangunan sebagai masalah, biasanya tidak berasal dari "ini sangat besar, akan mahal untuk menyimpannya".

Masalah utama dengan build besar adalah sebagai berikut -

• peningkatan waktu pengiriman. memindahkan potongan-potongan besar dari satu tempat ke tempat lain sering memakan waktu.
• seringnya perubahan pada artefak besar ditambah periode retensi yang besar membuat penyimpanan artefak seperti itu menjadi mahal, apalagi dengan artefak berlapis seperti gambar buruh pelabuhan.
• membuat artefak besar seperti itu biasanya memakan waktu, lebih dari menciptakan artefak yang jauh lebih kecil. mengotomatiskan proses untuk membuat artefak yang lebih kecil mungkin membutuhkan waktu, tetapi otomatisasi yang dapat diulang harus sesingkat mungkin untuk memungkinkan umpan balik yang cepat.
• memulihkan dari kegagalan (tergantung pada konfigurasi) mungkin membutuhkan lebih banyak waktu dengan artefak yang lebih besar, terutama ketika artefak yang lebih lama perlu diterapkan kembali alih-alih yang baru rusak.

Saya berlangganan empat metrik devops:

• Pimpin waktu untuk perubahan - persingkat
• Frekuensi penerapan - menambah frekuensi
• Saatnya memulihkan layanan - persingkat
• Ubah tingkat kegagalan - kurangi menjadi tidak pernah

Artefak besar biasanya menimbulkan masalah pada masing-masing metrik ini, dan tidak satu pun dari metrik ini yang benar-benar mementingkan biaya penyimpanan - karena itu murah, waktu mahal.

Melengkapi jawaban Evgeny dengan beberapa contoh lagi.

Apa yang Anda maksud dengan ukuran build mungkin sedikit penting:

• jika ukuran artefak yang sedang dibangun (masing-masing secara individual atau ukuran gabungannya) - yang dapat berarti dalam penyimpanan artefak atau operasi penggunaan / penyebaran jika operasi tersebut memiliki batas ukuran dan dilampaui. Misalnya aplikasi Google App Engine memiliki batas penyebaran seperti itu , jika penyebaran yang dicapai akan gagal, lihat Kesalahan saat menggunakan ke Google App Engine .

• jika ukuran ruang kerja di mana Anda melakukan membangun itu mungkin penting dari perspektif manajemen ruang kerja. Bahkan 2G mungkin signifikan - misalnya jika Anda membangun sistem file RAM pada mesin yang tidak banyak RAM. Tetapi beberapa build bisa jauh lebih besar - saya harus berurusan dengan ruang kerja + 500G (ketika sebagian besar disk server saya berada di bawah 1T).

Jika build adalah bagian dari pipa CI / CD Anda maka semakin besar ukuran build semakin lama waktu eksekusi pipeline (melakukan build aktual dan, jika berlaku, pengarsipan, penggelaran untuk pengujian, analisis jika terjadi kegagalan, pembersihan, dll.) - pengembangan Anda secara keseluruhan lebih lambat / berisiko / lebih mahal.

Jika Anda mencapai batas yang sulit Anda harus kreatif untuk mengatasinya (tidak selalu sederhana / mungkin). Jika itu hanya kinerja / biaya Anda juga memiliki pilihan untuk menerima dan hidup dengannya dan / atau mengatasinya secara parsial / bertahap.

Mungkin layak untuk membedakan antara:

• build membengkak - ketika ukuran tidak perlu meningkat - memperbaiki masalah biasanya dimungkinkan dengan menjatuhkan bagian yang tidak perlu
• kasus di mana konten bangunan itu sendiri adalah apa yang benar-benar diperlukan - ukurannya tidak terlalu penting - itu diperlukan, satu-satunya cara untuk mengatasi mungkin dengan mengorbankan beberapa fungsi

Saya akan menambahkan masalah yang sangat konkret yang sebenarnya kita hadapi. Ini adalah efek samping dari arsitektur buruk yang sedang kita derita saat ini:

Karena build kami besar dan kami perlu memuat banyak dependensi hanya dengan menyatukan semuanya membutuhkan waktu yang sangat lama. Kita seharusnya sudah lama membagi bangunan menjadi banyak bangunan kecil sebagai pendekatan ke arsitektur layanan-mikro alih-alih satu monolit besar.

Menjalankan semua tes untuk monolit membutuhkan waktu sekitar 45 menit dan memblokir lingkungan CI kami untuk saat ini.

Karena bebannya sangat intensif dan membutuhkan waktu yang lama, saat ini mustahil bagi kami untuk menjalankan beberapa build secara paralel satu sama lain.

Jadi, seperti poster sebelum saya telah menyatakan pada tingkat yang lebih teoretis, ini harus menunjukkan beberapa potensi (dan kemungkinan) implikasi samping yang biasanya dimiliki oleh bangunan besar di luar yang membutuhkan lebih banyak ruang pada harddisk.