Ada perasaan bahwa layanan mikro sering dipasarkan sebagai "peluru perak" untuk menggantikan monolit. Tetapi tidak semua orang menyukai pendekatan ini. Bahkan, kadang-kadang digunakan secara tidak benar atau tidak tepat. Di bawah ini adalah contoh masalah yang saya "beruntung" hadapi ketika menggunakan layanan microser di perusahaan yang berbeda dan yang tidak ingin saya ulangi di masa depan.
Skalabilitas Phantom
Nilai tambah besar dari pendekatan layanan mikro adalah skalabilitas. Aliran pengguna yang sangat besar dan beban tinggi dianggap tak terhindarkan. Karena itu, banyak waktu dihabiskan untuk optimasi awal, dan bukan fitur bisnis yang berguna. Pada kenyataannya, muatan tinggi tidak selalu ada.
Korban pertama dari pra-optimasi adalah proses bisnis linier. Ini diuraikan menjadi banyak layanan mikro. Semacam cadangan untuk masa depan, untuk alasan pembagian tanggung jawab atau penskalaan ilusi. Akibatnya, menjadi lebih sulit bagi bisnis untuk menavigasi lanskap TI dan berbicara bahasa yang sama dengan TI, belum lagi masalah navigasi melalui kode sumber untuk pengembang itu sendiri.
Masalah Interaksi Layanan
Layanan yang diterima tersebar dari monorep ke dalam repositori terpisah. Layanan itu sendiri menjadi lebih sulit untuk terhubung. Dalam hal ini, versi API microservice mungkin mulai menyimpang dari versi API yang sama di klien microservice. Kemudian JSON tua yang baik diganti dengan Protobuf, dan HTTP dengan gRPC untuk mendapatkan kinerja, pengetikan, dan versi API yang nyaman.
Sayangnya, solusi seperti gRPC + Protobuf tidak bebas bug. Layanan mungkin jatuh secara berurutan karena penyebaran kesalahan dan ketidakcocokan diketahui dari pasangan input-output layanan. Basis kode semakin besar, layanan debug jauh lebih sulit daripada dengan data plaintext, membawa banyak masalah baru.
Masalah ini harus diselesaikan dengan proses pengujian normal. Secara khusus, tes integrasi. Tetapi tes integrasi perlu ditulis dan dijalankan untuk setiap layanan mikro dan kelompok mereka sebagai bagian dari proses bisnis. Ini adalah tugas yang agak sulit yang biasanya mereka tidak ingin mengalokasikan waktu tambahan. Dalam hal ini, uji integrasi layanan-mikro dapat direduksi menjadi bentuk tes unit untuk monolit.
Pembatasan dan kebiasaan lama
Dengan semua ini, batasan yang biasa untuk seorang monolith mengembara ke dalam layanan mikro. Contoh nyata: satu bahasa pemrograman dan satu database untuk semua layanan microser. Dalam kasus pertama, ini adalah pembatasan mantan monolit, di kedua, itu adalah warisan yang berusaha untuk menjadi "hambatan" dari seluruh sistem. Karena penolakan oleh pengembang dan manajemen tentang kemungkinan keberadaan sistem heterogen yang dibangun dalam bahasa pemrograman yang berbeda, kemungkinan memilih alat yang sesuai untuk memecahkan masalah yang mendesak hilang.
Selain di atas, masing-masing layanan microser mungkin tidak memiliki pengembang yang bertanggung jawab untuknya. Semua orang mulai mendukung semuanya, tidak ada yang bertanggung jawab atas apa pun. Dalam hal ini, tidak ada yang memiliki pengetahuan tentang operasi layanan individual kecuali orang terakhir yang mengubah kode mereka. Ada desinkronisasi pengembang, hilangnya pemahaman tentang esensi dari pekerjaan layanan-mikro dalam kaitannya dengan tugas-tugas yang diselesaikan dalam kerangka area subjek.
Birokrasi infrastruktur
Layanan microser lebih sulit dipertahankan daripada monolit. Infrastruktur yang dulunya merupakan sepasang server menjadi cloud pribadi kecil. Dukungan untuk solusi semacam itu oleh pengembang membutuhkan banyak waktu dan menciptakan masalah bagi manajemen di masa depan. Muncul kebutuhan yang jauh dari birokrasi tambahan. Karyawan individu dipekerjakan, proses terpisah dibuat.
Dalam kasus tersebut, set aturan untuk bekerja dengan layanan microser dapat diekspos untuk menjaga integritas loop layanan microser. Kasus terburuk adalah menyangkal bahkan kemungkinan menjalankan skrip atau migrasi satu kali, mencegah akses langsung ke jalan. Intinya adalah bahwa skrip ditata sebagai layanan penuh, menambahkan satu baris lagi ke daftar panjang layanan microser.
Masa depan
Ternyata sistem yang memiliki noise berkali-kali lebih banyak daripada sinyal yang berguna. Di mana-mana - dari infrastruktur hingga kode layanan tertentu. Dari memahami skema interaksi antara layanan oleh pengembang dan manajemen perusahaan. Programmer tanpa disadari menjadi ahli dalam memecahkan teka-teki.
Tentu saja, monolit klasik tidak lebih baik. Itu lambat, stateful, sulit untuk didaur ulang, tidak dicakup oleh unit atau tes integrasi, dll. Tapi kita bisa berbuat lebih baik! Berkat mod untuk layanan-mikro, di antara banyak keuntungan lainnya, kami melihat peningkatan CI / CD dan bekerja pada pengujian. Sekarang kita dapat menerapkannya pada pendekatan lain, dan bukan hanya pada layanan microser.
Lain kali Anda mengembangkan sistem baru atau mendaur ulang yang lama, berapa pun ukurannya, pikirkan dua kali. Apakah perusahaan memerlukan skalabilitas? Apakah Anda memerlukan kemampuan untuk menangani beban tinggi? Apakah Anda benar-benar siap untuk layanan mikro sendiri? Atau lebih baik memulai dengan arsitektur yang lebih konservatif?
Mungkin tidak membangun roket, tetapi membangun skuter sederhana, karena Anda hanya perlu sampai di ujung jalan?