Saya sudah lama ingin menulis artikel tentang topik arsitektur layanan mikro, tetapi ada dua hal yang menghentikan saya - semakin jauh saya mendalami topik tersebut, semakin saya merasa bahwa apa yang saya ketahui sudah jelas, dan apa yang tidak saya ketahui. tidak tahu perlu dipelajari dan dipelajari. Di sisi lain, menurut saya sudah ada sesuatu yang perlu didiskusikan di kalangan khalayak luas. Jadi pendapat alternatif dipersilahkan.
Hukum Conway dan hubungan antara bisnis, organisasi dan sistem informasi
Sekali lagi saya izinkan diri saya mengutip:
βSetiap organisasi yang merancang suatu sistem (dalam arti luas) akan menerima desain yang strukturnya mereplikasi struktur tim dalam organisasi tersebut.β
β Melvyn Conway, 1967
Menurut saya, undang-undang ini lebih cenderung berkaitan dengan kelayakan penyelenggaraan suatu usaha, dibandingkan langsung dengan sistem informasi. Izinkan saya menjelaskan dengan sebuah contoh. Katakanlah kita memiliki peluang bisnis yang cukup stabil dengan siklus hidup yang panjang sehingga masuk akal untuk mengatur suatu perusahaan (ini bukan salah ketik, tapi saya sangat suka istilah yang saya curi ini). Tentu saja, sistem pendukung bisnis ini akan secara organisasi dan proses sesuai dengan bisnis ini.
Orientasi bisnis sistem informasi
Izinkan saya menjelaskan dengan sebuah contoh. Katakanlah ada peluang bisnis untuk menyelenggarakan bisnis penjualan pizza. Dalam versi V1 (sebut saja pra-informasi), perusahaannya adalah restoran pizza, mesin kasir, dan layanan pengiriman. Versi ini berumur panjang dalam kondisi variabilitas lingkungan yang rendah. Kemudian datanglah versi 2 yang menggantikannya - lebih maju dan mampu menggunakan sistem informasi pada intinya untuk bisnis dengan arsitektur monolitik. Dan di sini, menurut pendapat saya, terdapat ketidakadilan yang mengerikan sehubungan dengan monolit - arsitektur yang diduga monolitik tidak sesuai dengan model bisnis domain. Ya, jika demikian, sistem tidak akan dapat bekerja sama sekali - bertentangan dengan hukum Conway dan akal sehat yang sama. Tidak, arsitektur monolitik sepenuhnya konsisten dengan model bisnis pada tahap pengembangan bisnis ini - tentu saja yang saya maksud adalah tahap ketika sistem telah dibuat dan dioperasikan. Merupakan fakta yang sangat menakjubkan bahwa apa pun pendekatan arsitekturnya, baik arsitektur berorientasi layanan versi 3 maupun arsitektur layanan mikro versi N akan bekerja dengan sama baiknya. Apa menariknya?
Semuanya mengalir, semuanya berubah, atau apakah layanan mikro merupakan sarana untuk melawan kompleksitas?
Sebelum melanjutkan, mari kita lihat beberapa kesalahpahaman tentang arsitektur layanan mikro.
Para pendukung penggunaan pendekatan layanan mikro sering kali berpendapat bahwa memecah monolit menjadi layanan mikro menyederhanakan pendekatan pengembangan dengan mengurangi basis kode layanan individual. Menurut pendapat saya, pernyataan ini sama sekali tidak masuk akal. Serius, interaksi yang jelas dalam kode monolit dan homogen tampak rumit? Jika hal ini benar-benar terjadi, semua proyek pada awalnya akan dibangun sebagai layanan mikro, sementara praktik menunjukkan bahwa migrasi dari monolit ke layanan mikro jauh lebih umum. Kompleksitas tidak hilang; ia hanya berpindah dari modul individual ke antarmuka (baik itu bus data, RPC, API, dan protokol lainnya) dan sistem orkestrasi. Dan ini sulit!
Keuntungan menggunakan tumpukan heterogen juga dipertanyakan. Saya tidak akan berpendapat bahwa hal ini juga mungkin terjadi, namun kenyataannya jarang terjadi (Ke depan - ini harus terjadi - melainkan sebagai konsekuensi daripada keuntungan).
Siklus hidup produk dan siklus hidup layanan
Perhatikan lagi diagram di atas. Bukan suatu kebetulan jika saya mencatat penurunan siklus hidup versi bisnis yang terpisah - dalam kondisi modern, percepatan transisi bisnis antar versilah yang menentukan keberhasilannya. Keberhasilan suatu produk ditentukan oleh kecepatan pengujian hipotesis bisnis di dalamnya. Dan di sinilah, menurut saya, letak keunggulan utama arsitektur layanan mikro. Tapi mari kita mulai secara berurutan.
Mari kita beralih ke tahap berikutnya dalam evolusi sistem informasi - ke arsitektur SOA yang berorientasi layanan. Jadi, pada titik tertentu kami menonjolkan produk kami layanan berumur panjang - berumur panjang dalam artian ketika berpindah antar versi suatu produk, ada kemungkinan siklus hidup layanan akan lebih lama dibandingkan siklus hidup versi produk berikutnya. Masuk akal untuk tidak mengubahnya sama sekali - kita Yang penting adalah kecepatan transisi ke versi berikutnya. Namun sayang sekali, kami terpaksa melakukan perubahan terus-menerus pada layanan - dan di sini semuanya berfungsi untuk kami, praktik DevOps, containerisasi, dan sebagainya - semua yang terlintas dalam pikiran kami. Namun ini masih bukan layanan mikro!
Layanan mikro sebagai sarana untuk memerangi kompleksitas... manajemen konfigurasi
Dan di sini kita akhirnya dapat beralih ke peran penting layanan mikro - ini adalah pendekatan yang menyederhanakan manajemen konfigurasi produk. Secara lebih rinci, fungsi setiap layanan mikro menjelaskan dengan tepat fungsi bisnis di dalam produk sesuai dengan model domain - dan ini adalah hal-hal yang tidak hidup dalam versi jangka pendek, tetapi dalam peluang bisnis jangka panjang. Dan transisi ke versi produk berikutnya terjadi tanpa disadari - Anda mengubah/menambahkan satu layanan mikro, dan mungkin hanya skema interaksinya, dan tiba-tiba Anda menemukan diri Anda di masa depan, meninggalkan pesaing yang menangis yang terus berpindah antar versi. monolit mereka. Sekarang bayangkan ada sejumlah besar layanan mikro dengan antarmuka dan kemampuan bisnis yang telah ditentukan sebelumnya. Dan Anda datang dan membangun struktur produk Anda dari layanan mikro yang sudah jadi - cukup dengan menggambar diagram, misalnya. Selamat - Anda memiliki platform - dan sekarang Anda dapat menarik bisnis untuk diri Anda sendiri. Mimpi Mimpi.
Temuan
- Arsitektur sistem harus ditentukan oleh siklus hidup komponen-komponennya. Jika suatu komponen berada dalam versi produk, tidak ada gunanya meningkatkan kompleksitas sistem dengan menggunakan pendekatan layanan mikro.
- Arsitektur layanan mikro harus didasarkan pada model domain - karena peluang bisnis adalah domain yang berumur paling lama
- Praktik pengiriman (praktik DevOps) dan orkestrasi adalah salah satu hal yang paling penting untuk arsitektur layanan mikro - karena peningkatan laju perubahan komponen meningkatkan tuntutan pada kecepatan dan kualitas pengiriman
Sumber: www.habr.com