Tampaknya puncak popularitas layanan mikro sudah berlalu. Kami tidak lagi membaca postingan beberapa kali seminggu “Bagaimana saya memindahkan monolit saya ke 150 layanan.” Sekarang saya mendengar lebih banyak pemikiran yang masuk akal: “Saya tidak membenci monolit, saya hanya peduli pada efisiensi.” Kami bahkan mengamati beberapa migrasi . Saat berpindah dari satu aplikasi besar ke beberapa layanan kecil, Anda harus menyelesaikan beberapa masalah baru. Mari kita daftarkan mereka sesingkat mungkin.
Setting: dari kimia dasar hingga mekanika kuantum
Menyiapkan database dasar dan aplikasi dengan proses latar belakang adalah proses yang cukup mudah. Saya menerbitkan readme di Github - dan seringkali setelah satu jam, paling lama beberapa jam, semuanya berfungsi, dan saya memulai proyek baru. Menambah dan menjalankan kode, setidaknya untuk lingkungan awal, dilakukan pada hari pertama. Namun jika kita terjun ke layanan mikro, waktu peluncuran awal akan meroket. Ya, sekarang kami memiliki Docker dengan orkestrasi dan sekelompok mesin K8, tetapi bagi programmer pemula, semua ini jauh lebih rumit. Bagi banyak junior, ini adalah beban yang sebenarnya merupakan komplikasi yang tidak perlu.
Sistemnya tidak mudah dimengerti
Mari kita fokus pada junior kita sejenak. Dengan aplikasi monolitik, jika terjadi kesalahan, mudah untuk melacaknya dan segera melanjutkan ke debugging. Sekarang kita mempunyai layanan yang sedang berbicara dengan layanan lain yang sedang mengantri sesuatu di bus pesan yang sedang memproses layanan lain - dan kemudian terjadi kesalahan. Kita harus menggabungkan semua bagian ini untuk akhirnya mengetahui bahwa Layanan A menjalankan versi 11, dan Layanan E sudah menunggu versi 12. Ini sangat berbeda dari log konsolidasi standar saya: harus menggunakan terminal interaktif/debugger untuk berjalan melalui proses langkah demi langkah. Debugging dan pemahaman secara inheren menjadi lebih sulit.
Jika tidak bisa di-debug, mungkin kami akan mengujinya
Integrasi berkelanjutan dan pembangunan berkelanjutan kini menjadi hal yang lumrah. Sebagian besar aplikasi baru yang saya lihat secara otomatis membuat dan menjalankan pengujian pada setiap rilis baru dan memerlukan pengujian untuk dilakukan dan ditinjau sebelum pendaftaran. Ini adalah proses hebat yang tidak boleh ditinggalkan dan telah menjadi perubahan besar bagi banyak perusahaan. Namun sekarang, untuk benar-benar menguji layanan ini, saya harus menjalankan versi aplikasi saya yang berfungsi penuh. Ingat insinyur baru dengan cluster K8 yang terdiri dari 150 layanan? Nah, sekarang kami akan mengajarkan sistem CI kami cara memunculkan semua sistem ini untuk memverifikasi bahwa semuanya benar-benar berfungsi. Ini mungkin membutuhkan banyak usaha, jadi kami hanya akan menguji setiap bagian secara terpisah: Saya yakin spesifikasi kami cukup baik, API bersih, dan kegagalan layanan diisolasi dan tidak akan memengaruhi yang lain.
Semua kompromi mempunyai alasan yang kuat. Benar?
Ada banyak alasan untuk beralih ke layanan mikro. Saya telah melihat hal ini dilakukan demi fleksibilitas yang lebih besar, untuk meningkatkan skala tim, demi kinerja, untuk memberikan keberlanjutan yang lebih baik. Namun kenyataannya, kami telah menginvestasikan waktu puluhan tahun pada alat dan praktik untuk mengembangkan monolit yang terus berkembang. Saya bekerja dengan para profesional di berbagai teknologi. Kami biasanya berbicara tentang penskalaan karena penskalaan tersebut mencapai batas satu node database Postgres. Kebanyakan pembicaraannya tentang .
Tapi saya selalu tertarik mempelajari arsitektur mereka. Pada tahap transisi ke layanan mikro apa mereka berada? Sangat menarik untuk melihat lebih banyak insinyur yang mengatakan bahwa mereka senang dengan aplikasi monolitik mereka. Banyak orang akan mendapatkan manfaat dari layanan mikro, dan manfaatnya akan lebih besar daripada hambatan yang ada pada jalur migrasi. Tapi secara pribadi, tolong beri saya aplikasi monolitik saya, tempat di pantai - dan saya sangat senang.
Sumber: www.habr.com