👍🏿 🥛 🏞️ Layanan Mikro: apa itu, mengapa itu dan kapan Anda perlu menerapkannya 👟 💃🏾 🎡

Saya ingin menulis artikel tentang topik arsitektur layanan mikro untuk waktu yang lama, tetapi dua poin berhenti sepanjang waktu - semakin saya masuk ke dalam topik, semakin saya merasa bahwa apa yang saya tahu sudah jelas, dan bahwa saya tidak tahu, saya masih harus belajar dan belajar. Di sisi lain, saya percaya bahwa sudah ada sesuatu untuk berspekulasi tentang khalayak luas. Jadi pendapat alternatif dipersilakan.

Conway Law dan hubungan antara bisnis, organisasi dan sistem informasi

Sekali lagi, saya membiarkan diri saya mengutip:

"Setiap organisasi yang merancang sistem (dalam arti luas) akan menerima desain yang strukturnya menyalin struktur tim dalam organisasi ini"
- Melvyn Conway, 1967

Menurut pendapat saya, undang-undang ini lebih cenderung terkait dengan kemanfaatan mengatur bisnis, daripada langsung ke sistem informasi. Saya akan jelaskan dengan sebuah contoh. Misalkan kita memiliki peluang bisnis yang cukup stabil dengan siklus hidup sedemikian lama sehingga masuk akal untuk mengatur suatu perusahaan (ini bukan kesalahan ketik, tapi saya sangat suka istilah yang saya ambil) Secara alami, sistem pendukung bisnis ini akan bersifat organisasi dan proses yang konsisten dengan bisnis ini .

Sistem Informasi Orientasi Bisnis

Saya akan jelaskan dengan sebuah contoh. Misalkan ada peluang bisnis untuk mengorganisir bisnis pizza. Dalam versi V1 (sebut saja pra-informasi), perusahaan itu adalah restoran pizza, meja kas, layanan pengiriman. Versi ini berumur panjang dalam kondisi variabilitas rendah di dunia sekitarnya. Kemudian datang versi 2, yang lebih maju dan dapat menggunakan sistem informasi sebagai dasar untuk bisnis dengan arsitektur monolitik. Dan di sini, menurut saya, ada ketidakadilan yang mengerikan sehubungan dengan monolit - konon arsitektur monolitik tidak sesuai dengan model bisnis domain. Ya, jika memang begitu, sistem tidak akan bisa bekerja sama sekali, bertentangan dengan hukum dan akal sehat Conway yang sama. Tidak, arsitektur monolitik sepenuhnya konsisten dengan model bisnis pada tahap pengembangan bisnis ini - tentu saja yang saya maksudkan adalah tahap ketika sistem sudah dibuat dan dioperasikan. Ini adalah fakta yang benar-benar luar biasa bahwa terlepas dari pendekatan arsitektur, baik arsitektur berorientasi layanan versi 3 dan arsitektur layanan mikro versi N akan bekerja sama baiknya. Apa yang menangkap?

Apakah semuanya mengalir, apakah semuanya berubah, atau apakah layanan mikro merupakan cara untuk menghadapi kompleksitas?

Sebelum melanjutkan, kami akan mempertimbangkan beberapa kesalahpahaman tentang arsitektur layanan microsoft.

Para pendukung pendekatan layanan-mikro sering mengatakan bahwa pemisahan monolit menjadi layanan-mikro menyederhanakan pendekatan pengembangan dengan mengurangi basis kode layanan individual. Menurut pendapat saya, pernyataan ini benar-benar omong kosong. Serius, apakah interaksi yang jelas dalam monolit dan kode homogen tampak rumit? Jika ini benar, semua proyek pada awalnya akan dibangun sebagai layanan microser, sementara praktik menunjukkan bahwa migrasi dari monolit ke layanan microser jauh lebih umum. Kompleksitas tidak hilang di mana pun, itu hanya bergerak dari modul individu ke antarmuka (apakah itu data bus, RPC, API dan protokol lainnya) dan sistem orkestrasi. Dan itu sulit!

Keuntungan menggunakan tumpukan heterogen juga meragukan. Saya tidak akan berdebat bahwa ini juga mungkin, tetapi jarang terjadi dalam kenyataan (Ke depan - ini harus menjadi tempat yang akan - tetapi lebih sebagai konsekuensi daripada keuntungan).

Siklus Hidup Produk dan Siklus Hidup Layanan

Lihatlah grafik di atas. Bukan kebetulan bahwa saya mencatat siklus hidup yang menurun dari versi yang terpisah dari sebuah bisnis - dalam kondisi modern, itu adalah percepatan transisi bisnis antara versi yang sangat penting untuk keberhasilannya. Keberhasilan produk ditentukan oleh kecepatan pengujian hipotesis bisnis di dalamnya . Dan di sini, menurut pendapat saya, keuntungan utama dari arsitektur layanan mikro dikuburkan. Tapi mari kita mulai.

Mari kita beralih ke langkah selanjutnya dalam evolusi sistem informasi - ke arsitektur SOA yang berorientasi layanan. Jadi, pada saat tertentu, kami menyoroti layanan berumur panjang dalam produk kami- berumur panjang dalam arti bahwa ketika beralih di antara versi produk ada kemungkinan bahwa siklus hidup layanan akan lebih lama dari siklus hidup versi berikutnya dari produk. Adalah logis untuk tidak mengubahnya sama sekali - kecepatan transisi ke versi berikutnya adalah penting bagi kami . Tetapi sayangnya, kami dipaksa untuk membuat perubahan konstan pada layanan - dan di sini semuanya sesuai dengan kami, dan praktik DevOps, dan kemasukan, dan sebagainya - segala sesuatu yang terlintas dalam pikiran. Tetapi ini masih bukan layanan mikro!

Microservices sebagai alat untuk memerangi kompleksitas ... manajemen konfigurasi

Dan di sini kita akhirnya dapat beralih ke peran menentukan layanan-mikro - ini adalah pendekatan yang menyederhanakan manajemen konfigurasi produk. Lebih khusus lagi, fungsi dari masing-masing layanan mikro menjelaskan dengan tepat fungsi bisnis di dalam produk sesuai dengan model domain - dan ini adalah hal-hal yang hidup bukan dalam versi yang berumur pendek, tetapi dalam peluang bisnis yang berumur panjang. Dan transisi ke versi berikutnya dari produk ini benar-benar tidak terlihat - Anda mengubah / menambahkan satu layanan mikro, dan mungkin hanya skema interaksi mereka dan tiba-tiba menemukan diri Anda di masa depan, meninggalkan pesaing yang menangis yang terus melompat di antara versi monolit mereka. Sekarang bayangkan bahwa ada sejumlah besar layanan microser dengan antarmuka yang telah ditentukan dan peluang bisnis.Dan Anda datang dan membangun struktur produk Anda dari layanan microser yang sudah jadi - hanya dengan menggambar diagram misalnya. Selamat - Anda memiliki platform - dan sekarang Anda bisa mendapatkan bisnis Anda sendiri. Mimpi Mimpi.

temuan

Arsitektur sistem harus ditentukan oleh siklus hidup komponen penyusunnya. Jika komponen hidup dalam versi produk, tidak ada gunanya meningkatkan kompleksitas sistem menggunakan pendekatan layanan-mikro.
Arsitektur microservice harus didasarkan pada model domain - dengan alasan bahwa peluang bisnis adalah area yang paling berumur panjang
Praktik pengantaran (praktik DevOps) dan orkestrasi memiliki salah satu nilai paling penting untuk arsitektur layanan mikro - dengan alasan bahwa peningkatan laju perubahan komponen menyebabkan peningkatan permintaan pada kecepatan dan kualitas pengiriman