‼️ 🍠 👼 Biaya tersembunyi untuk beralih ke layanan mikro 🎍 🛬 ❄️

Dalam dunia yang ideal, seseorang dapat dengan mudah mengambil kode sumber dari sebuah monolit, membagi kodenya di antara layanan mikro dan, dengan menghubungkannya bersama, mendapatkan sistem yang sama, tetapi pada arsitektur yang baru. Ini tidak pernah terjadi dalam hidup. Hidup membawa banyak kerumitan pada gambaran sempurna ini. Apa saja tantangan khusus yang dapat menggandakan atau melipatgandakan anggaran migrasi layanan mikro Anda?

Saya akan menjelaskan faktor-faktor yang menunda transisi ke layanan mikro dan membuatnya jauh lebih mahal dari yang diharapkan. Anda akan menerima daftar periksa untuk mengevaluasi faktor-faktor ini dan akan lebih realistis tentang anggaran transisi Anda.

Saya berbicara dengan topik ini di ArchDays 2020 . Ikuti tautan untuk menemukan slide dan video (akan segera diterbitkan) pidato https://blog.byndyu.ru/2020/12/archdays-2020.html .

# 1 Mengubah pendekatan untuk bekerja dengan data master

Monolit biasanya memiliki satu atau dua database besar yang berisi data master beraneka ragam. Monolit itu sendiri berisi kode yang mengelola data master ini. Misalnya, jika bagian "hijau" dari database adalah direktori alamat, maka kode monolit "hijau" mengontrol alamat. Ternyata ada banyak data master di database monolit, dan ada banyak sistem master di kode monolit:

Di layanan mikro, data master dikelola secara berbeda: ada banyak database, Anda tidak dapat mencampur data master di antara layanan mikro, dan hanya satu layanan mikro yang dapat mengelola data master. Misalnya, layanan mikro "hijau" sekarang telah menerima database dengan alamat, dan hanya dia yang dapat membuat perubahan pada data master ini. Layanan mikro lain dapat membaca data dengan alamat, tetapi hanya melalui layanan mikro "hijau":