Migrasi Monolith ke Microservices

PERTEMUAN KE 10
Dr. Ir. Toto Widyanto, MSc.
23 Juli 2022
 Latar Belakang
• Pada survei tahun 2018 ditemukan ada 63 persen perusahaan mengadopsi arsitektur
Microservices.
• Adopsi yang meluas ini didorong oleh janji perbaikan ketahanan, skalabilitas, waktu ke
pasar, dan pemeliharaan, di antara alasan lainnya.
• Di sini akan dijelaskan rencana tentang bagaimana organisasi yang ingin memigrasikan
aplikasi yang ada ke Microservices dapat melakukannya dengan aman dan efektif.
• Pada suatu aplikasi monolitik, semua obyek dan Aksi data ditangani oleh basis kode
rajut tunggal yang erat.
• Data biasanya disimpan dalam bentuk database tunggal atau sistem file.
• Fungsi dan metode dikembangkan untuk mengakses data langsung dari mekanisme
penyimpanan ini, dan semua logika bisnis terkandung dalam basis kode server dan
aplikasi klien.
Dr. Toto Widyanto 2
https://insights.sei.cmu.edu/blog/8-steps-for-migrating-existing-applications-to-microservices/
 Latar Belakang
• Dimungkinkan untuk memigrasikan beberapa aplikasi monolitik dan /
atau platform, masing-masing dengan mekanisme penyimpanan data
sendiri, antarmuka pengguna, dan skema data, ke dalam serangkaian
Microservices terpadu yang melakukan fungsi yang sama dengan
aplikasi asli di bawah satu antarmuka pengguna.
• Migrasi aplikasi ini ke Microservices menawarkan keuntungan berikut:
• menghapus duplikasi upaya untuk entri manual
• mengurangi risiko pengembangan terprogram
• menyediakan satu tampilan terpadu data
• meningkatkan kontrol dan sinkronisasi sistem ini

Dr. Toto Widyanto 3

https://insights.sei.cmu.edu/blog/8-steps-for-migrating-existing-applications-to-microservices/
 Pola Arsitektur Perangkat Lunak

Sebelum pembahasan proses migrasi dari sistem monolitik menuju

Microservices, beberapa deskripsi pola arsitektur perangkat lunak yang
relevan akan dibahas di sini.

Dr. Toto Widyanto 4

 Monolitik
• Banyak aplikasi warisan saat ini diimplementasikan sebagai monolit, di
mana semua penyimpanan dan pemrosesan data dikendalikan oleh
monolit, dan semua fungsi untuk semua objek data diproses
menggunakan basis kode backend yang sama.
• Meskipun metode pengembangan ini khas secara historis, itu dapat
menyebabkan masalah keberlanjutan:
• Memperbarui kode untuk satu set objek data dapat merusak dependensi di
area lain.
• Penskalaan sistem bisa sulit karena hubungan data yang terjalin.
• Menyediakan beberapa cara untuk menemukan, memperbarui, dan
mengakses data secara terprogram bisa menjadi tantangan.
Dr. Toto Widyanto 5
 Microservices
• Pola pengembangan perangkat lunak Microservices menyediakan metode untuk membangun layanan terpadu
tunggal dari koleksi layanan yang lebih kecil.
• Setiap komponen Microservices berfokus pada serangkaian Aksi yang digabungkan secara longgar pada set data
kecil yang terdefinisi dengan baik.
• Setiap Microservices mencakup sistem penyimpanan independen sehingga semua datanya terletak di satu lokasi.
• Dengan mengurangi jumlah operasi pemblokiran pada backend penyimpanan data, arsitektur ini memungkinkan
Microservices untuk menskalakan secara horizontal, meningkatkan kapasitas dengan menambahkan lebih banyak
node ke sistem daripada hanya meningkatkan sumber daya (RAM, CPU, penyimpanan) pada satu node.
• Microservices dapat ditulis dalam bahasa pemrograman apa pun dan dapat menggunakan database, perangkat
keras, dan lingkungan perangkat lunak mana pun yang paling masuk akal bagi organisasi. Antarmuka
pemrograman aplikasi (API) menyediakan satu-satunya cara bagi pengguna dan layanan lain untuk mengakses
data Microservices.
• API tidak perlu dalam format tertentu, tetapi transfer status representasional (REST) populer, sebagian karena
keterbacaan manusia dan sifat stateless membuatnya berguna untuk antarmuka web.
• Format API umum lainnya termasuk gRPC dan GraphQL, yang masing-masing memiliki pendekatan dan tradeoff
yang berbeda untuk bagaimana data diakses.

Dr. Toto Widyanto 6

 Lokalitas Data
• Meskipun setiap Microservices mempertahankan datastore sendiri, data tidak perlu disimpan pada satu disk pada
satu mesin.
• Yang penting adalah bahwa satu-satunya metode bagi sistem dan pengguna untuk mengakses data adalah melalui
API.
• Mekanisme penyimpanan yang mendasarinya mungkin berupa satu disk, atau mungkin klaster terdistribusi dan
ketersediaan tinggi yang dicerminkan melalui replikasi data dan beberapa bentuk mekanisme kuorum.
• Rincian implementasi terserah pemilik sistem dan harus mencerminkan kebutuhan sistem berdasarkan penggunaan
yang diharapkan.
• Demikian pula, tidak ada persyaratan bahwa lokasi penyimpanan data untuk setiap Microservices berada di host
terpisah.
• Pola Microservices hanya berfokus pada data yang langsung membaca set datanya sendiri.
• Karena tidak mengakses kumpulan data lainnya, tidak masalah apakah ada kumpulan data co-located lainnya pada
sistem penyimpanan data yang sama.
• Sekali lagi, pemilik sistem harus menimbang manfaat biaya dan pemeliharaan dari co-locating data dengan risiko
yang terkait dengan mempertahankan satu titik kegagalan untuk data mereka.
• Mekanisme dan proses yang mendasari untuk menyimpan, mencadangkan, dan memulihkan data untuk sistem
monolitik, Macroservices sementara, dan Microservices akhir tetap menjadi hak prerogatif pemilik sistem.
Dr. Toto Widyanto 7
 Migrasi dari Monolith ke Microservices
• Skalabilitas adalah salah satu motivasi utama untuk pindah ke arsitektur
Microservices.
• Selain itu, efek skalabilitas pada komponen yang jarang digunakan dapat diabaikan.
• Komponen yang digunakan oleh sebagian besar pengguna oleh karena itu harus
dipertimbangkan untuk migrasi terlebih dahulu.
• Pengguna ingin interaksi mereka dengan sistem untuk mengembalikan data yang
tepat pada tingkat detail yang tepat, biasanya secepat data tersebut dapat
diperoleh.
• Pekerjaan untuk pengguna masing-masing melibatkan satu atau beberapa objek
data, dan setiap objek data memiliki serangkaian Aksi terkait yang dapat dilakukan.
• Tim pengembangan yang merancang dan mengimplementasikan sistem harus
mempertimbangkan pengumpulan pekerjaan, objek data, dan Aksi data.
Dr. Toto Widyanto 8
 Migrasi dari Monolith ke Microservices
Proses khas untuk bermigrasi dari sistem monolitik ke sistem berbasis Microservices
melibatkan langkah-langkah berikut:

6. Melakukan migrasi grup komponen ke

1. Identifikasi komponen logika.
makroservice (pindahkan grup komponen untuk
memisahkan proyek dan membuat penyebaran
terpisah).
2. Rampingkan dan refaktor komponen.

7. Migrasikan Macroservices ke
3. Identifikasi dependensi komponen.
Microservices.

4. Identifikasi grup komponen.

8. Ulangi langkah 6-7 hingga selesai.

5. Buat API untuk antarmuka pengguna jarak
jauh.

Dr. Toto Widyanto 9

 Migrasi dari Monolith ke Microservices
• Di sini ada tiga hal yang perlu dibahas lebih lanjut:
 (1) komponen,(2) antarmuka pengguna jarak jauh, dan (3) makroservices.
• Dalam proses ini, pengembang melakukan langkah 1-5 sekali di awal proyek migrasi.
• Tim dapat mengunjungi kembali langkah-langkah ini saat proses dimigrasikan atau ketika informasi baru
tersedia selama proses migrasi, tetapi setelah langkah-langkah selesai, seharusnya tidak perlu
mengunjunginya kembali.
• Langkah 6 adalah langkah sementara yang mungkin tidak diperlukan untuk beberapa proyek.
• Jika Macroservices tidak diperlukan, pengembang dapat melewati langkah 6; langkah 7 kemudian
menjadi, "Migrasi kelompok komponen ke Microservices."
• Demikian juga, pengembang dapat melewati langkah 7 atau iterasi tertentu jika migrasi dari
makroservice ke Microservices muncul terlalu keras atau jika transisi makroservice memadai dengan
sendirinya.
• Langkah 8 ada karena pengembang tidak perlu melakukan seluruh migrasi sekaligus.
• Mereka dapat menarik komponen dari monolit warisan dan membuatnya menjadi Microservices, baik
secara bernyanyi atau berkelompok sebagaimana waran pengembangan.
Dr. Toto Widyanto 10
 Komponen dan Grup Komponen
• Komponen adalah kumpulan objek data logis dan Aksi yang dilakukan
sistem pada objek tersebut.
• Aksi yang dilakukan pada objek data biasanya dikodekan dalam fungsi
dan metode perangkat lunak, dan fungsi dan metode ini biasanya
disimpan dalam software library.
• Grup komponen kira-kira sesuai dengan software library, tetapi
proses migrasi dapat mengatur ulang konten software library yang
ada untuk memenuhi tujuan migrasi.

Dr. Toto Widyanto 11

 Macroservices
• Macroservices mirip dengan Microservices dengan dua perbedaan utama.
1. Macroservices dapat berbagi datastore dengan sistem monolitik warisan atau Macroservices
lainnya.
2. Tidak seperti Microservices, Macroservices dapat memberikan akses ke beberapa objek data dan
pekerjaan yang harus dilakukan.
• Karena perbedaan ini dari Microservices, Macroservices mungkin mengalami masalah
yang sama dengan sistem monolitik mengenai skalabilitas dan keberlanjutan.
• Namun, karena mereka biasanya berfokus pada lebih sedikit objek data dan interaksi
dibandingkan sistem monolitik asli, mereka dapat menjadi langkah sementara yang
berguna selama proses migrasi.
• Dimungkinkan juga untuk mewujudkan beberapa manfaat dari berkurangnya
kompleksitas sementara arsitek menentukan cara terbaik untuk menguraikan
interkoneksi yang tersisa.

Dr. Toto Widyanto 12

 Proksi/Fasad API
• Proxy antarmuka pemrograman aplikasi (API – application programming interface) adalah
mekanisme di mana semua aliran data ke layanan yang mendasarinya harus melintasi.
• API ini digunakan oleh antarmuka pengguna dan sistem backend.
• Selama migrasi, sistem monolitik harus dimodifikasi sehingga komponen yang telah dimigrasikan
(baik ke Macroservices atau Microservices) menggunakan API untuk mengakses data yang
dimigrasikan.
• Sistem monolitik juga harus dimodifikasi sehingga proxy API dapat berkomunikasi dengan sistem
lama untuk melakukan Aksi yang belum dimigrasikan.
• Proxy API kemudian dapat digunakan untuk mengakses data apakah dapat diakses melalui layanan
monolitik, Microservices, atau Macroservices sementara.
• Hanya satu Microservices yang dimigrasikan yang diizinkan untuk mengakses data secara langsung.
• Semua pengguna lain dari data tersebut harus menggunakan API untuk akses.
• Ketika migrasi selesai, API tetap satu-satunya cara untuk mengakses data.

Dr. Toto Widyanto 13

 Proksi/Fasad API
• Idealnya, Macroservices akan memiliki akses eksklusif yang sama ke pusat
datanya untuk semua informasi yang relevan, tetapi kadang-kadang mungkin
perlu mengakses toko data aplikasi monolitik warisan atau macroservices lain.
• Namun, jika macroservices termasuk datastore yang terpisah dari aplikasi
monolitik warisan, monolit itu seharusnya tidak dapat mengakses datastore
macroservices secara langsung; monolit harus selalu menggunakan API untuk
data tersebut.
• Proxy API ini kadang-kadang disebut sebagai fasad karena menyamar sebagai
Microservices aktual yang ada di belakangnya.
• Setelah layanan yang mendasarinya dimigrasikan dan dapat merespons
panggilan API secara langsung, proxy API dapat dihapus.

Dr. Toto Widyanto 14

Contoh SIAKAD

Dilakukan
pemeriksaan login
siapa:
Admin?
Dosen?
Mahasiswa?

Dr. Toto Widyanto 15

Contoh SIAKAD Beranda untuk DOSEN

Dr. Toto Widyanto 16

Contoh SIAKAD

Dr. Toto Widyanto 17

Contoh SIAKAD

Dr. Toto Widyanto 18

 8 Langkah Migrasi dari Monolith ke Microservices
Proses khas untuk bermigrasi dari sistem monolitik ke sistem berbasis Microservices
melibatkan langkah-langkah berikut:

6. Melakukan migrasi grup komponen ke

1. Identifikasi komponen logika.
makroservice (pindahkan grup komponen untuk
memisahkan proyek dan membuat penyebaran
terpisah).
2. Rampingkan dan refaktor komponen.

7. Migrasikan Macroservices ke
3. Identifikasi dependensi komponen.
Microservices.

4. Identifikasi grup komponen.

8. Ulangi langkah 6-7 hingga selesai.

5. Buat API untuk antarmuka pengguna jarak
jauh.

Dr. Toto Widyanto 19

MVC atau MVP?

Dr. Toto Widyanto 20

 1. Identifikasi Komponen Logis
Ada tiga komponen informasi utama dengan data yang digunakan dalam sistem:
(1) objek data, (2) Aksi data, (3) pekerjaan untuk melakukan dan contoh kasus
1. Objek data
• Objek data adalah konstruksi logis yang mewakili data yang digunakan.
2. Aksi data
• Aksi data adalah perintah yang digunakan pada satu atau beberapa objek data, mungkin
pada berbagai tipe data, untuk melakukan tugas.
3. Pekerjaan untuk melakukan dan contoh kasus
• Tugas yang harus dilakukan mewakili fungsi yang dilakukan pengguna untuk memenuhi
peran organisasi mereka.
• Tugas yang harus dilakukan dapat ditangkap sebagai kasus penggunaan (use case), cerita
pengguna (user stories), atau dokumentasi lain yang melibatkan input pengguna.

Dr. Toto Widyanto 21

1. Identifikasi Komponen Logis

Gambar 1. Contoh komponen logis

Dr. Toto Widyanto 22
 1. Identifikasi Komponen Logis
• Saat menggabungkan beberapa sistem ke dalam sistem terpadu, objek data, Aksi data, dan
pekerjaan yang harus dilakukan untuk setiap sistem harus diidentifikasi.
• Semua komponen ini diimplementasikan sebagai modul dalam basis kode dengan satu atau
beberapa modul yang mewakili setiap objek data, Aksi data, dan pekerjaan yang harus dilakukan.
• Modul ini harus dikelompokkan ke dalam kategori untuk bekerja dengan langkah-langkah
selanjutnya.
• Pengelompokan ini ditunjukkan dengan pengkodean warna pada Gambar 1.
• Arsitek sistem mungkin merasa paling mudah untuk mengidentifikasi objek data yang digunakan
dalam sistem.
• Bekerja dari kumpulan data ini, mereka kemudian dapat menentukan Aksi data dan memetakan
ini ke pekerjaan yang akan dilakukan oleh pengguna sistem.
• Basis kode biasanya berpusat pada objek, dan setiap objek kode dikaitkan dengan fungsi dan
pekerjaan yang harus dilakukan.

Dr. Toto Widyanto 23

 1. Identifikasi Komponen Logis
• Selama bagian proses migrasi ini, arsitek sistem harus mengajukan pertanyaan
berikut:
• Jika dua aplikasi atau lebih menyediakan data serupa, dapatkah data ini digabungkan?
• Apa yang harus dilakukan tentang bidang data yang berbeda atau hilang di objek serupa?
• Migrasi dari sistem monolitik ke Microservices biasanya tidak mempengaruhi
antarmuka pengguna secara langsung.
• Komponen yang terbaik untuk migrasi ditentukan antara lain oleh komponen
yang:
• digunakan oleh pengguna terbanyak
• digunakan oleh yang paling sering
• memiliki dependensi terkecil pada komponen lain
• berjalannya terlalu lambat

Dr. Toto Widyanto 24

 2. Rampingkan dan Faktor Ulang Komponen
• Setelah semua modul diidentifikasi dan • Mungkin juga muncul di mana ada kode
dikelompokkan secara unik, sekarang warisan (mungkin mati) yang termasuk
saatnya untuk mengatur grup secara dalam satu aplikasi.
internal. • Menggabungkan fungsi dan data duplikat
• Komponen yang menduplikasi akan memerlukan pertimbangan yang sama
fungsionalitas harus ditangani sebelum seperti ketika merancang menelan set data
mengimplementasikan Microservices. baru:
• Dalam sistem akhir, seharusnya hanya ada 1. Periksa format data.
satu Microservices yang melakukan fungsi 2. Verifikasi tipe data.
tertentu. 3. Verifikasi akurasi data.
4. Verifikasi unit data.
• Duplikasi fungsi kemungkinan besar akan
5. Identifikasi outlier.
ditemui ketika ada beberapa aplikasi
6. Berurusan dengan bidang atau nilai yang
monolitik yang digabungkan. hilang.

Dr. Toto Widyanto 25

 2. Rampingkan dan Faktor Ulang Komponen
• Karena salah satu efek dari migrasi ini adalah memiliki repositori data
tunggal untuk setiap bagian data, data apa pun yang direplikasi di beberapa
lokasi harus diperiksa di sini, dan representasi akhir harus ditentukan.
• Data yang sama dapat diwakili secara berbeda tergantung pada pekerjaan
yang harus dilakukan.
• Ada kemungkinan juga bahwa data serupa dapat diperoleh dari beberapa
lokasi, atau bahwa data mungkin merupakan kombinasi dari beberapa
sumber data.
• Apa pun sumbernya dan bagaimanapun data akan digunakan, sangat
penting bahwa satu representasi akhir ada untuk setiap tipe data yang unik.

Dr. Toto Widyanto 26

 3. Identifikasi Ketergantungan Komponen
• Setelah komponen diidentifikasi dan ditata ulang untuk
mempersiapkan migrasi, arsitek sistem harus mengidentifikasi
dependensi antara komponen.
• Aktivitas ini dapat dilakukan menggunakan analisis statis kode sumber
untuk mencari panggilan antara pustaka dan tipe data yang berbeda.
• Ada juga beberapa alat analisis dinamis yang dapat menganalisis pola
penggunaan aplikasi selama eksekusinya untuk menyediakan peta
otomatis antar komponen.
• Gambar 2 di bawah ini menunjukkan contoh peta dependensi
komponen.
Dr. Toto Widyanto 27
3. Identifikasi Ketergantungan Komponen

Gambar 2. Identifikasi Ketergantungan Komponen

Dr. Toto Widyanto 28
 4. Identifikasi Grup Komponen
• Setelah dependensi diidentifikasi, arsitek sistem harus fokus pada
pengelompokan komponen menjadi kelompok kohesif yang dapat
diubah menjadi Microservices, atau, setidaknya, Macroservices.
• Perbedaan antara Macroservices dan Microservices pada saat ini tidak
penting.
• Tujuannya adalah untuk mengidentifikasi seperangkat kecil objek dan
tindakan konstituen mereka yang harus dipisahkan secara logis dalam
sistem akhir.

Dr. Toto Widyanto 29

4. Identifikasi Grup Komponen

Gambar 3. Identifikasi Grup Komponen

Dr. Toto Widyanto 30

 5. Buat API untuk Antarmuka Pengguna Jarak Jauh
• Antarmuka pengguna jarak jauh dimaksudkan sebagai yang ada tidak akan berubah secara signifikan.
mode komunikasi tunggal antara sistem, komponennya, • Sebaliknya, itu harus memungkinkan penambahan objek,
dan pengguna sistem. atribut, dan tindakan baru karena diidentifikasi dan
• Sangat penting bahwa antarmuka ini dapat diskalakan dan disediakan.
direncanakan dengan baik untuk menghindari masalah saat• Setelah lapisan API diberlakukan, semua fungsi baru harus
sistem berkembang dari waktu ke waktu. ditambahkan melalui API, bukan melalui aplikasi lama.
• Antarmuka yang mendasarinya harus dapat digunakan baik • Desain dan implementasi API adalah kunci keberhasilan
selama migrasi dan sesudahnya, sehingga kemungkinan migrasi ke Microservices.
berubah karena komponen dikerjakan ulang dari sistem
• API harus dapat menangani semua kasus akses data yang
monolitik ke layanan makro dan Microservices.
didukung oleh aplikasi yang akan menggunakan API. Sesuai
• Output utama dari upaya migrasi ini adalah API terpadu dengan praktik standar penomor kontrol versi perangkat
yang dapat digunakan oleh antarmuka pengguna dan lunak, perubahan pada API yang memecah kompatibilitas
aplikasi untuk memanipulasi data. mundur dengan versi yang lebih lama harus memicu
• Segala sesuatu yang lain tergantung pada API ini, sehingga perubahan nomor revisi "utama" untuk API.
harus direkayasa untuk memastikan bahwa interaksi data

Dr. Toto Widyanto 31

 5. Buat API untuk Antarmuka Pengguna Jarak Jauh
• Perubahan pada API yang memecah • Agar Microservices berfungsi dengan baik,
kompatibilitas mundur harus jarang dan semua akses data harus disediakan melalui API
direncanakan sebelumnya untuk mencegah ke Microservices atau, selama periode transisi
masalah penyebaran berulang. migrasi, ke Macroservices atau aplikasi warisan.
• API harus menyediakan mekanisme sehingga • Untuk memaksimalkan skalabilitas sistem akhir,
aplikasi dapat memeriksa versi API yang API harus
digunakan dan memperingatkan pengguna dan • stateless
pengembang tentang ketidakcocokan. • mampu menangani semua objek data yang
• Satu-satunya perubahan pada API adalah dinyatakan dalam sistem
• kompatibel mundur dengan versi sebelumnya
perubahan yang menambahkan objek dan
• Memiliki versi
fungsi data baru dan yang tidak mengubah
format output yang ada atau input yang • Meskipun REST API khas, itu tidak sepenuhnya
diharapkan. diamanatkan untuk Microservices.

Dr. Toto Widyanto 32

 6. Migrasi Grup Komponen ke Macroservices
• Macroservices memiliki postur yang lebih santai untuk berbagi repositori data dan
memungkinkan interaksi yang lebih kompleks dengan objek data.
• Oleh karena itu mungkin berguna untuk mempertimbangkan penggunaannya sebagai langkah
sementara menuju migrasi ke Microservices penuh.
• Alasan utama untuk tidak bergerak langsung ke Microservices adalah kompleksitas.
• Sistem monolitik biasanya dibangun dengan logika terjalin yang dapat menyebabkan masalah
saat dikonversi ke Microservices.
• Jika monolit terus berubah, maka migrasi ke Microservices dalam satu langkah akan menjadi
target yang terus berubah juga.
• Tujuan utama pada langkah ini adalah untuk memindahkan grup komponen ke proyek
terpisah dan membuat penyebaran terpisah.
• Minimal, setiap Macroservices harus dapat digunakan secara independen dari dalam saluran
continuous integration (CI) dan continuous deployment (CD) sistem.
Dr. Toto Widyanto 33
6. Migrasi Grup Komponen ke Macroservices

Gambar 4. Migrasi Grup Komponen ke Macroservices

Dr. Toto Widyanto 34

 7. Migrasi Macroservices ke Microservices
• Proses menarik komponen, objek data, dan fungsi keluar dari sistem
monolitik dan ke dalam Macroservices akan memberikan wawasan
tentang bagaimana komponen-komponen ini dapat dipisahkan lebih
lanjut menjadi Microservices.
• Ingat, setiap Microservices mempertahankan datastore sendiri dan
hanya melakukan serangkaian tindakan kecil pada objek data dalam
datastore tersebut.

Dr. Toto Widyanto 35

7. Migrasi Macroservices ke Microservices

Gambar 5. Migrasi Macroservices ke Microservices

Dr. Toto Widyanto 36

7. Migrasi Macroservices ke Microservices

Gambar 6. Hasil Akhir: Aplikasi Sepenuhnya Dikonversi ke Microservices

Dr. Toto Widyanto 37
 8. Penyebaran dan Pengujian
• Setelah Macroservices atau Microservices siap untuk yang masih berusaha menggunakan datastore lama
penyebaran, langkah berikutnya melibatkan
pengujian dan penyebaran integrasi.
• Sistem monolitik harus dikonfigurasi untuk
menggunakan layanan baru untuk kebutuhan
datanya daripada datastore warisannya.
• Menemukan semua panggilan ke toko data dari
dalam sistem monolitik warisan bisa sulit.
• Dalam lingkungan pengujian, harus dimungkinkan
untuk menghapus data warisan yang terkait dengan
kumpulan data yang dimigrasikan yang sekarang
bertanggung jawab oleh Microservices baru.
• Semua fungsi yang mengakses data yang
dimigrasikan harus diuji di semua antarmuka
pengguna untuk memastikan bahwa tidak ada fungsi
Dr. Toto Widyanto
melalui metode yang sebelumnya tidak terdeteksi.
• Jika memungkinkan, akses ke set data lama di
datastore lama harus dicatat dan ditandai jika kode
lama atau direfaktor masih dapat mengakses data
lama. Kontrol akses harus diperbarui untuk
mencegah pengguna mengakses data lama langsung
dari toko data; pengguna dapat diberi tahu cara
mengakses data menggunakan antarmuka API baru
jika akses langsung tersebut diizinkan.
• Setelah pengujian menunjukkan bahwa kode
monolitik yang tersisa mengakses layanan baru
untuk informasinya dan bahwa tampaknya tidak ada
koneksi yang tersisa dengan datastore lama, layanan
baru dapat digunakan ke sistem produksi.
38
 Konsolidasi Beberapa Layanan
• Ketika proses ini digunakan untuk
mengkonsolidasikan beberapa layanan daripada
hanya memigrasikan satu sistem warisan, mungkin
ada satu atau lebih contoh di mana data yang sama
atau serupa disimpan oleh lebih dari satu sistem
warisan.
• Konsolidasi ini menimbulkan masalah bagaimana
menangani data selama periode migrasi.
• Pada akhir migrasi, data ini harus disimpan sebagai
satu atau lebih Microservices dan diakses melalui
API oleh semua komponen yang ingin menggunakan untuk menulis data ke beberapa toko data secara
data tersebut.
• Idealnya, sebagai bagian dari Komponen Langkah 2,
Perampingan dan Faktor Ulang, sistem otoritatif
tunggal harus diidentifikasi untuk menangani data
dan semua aliran data akan dikonfigurasi untuk
Dr. Toto Widyanto
menggunakan sistem tunggal ini.
• API akan menunjuk ke sistem ini, dan aplikasi lama
akan dikonfigurasi untuk menggunakan API untuk
mengakses data ini di lokasi otoritatifnya.
• API harus selalu membaca data dari satu lokasi
otoritatif.
• Idealnya, data ini harus selalu menulis data ke satu
lokasi otoritatif juga.
• Namun, macroservice sementara dapat dikonfigurasi
bersamaan, mungkin termasuk datastore untuk
sistem monolitik warisan.
• Pada titik tertentu sebelum proses migrasi selesai,
beberapa tulisan harus dihapus sehingga hanya satu
datastore yang berisi data yang relevan.
39
 Kesimpulan
• Rencana migrasi aplikasi yang ada ke Microservices ini dimaksudkan
untuk memungkinkan organisasi mewujudkan manfaat arsitektur
Microservices, seperti ketahanan, skalabilitas, peningkatan waktu ke
pasar, dan pemeliharaan yang lebih mudah, dengan efisiensi
maksimum dan gangguan minimal terhadap aplikasi dan layanan yang
ada.

Dr. Toto Widyanto 40

Dr. Toto Widyanto 41