Tampaknya puncak hype untuk layanan mikro ada di belakang. Kami tidak lagi membaca posting “Bagaimana Saya Mentransfer Monolith Saya ke 150 Layanan” beberapa kali seminggu. Sekarang saya sering mendengar pemikiran yang masuk akal: "Saya tidak membenci monolit, saya hanya peduli pada efisiensi." Kami bahkan mengamati beberapa migrasi dari layanan microsoft kembali ke monolith . Saat berpindah dari satu aplikasi besar ke beberapa layanan yang lebih kecil, Anda harus menyelesaikan beberapa masalah baru. Kami membuat daftar mereka sesingkat mungkin.

Instalasi: dari kimia dasar ke mekanika kuantum

Menyiapkan basis data dan aplikasi dengan proses latar belakang adalah proses yang cukup jelas. Saya menerbitkan readme di Github - dan seringkali setelah satu jam, paling banyak, beberapa jam, semuanya bekerja, dan saya memulai proyek baru. Menambah dan menjalankan kode, setidaknya untuk lingkungan awal, dilakukan pada hari pertama. Tetapi jika kita berkelana ke layanan mikro, waktu peluncuran awal berangkat ke surga. Ya, sekarang kami memiliki Docker yang diatur dan sekelompok mesin K8, tetapi untuk programmer pemula, semua ini adalah urutan besarnya yang lebih rumit. Bagi banyak junior, ini adalah beban yang benar-benar tidak perlu kompleksitas.

Sistemnya tidak mudah dimengerti.

Mari kita berhenti sejenak di junior kita. Dengan aplikasi monolitik, jika terjadi kesalahan, mudah untuk melacaknya dan segera melanjutkan ke debugging. Sekarang kami memiliki layanan yang berbicara ke layanan lain yang mengantri sesuatu di bus pesan yang memproses layanan lain - dan kemudian terjadi kesalahan. Kami harus mengumpulkan semua bagian ini untuk mengetahui bahwa layanan A berjalan di versi 11, dan layanan E sudah menunggu versi 12. Ini sangat berbeda dari log konsolidasi standar saya: Anda harus menggunakan terminal interaktif / debugger untuk melalui proses langkah demi langkah. Debugging dan pengertian pada dasarnya menjadi lebih sulit.

Jika Anda tidak dapat men-debug, mungkin kami akan mengujinya

Integrasi berkelanjutan dan pengembangan berkelanjutan sekarang menjadi hal biasa. Sebagian besar aplikasi baru yang saya lihat dengan setiap rilis baru secara otomatis membuat dan menjalankan tes dan mengharuskan tes lulus dan ditinjau sebelum pendaftaran. Ini adalah proses yang sangat baik yang tidak dapat ditinggalkan, mereka telah menjadi perubahan besar bagi banyak perusahaan. Tapi sekarang, untuk benar-benar menguji layanan ini, saya harus meningkatkan versi aplikasi saya yang berfungsi penuh. Ingat insinyur baru itu dengan 150 layanan K8? Nah, sekarang kami akan mengajarkan sistem CI kami cara menaikkan semua sistem ini untuk memverifikasi bahwa semuanya benar-benar berfungsi. Ini mungkin terlalu banyak upaya, jadi kami hanya akan menguji setiap bagian secara terpisah: Saya yakin bahwa spesifikasi kami cukup baik, APInya bersih, dan kegagalan layanan terisolasi dan tidak akan memengaruhi yang lain.

Semua kompromi memiliki alasan yang bagus. Benar?

Ada banyak alasan untuk meningkatkan ke layanan microser. Saya melihat mereka melakukan ini untuk fleksibilitas yang lebih besar, untuk penskalaan perintah, untuk kinerja, untuk memberikan stabilitas yang lebih baik. Namun dalam kenyataannya, kami telah menginvestasikan puluhan tahun dalam alat dan praktik mengembangkan monolit, yang terus berkembang. Saya bekerja dengan para profesional di berbagai teknologi. Kami biasanya berbicara tentang penskalaan karena mereka dihadapkan dengan batas-batas satu simpul basis data Postgres. Sebagian besar pembicaraan tentang penskalaan basis data .

Tetapi saya selalu tertarik untuk belajar tentang arsitektur mereka. Pada tahap transisi ke layanan mikro apa mereka. Sangat menarik untuk melihat bagaimana semakin banyak insinyur mengatakan mereka senang dengan aplikasi monolitik mereka. Banyak layanan mikro akan mendapat manfaat, dan manfaatnya akan lebih besar daripada lubang di jalur migrasi. Tetapi secara pribadi, beri saya, tolong, aplikasi monolitik saya, tempat di pantai - dan saya benar-benar bahagia.