Bagaimana cara beralih ke layanan-mikro membuat masalah run-time?

Komentator berikut menulis :

Layanan Microsoft menggeser disfungsi organisasi Anda dari masalah waktu kompilasi ke masalah run time.

Komentator ini memperluas masalah dengan mengatakan:

Fitur bukan bug. Jalankan masalah waktu => masalah prod = = umpan balik yang lebih kuat, lebih cepat tentang disfungsi kepada mereka yang bertanggung jawab

Sekarang saya mendapatkannya dengan microservices Anda:

• berpotensi meningkatkan latensi through-put Anda - yang merupakan masalah produksi dan run-time.
• tingkatkan jumlah "antarmuka jaringan" dalam kode Anda di mana mungkin ada kesalahan run-time parsing.
• berpotensi dapat melakukan penyebaran biru-hijau. Itu bisa ditahan oleh ketidakcocokan antarmuka (lihat antarmuka jaringan). Tetapi jika penyebaran biru-hijau berhasil maka itu lebih merupakan masalah run-time.

Pertanyaan saya adalah: Apa artinya beralih ke layanan-mikro menciptakan masalah run-time?

Saya punya masalah. Mari kita gunakan Layanan Mikro! Sekarang saya memiliki 13 masalah yang didistribusikan.

Membagi sistem Anda menjadi komponen yang dienkapsulasi, kohesif, dan dipisahkan adalah ide yang bagus. Ini memungkinkan Anda untuk mengatasi masalah yang berbeda secara terpisah. Tetapi Anda dapat melakukannya dengan sangat baik dalam penyebaran monolitik (lihat Fowler: Microservice Premium ). Bagaimanapun, inilah yang telah diajarkan OOP selama beberapa dekade! Jika Anda memutuskan untuk mengubah komponen Anda menjadi layanan microser, Anda tidak mendapatkan keunggulan arsitektur apa pun. Anda mendapatkan beberapa fleksibilitas mengenai pilihan teknologi dan mungkin skalabilitas (tetapi tidak harus!). Tetapi Anda dijamin beberapa sakit kepala yang berasal dari (a) sifat sistem yang terdistribusi, dan (b) komunikasi antar komponen. Memilih layanan microser berarti Anda memiliki masalah lain yang sangat mendesak sehingga Anda bersedia menggunakan layanan microser meskipun ada masalah ini.

Jika Anda tidak dapat merancang monolith yang terbagi menjadi beberapa komponen, Anda juga tidak dapat merancang sistem layanan-mikro. Dalam basis kode monolitik, rasa sakit akan cukup jelas. Idealnya, kode tidak akan dikompilasi jika rusak parah. Tetapi dengan layanan microser, setiap layanan dapat dikembangkan secara terpisah, mungkin bahkan dalam bahasa yang berbeda. Setiap masalah dalam interaksi komponen tidak akan terlihat sampai Anda mengintegrasikan komponen Anda, dan pada saat itu sudah terlambat untuk memperbaiki arsitektur secara keseluruhan.

Sumber bug nomor 1 adalah ketidakcocokan antarmuka. Mungkin ada kesalahan mencolok seperti parameter yang hilang, atau lebih banyak contoh halus seperti lupa untuk memeriksa kode kesalahan, atau lupa untuk memeriksa prasyarat sebelum memanggil metode. Pengetikan statis mendeteksi masalah seperti sedini mungkin: di IDE Anda dan di kompiler, sebelum kode pernah berjalan. Sistem dinamis tidak memiliki kemewahan ini. Itu tidak akan meledak sampai kode yang salah dijalankan.

Implikasinya bagi layanan mikro menakutkan. Layanan Microsoft secara inheren dinamis. Kecuali jika Anda pindah ke bahasa deskripsi layanan formal, Anda tidak dapat memverifikasi segala jenis kebenaran penggunaan antarmuka Anda. Anda harus menguji, menguji, menguji! Tetapi tes mahal dan biasanya tidak lengkap, yang meninggalkan kemungkinan bahwa masalah mungkin masih ada dalam produksi. Kapan masalah itu akan terlihat? Hanya ketika jalur yang salah itu diambil, pada saat dijalankan, dalam produksi. Gagasan bahwa masalah prod akan mengarah pada umpan balik yang lebih cepat adalahmeriah salah berbahaya, kecuali jika Anda terhibur dengan kemungkinan kehilangan data.

Tweet pertama milik saya, jadi saya akan mengembangkannya:

Misalkan Anda memiliki 100 pengembang, bekerja pada aplikasi monolitik. Itu terlalu banyak orang untuk berkomunikasi secara efektif antara satu sama lain, sehingga perusahaan harus bekerja keras untuk membaginya menjadi tim yang lebih kecil dan menciptakan pola komunikasi yang baik di antara mereka. Ketika organisasi itu "disfungsional", tim mungkin tidak berbicara satu sama lain, mereka tidak selaras dengan tujuan yang lebih besar, mereka tidak setuju pada prioritas dll - akibatnya, dibutuhkan selamanya untuk mengirimkan sesuatu. Ini adalah "masalah waktu kompilasi" dalam arti bahwa disfungsi sudah jelas sebelum perangkat lunak diproduksi. Proyek ini mungkin merupakan pawai kematian atau tidak akan pernah dikirimkan ("kompilasi").

Saya pikir banyak orang tertarik pada layanan mikro, dan pindah ke mereka, bukan karena manfaat teknis / arsitektur yang melekat, tetapi karena itu memungkinkan mereka untuk mengabaikan disfungsi organisasi. Alih-alih mencoba menyelaraskan 100 pengembang, mereka berharap bahwa mereka dapat memiliki tim kecil yang bekerja di silo, masing-masing fokus pada layanan mikro kecil mereka sendiri. Jika Anda berada dalam organisasi yang disfungsional, ini sangat menarik: memberi Anda izin lebih besar untuk menghindari orang yang tidak Anda sukai, untuk tidak berkomunikasi.

Sayangnya itu menjadi "masalah waktu berjalan" karena begitu perangkat lunak berjalan dalam produksi, komunikasi yang baik menjadi sama pentingnya. Masalah dengan organisasi - tim dan bagaimana mereka disejajarkan dan berkomunikasi - bermanifestasi pada "run time".

Inti dari tweet saya adalah: jika apa yang Anda miliki adalah masalah orang , arsitektur baru tidak akan membantu. Itu hanya akan menunda efek dari masalah. Saya pikir daya tarik layanan mikro bagi banyak orang adalah harapan bahwa hal itu akan secara ajaib menyelesaikan masalah orang-orang ini.

Pertanyaan saya adalah: Apa artinya beralih ke layanan-mikro menciptakan masalah run-time?

Itu tidak apa yang mereka tweet mengatakan! Mereka tidak mengatakan apa-apa tentang beralih ke layanan-layanan mikro , juga tidak mengatakan apa-apa tentang menciptakan masalah. Mereka hanya mengatakan sesuatu tentang masalah bergeser .

Dan mereka memberikan batasan kontekstual pada pernyataan mereka, yaitu bahwa organisasi Anda tidak berfungsi.

Jadi, yang pada dasarnya tweet pertama katakan adalah dua hal:

• "Jika organisasi Anda tidak mampu merancang sistem rumit sekarang tanpa layanan microser, maka secara ajaib tidak akan bisa merekayasa sistem kompleks dengan layanan microser" dan
• "masalah yang disebabkan oleh ketidakmampuan yang sekarang muncul selama waktu kompilasi, yaitu selama pengembangan kemudian akan muncul selama waktu berjalan, yaitu dalam produksi" (secara teknis, mereka juga bisa muncul selama pengujian, tetapi ingat, kutipan membatasi sendiri untuk organisasi disfungsional, yang kemungkinan memiliki rezim pengujian di bawah standar)

The kedua Tweet mengatakan bahwa fakta bahwa masalah hanya menampakkan diri dalam produksi, yaitu di mana pelanggan melihat mereka, adalah fitur, bukan bug, karena ketika pelanggan mengeluh, yang cenderung untuk didengar di tempat yang berbeda daripada ketika membangun istirahat, yaitu di tempat-tempat yang dapat melakukan sesuatu tentang disfungsi organisasi (misalnya manajemen tingkat tinggi). Karena disfungsi organisasi biasanya merupakan kegagalan manajemen tingkat tinggi, ini berarti bahwa pelanggan yang tidak puas mencerminkan buruk pada mereka yang pada akhirnya bertanggung jawab atas ketidakpuasan itu, sedangkan kualitas kode rendah yang disebabkan oleh kegagalan manajemen tingkat tinggi biasanya hanya berdampak buruk pada pengembang, yang Namun, tidak bersalah dan tidak dapat melakukan sesuatu.

Jadi, tweet pertama mengatakan bahwa layanan microsoft memindahkan masalah yang disebabkan oleh manajemen yang buruk dari waktu kompilasi, di mana hanya pengembang yang melihatnya, untuk menjalankan waktu, tempat pelanggan melihatnya. Tweet kedua mengatakan itu adalah hal yang baik, karena kemudian, masalahnya melukai mereka yang bertanggung jawab atas mereka.

Itu menciptakan masalah run-time yang bertentangan dengan masalah waktu kompilasi .

Aplikasi monolitik sulit dan mahal untuk dikompilasi. Tetapi begitu kompilasi Anda dapat yakin bahwa tidak ada ketidakcocokan yang sangat bodoh antara komponen ada, karena sistem tipe dapat menangkap mereka. Kesalahan yang sama dalam sistem microservives mungkin tidak muncul sampai dua komponen spesifik benar-benar berinteraksi dengan cara tertentu.

Baik dalam sistem monolitik dan layanan microser Anda harus mendefinisikan antarmuka antara subsistem. Antarmuka harus dirancang dengan baik, terdokumentasi dengan baik, dan setabil mungkin. Ini sama dengan di OOP.

Jika organisasi Anda tidak dapat melakukan ini, layanan microser juga tidak akan menyelesaikan masalah. Dalam layanan microser Anda memiliki antarmuka Web publik. Jadi Anda bahkan harus mengeluarkan lebih banyak upaya dalam desain antarmuka.

Jika antarmuka tidak dirancang dengan benar, Anda akan mendapatkan dua jenis masalah runtime:

1. Jika antarmuka tidak digunakan dengan benar, Anda akan mendapatkan kesalahan saat runtime, bukan pada waktu kompilasi.
2. Memanggil antarmuka web cukup lambat, sehingga Anda bisa mendapatkan masalah kinerja.

Saya pikir menghasilkan masalah runtime bukanlah cara yang benar dalam mengomunikasikan masalah organisasi kepada mereka yang bertanggung jawab.