Layanan Mikro: MonolithFirst?

Saya telah meneliti arsitektur layanan mikro yang mencoba mendapatkan gambaran tingkat tinggi dari semua pro dan kontra, kapan dan mengapa, dll. Banyak informasi yang saya baca / tonton berasal dari ThoughtWorks (Martin Fowler, Neal Ford, et Al).

Sebagian besar karya Martin Fowler mengenai hal ini berusia beberapa tahun, ketika Microservices (sebagai nama rumah tangga dalam pemrograman, jika tidak dalam praktik umum) masih muda, jadi saya mengambil banyak dari itu dengan sebutir garam.

Satu hal khusus adalah ini:

Ketika saya mendengar cerita tentang tim yang menggunakan arsitektur layanan mikro, saya telah memperhatikan pola umum.

• Hampir semua kisah microservice yang sukses telah dimulai dengan sebuah monolith yang terlalu besar dan hancur
• Hampir semua kasus di mana saya pernah mendengar tentang sistem yang dibangun sebagai sistem microservice dari awal, itu berakhir dengan masalah serius.

Pola ini telah membuat banyak kolega saya berpendapat bahwa Anda seharusnya tidak memulai proyek baru dengan layanan mikro, bahkan jika Anda yakin aplikasi Anda akan cukup besar untuk membuatnya berharga. .

(ref: https://martinfowler.com/bliki/MonolithFirst.html - beri penekanan pada mereka)

Sekarang, 3 tahun kemudian dan dengan layanan microser istilah yang lebih umum, apakah secara umum disetujui bahwa sistem baru biasanya lebih baik dilayani dengan memiliki potongan layanan yang lebih besar (-dari-layanan-mikro-tetapi-lebih kecil dari-monolith) untuk memulai, dan membuat mereka lebih terperinci sebagai bagian dari ukuran evolusi?

Atau, adakah norma untuk memulai proyek dari awal dengan arsitektur microservice granular, berbeda dengan pernyataan di atas?

Sepertinya pendekatan umum yang waras, tetapi penasaran dengan pemikiran masyarakat.

Jika perusahaan Anda telah melakukan layanan microser untuk sementara waktu, beberapa bagian mungkin sudah dibangun dan Anda hanya perlu menggabungkannya. Kemungkinan contohnya adalah autentikasi sebagai layanan atau menyimpan data gumpalan. Dalam hal ini, Anda telah menetapkan batas dan Anda menggunakan kembali kode dalam aplikasi baru. Itu hal yang baik.

Untuk kode baru di mana Anda tidak yakin di mana batas harus berada, membangunnya dalam satu layanan. Jika Anda membuatnya modular, Anda dapat memisahkan microservices dari yang diperlukan. Terutama ketika Anda menemukan potongan-potongan layanan Anda yang perlu skala berbeda dari yang lain.

Manfaat dari layanan microser adalah Anda dapat menambahkan instance untuk mengukur pekerjaan yang dilakukan sesuai permintaan. Jika beberapa pekerjaan Anda tiba-tiba meledak, mungkin masuk akal untuk memisahkannya ke dalam layanan mikro itu sendiri.

Secara umum:

• Jika Anda sudah memiliki layanan Microsoft, gunakan kembali
• Jika Anda sedang membangun sesuatu yang baru, buat ide itu berhasil terlebih dahulu
• Saat Anda membangun, cobalah untuk menjaga hal-hal modular sehingga beberapa layanan dapat dengan mudah pecah
• Ketika Anda membangun, jika bagian dari layanan Anda perlu dapat menyesuaikan permintaan dengan tingkat yang berbeda, pisahkan itu ke dalam layanan itu sendiri

Terlalu sering, kita mendengar pedoman yang berguna dari orang-orang pintar dengan reputasi baik seperti Martin Fowler, dan kemudian mengubahnya menjadi doktrin keras yang tidak dapat diombang-ambingkan dengan cara apa pun.

Anda harus mengambil pernyataan seperti itu dalam semangat bagaimana artinya. Martin Fowler berusaha menyelamatkan orang dari kelumpuhan dengan analisis dan menyuruh mereka membangun sesuatu yang berfungsi lebih dulu. Anda selalu dapat memecahnya nanti, ketika Anda tahu lebih banyak tentang bagaimana aplikasi Anda benar-benar bekerja.

Manfaat layanan mikron yang paling berharga dapat dicapai dengan modularisasi kode sederhana. Anda dapat mengisolasi kelompok fitur ke dalam modul menggunakan sistem modul apa pun yang Anda miliki (maven, npm, nuget, apa pun). Setiap modul dapat melayani satu tujuan, duduk repo sendiri, gunakan skema DB sendiri, kelola konfigurasi sendiri, miliki backlog fitur sendiri dan jadwal rilis. Mereka masih bisa dikerahkan bersama ke monolith. Ini adalah jumlah overhead yang sangat mudah dikelola dan memberikan beberapa manfaat baik. Overhead yang lebih besar berasal dari memisahkan penyebaran yang hanya benar-benar berharga begitu Anda memiliki skala yang cukup untuk memerlukannya. Jika kode Anda sudah modular, maka itu akan menjadi migrasi yang lebih mudah ketika saatnya tiba.

Menurut pendapat saya, akan bermanfaat untuk mengembangkan monolit terlebih dahulu (atau lebih baik: mengembangkan bagian dari aplikasi Anda sebagai monolit).

Ada kasus ketika Anda tidak yakin tentang domain dan batas-batas masalah Anda (misalnya saya membangun situs manajemen kapal, apakah saya memerlukan layanan kapal DAN layanan armada, atau apakah layanan kapal cukup?), Dan dalam kasus seperti itu, Monolith bisa lebih mudah dikembangkan.

Anda harus berhenti melakukan ini jika Anda perlu membawa teknologi yang berbeda ke dalam campuran (mis. Bagian Anda yang ada ditulis dalam C #, tetapi masalah baru Anda memerlukan pembelajaran mesin, dengan yang terbaik dilakukan dengan python), memiliki pemahaman yang baik tentang domain di Anda memproyeksikan atau memperlakukan monolit Anda untuk menggembleng, misalnya semua orang hanya membangun monolit ini dan menghancurkan gagasan layanan terpisah.

Saya cukup yakin ada beberapa pertanyaan tentang artikel yang tepat dari MF ini.

Pendapat saya adalah ini:

Monolith dengan masalah pemeliharaan atau skalabilitas ditingkatkan dengan memecahnya menjadi layanan mikro. Proyek semacam itu hampir selalu akan 'berhasil' karena bahkan memecah bagian kecil dapat menghasilkan keuntungan yang terukur dan Anda dapat menarik garis di bawahnya ketika Anda bahagia.

Apakah setengah monolit Anda + antrian pesan dan beberapa proses pekerja dianggap sebagai 'Arsitektur Layanan Mikro' adalah argumen untuk menurunkan pub, tetapi Anda pasti akan menyebutnya begitu ketika Anda berbicara tentang proyek.

Di sisi lain, setiap proyek baru terlepas dari arsitektur yang dipilih berisiko tidak memenuhi harapan, jadi tentu saja Anda akan mengharapkan tingkat keberhasilan yang lebih rendah. Plus jika Anda sudah mulai bertujuan untuk membuat semuanya 'Best Practice Microservice Architecture' dari bawah ke atas maka Anda mungkin merambah ke teknologi baru dan bagian-bagian kecil dari layanan microser.

Kita juga harus ingat bahwa MF menulis dari perspektif OOP besar. Dia secara alami skeptis terhadap pendekatan terdistribusi yang lebih modern.

Di zaman sekarang ini saya mengharapkan solusi bisnis besar untuk memasukkan unsur layanan microser dan hanya orang bodoh yang akan merekomendasikan Anda membuat satu aplikasi monolith raksasa kecuali Anda mendistribusikan aplikasi gaya desktop tunggal.

Dalam pengalaman (luas) saya, saya telah menyaksikan banyak proyek gagal karena masalah orang daripada masalah teknologi. Sayangnya, orang tidak suka gagal dan cenderung salah melaporkan alasan kegagalan dan menyalahkan teknologi.

Dalam domain saya, keuangan, sebagian besar proyek baru mengikuti arsitektur layanan mikro hari ini, dan tampaknya menjadi arsitektur pemenang dari perspektif TCO (total biaya kepemilikan). Proyek-proyek ini tampaknya tidak sering gagal, dan ketika mereka melakukan alasan yang diberikan tidak sering mencantumkan arsitektur aplikasi sebagai masalah.