Semua orang berbicara tentang layanan mikro sekarang. Hampir setiap pertemuan, konferensi, dan pertemuan tidak lengkap tanpa cerita tentang apa itu layanan microser dan seberapa bagusnya, bagaimana mereka mengurangi kerumitan proyek, dll.
Pesan utama dari semua laporan ini - layanan microser membantu untuk menjauh dari kompleksitas dan kompleksitas proyek yang berlebihan. Tetapi, bagi saya, Anda tidak bisa menghilangkan kompleksitas sama sekali, Anda tidak dapat membuat ulang proyek sehingga semuanya menjadi sederhana sekaligus. Kesulitan akan berpindah dari satu area ke area lain.
Misalnya: ada monolit kusut yang sangat rumit, kami membaginya menjadi beberapa layanan, masing-masing tampak hebat, siapa pun dapat mengetahui kode, tetapi apa yang terjadi pada lingkungan? Kompleksitas berkembang: ini adalah transaksi terdistribusi yang perlu dicatat untuk memahami bahwa ini adalah satu transaksi; CI / CD dan pengiriman ditambahkan untuk setiap layanan; skema interaksi menjadi non-sepele.
Tesis atau pernyataan yang paling kontroversial yang pernah saya dengar dalam laporan dan dengan siapa saya siap untuk berdebat:
Memasuki proyek monolit lebih mahal bagi anggota tim baru . Untuk beberapa alasan, biasanya untuk mengevaluasi biaya bergabung dengan proyek dengan seberapa cepat pengembang baru mulai melakukan tugas. Ya, dia akan mengatasinya dalam layanan kecil dengan sangat cepat dan mengeluarkan tugas dengan sangat cepat (terutama sesuai dengan spesifikasi, "apa yang mereka tulis, saya lakukan").
Tetapi bagaimana dengan anggota tim lainnya?
Penguji baru akan berurusan dengan model integrasi. Menguji layanan itu baik, tetapi selain menguji kontrak layanan, Anda perlu memeriksa proses bisnis yang memengaruhi beberapa layanan.
Pada awalnya, analis baru bahkan dapat mematahkan kepalanya, sampai ia memahami semua seluk-beluk tantangan internal.
Layanan microser memungkinkan Anda untuk merilis lebih sering . Layanan Microsoft lebih cepat diperbaiki, karena mereka dibagi menjadi beberapa tugas paralel yang dikembangkan dan diuji secara paralel, dan tetap hanya untuk memeriksa integrasi (tanpa memperhitungkan waktu untuk analitik).
Anda dapat melakukan ini dengan monolit juga, semuanya tergantung pada dekomposisi tugas. Paling sering, di awal akan ada satu tugas - untuk membuat fungsi umum (untuk memperbaiki database umum, atau memodifikasi antarmuka), dan kemudian semua orang akan melihat subtugas mereka dan memberikannya untuk pengujian.
Dan waktu rilis fitur yang dibayar bisnis akan sama. Fitur ini akan ditutup hanya ketika semua komponen dilepaskan. Layanan Microsoft dapat menyelesaikan 99% tugas, tetapi sampai fitur terakhir ditutup, tugas tersebut tidak akan dilepaskan ke pertempuran.
Apa lagi yang tidak mereka bicarakan
Kesulitan tumbuh
Saat menggunakan layanan mikro,
infrastrukturnya rumit . Hal ini disebabkan oleh fakta bahwa Anda perlu mendukung pekerjaan tidak hanya satu aplikasi, tetapi banyak layanan. Penting untuk memantau kinerja semua layanan, untuk memahami dengan baik dependensi layanan menurut versi, untuk memiliki rencana CI / CD untuk merakit layanan dan pengiriman, mekanisme untuk menanggapi kegagalan layanan, sehingga segala sesuatu yang lain tidak turun.
Tampaknya hal-hal sederhana, dan dalam monolit kita harus melakukan hal yang sama. Hanya di monolith kami bekerja pada satu aplikasi, dan dengan meningkatnya jumlah layanan, kompleksitas bertambah, yang membutuhkan keterampilan yang lebih tinggi untuk didukung.
Layanan Microsoft menambah kompleksitas - perpustakaan baru, fungsionalitas baru untuk mendukung transaksi terdistribusi, untuk menangani kesalahan layanan lain, mengirim permintaan berulang, memutar kembali transaksi. Sebagian besar, mekanisme ini akan umum, dan sebagian besar pengembang tidak akan masuk ke nyali, tetapi hanya akan menggunakannya.
Tetapi mungkin ada kesalahan di dalamnya yang harus diperbaiki. Jika kami mengatasi perbaikan tanpa masalah, maka untuk meluncurkan perubahan ke 200-300 layanan, itu akan memakan waktu dan mengembangkan kontrol. Dan jika Anda perlu membangun kembali layanan dengan perpustakaan yang diperbarui, atau bahkan mengulang panggilan (mereka memperbaikinya, tidak menyediakannya), maka semua ini tidak akan menyenangkan.
Monolith - bukan bola lumpur yang besar
Bagaimana kisah-kisah tentang dunia indah layanan-mikro biasanya dimulai? "Kami memiliki monolit, itu adalah benjolan tanah yang padat, di mana semuanya membingungkan dan tidak bisa dipahami," ditambah mereka akan menunjukkan gambar yang mengerikan. Dan monolit telah menjadi sesuatu yang menakutkan, "Anda akan bekerja dengan buruk, proyek Anda akan berubah menjadi monolit."
Tapi tidak.Monolith dapat (dan harus) jelas, terstruktur, dengan kode 'baik', dengan dokumentasi, sama seperti proyek layanan-mikro dapat berubah menjadi bola kotoran yang bahkan lebih besar jika Anda tidak terlibat dalam proses pengembangan dan tidak memantau kualitas pengembangan.
Jadi apa yang harus digunakan?
Pertanyaan bagus, dan hanya Anda yang bisa menjawab. Karena hanya Anda yang tahu masalah bisnis apa yang Anda putuskan, apa proyeknya. Tidak ada peluru perak, tidak ada arsitektur ideal yang dapat digunakan dan akan selalu ada "kebahagiaan".
Dan di monolit, dan dalam layanan mikro, ikuti dokumentasi dan tetap perbarui. Dengan dokumentasi lebih baik daripada tanpa itu.
Membangun proses pengembangan di mana kualitas kode hanya akan tumbuh (review, unit test). Namun soal kualitas Anda dapat menulis seluruh buku, ini adalah topik untuk percakapan besar yang terpisah.
Kode sederhana dan dapat dimengerti bukan tentang layanan mikro, kode harus seperti itu secara apriori.
Otomatisasi uji juga tentang kualitas kode.
Otomatiskan semua yang Anda bisa otomatiskan - CI / CD. Mungkin ada tumpukan teknologi yang sangat sulit untuk ditarik ke CI / CD, tetapi 99% dari rakitan / pengiriman bisa otomatis.