Transcript for:
Strategi Migrasi ke Microservice

Oke jadi kita bahas sekarang sebelum migrasi ke microservice jadi banyak banget ya E yang konsultasi ke saya Eh minta dijelaskan Gimana kalau mereka mau migrasi ke microservice gitu ya Nah banyak banget Ternyata setelah saya Eh ini ya korek informasinya Ternyata banyak yang belum ideal ya Jadi ya mungkin karena Hype gitu ya jadi orang pada pengin pindah ke microservice padahal mungkin kondisinya enggak ideal gitu ya jadi dan sebaiknya enggak pindah ke micros service Nah di sini saya jelasin gimana tahapannya gitu ya Jadi sebelum kita migrasi ke microservice kalau teman-teman pengin tahu apa itu microservice saya pernah buat kayak playlistnya di YouTube teman-teman bisa cari e belajar microservice di sana saya jelaskan dari awal Nah kalau teman-teman sekarang nih mau migrasi ke microservice gitu ya Nah kira-kira tahapannya seperti apa Apakah kita harus langsung ya atau ada tahapannya Oke jadi saya akan e Jelaskan sebelum teman-teman pindah ke microservice idealnya itu enggak saat saat kita bikin aplikasi ya pertama kali ya idealnya tuh enggak langsung microservice idealnya tuh dari awal biasanya Dibikin monolit dulu nah kecuali Memang teman-teman sebelumnya udah bikin monolit gitu ya terus teman-teman eh udah besar perusahaannya dan baru pindah ke microservice Oke tapi kalau teman-teman baru banget set up di awal gitu ya aplikasinya baru buat itu rata-rata biasanya kita akan mulai dari monolit dulu jadi yang pertama ya E idealnya itu adalah dia eh monolit ya Nah selanjutnya setelah monolit tahapan selanjutnya itu saya selalu sarankan optimiz optimasi ya jadi optimize optimasi dulu si monolitnya Nah setelah ini baru pindah ke tahapan yang namanya cqrs ya atau singkatan dari [Musik] command query ini singkatan ya Eh rest ponsibility segregation nanti saya jelasin Nah baru terakhir itu baru ke microservice jadi di ujung sini baru dia ke microservices nah ini tahapannya Jadi idealnya kita enggak tiba-tiba langsung ke microservice jadi saya selalu saranin bertahap jadi dari monolit dulu ya nanti setelah selesai baru ke optimasi monolitnya setelah selesai baru ke cek qrs nya Nah terakhir kalau ini UD selesai ya baru kita pindah ke microservice ee bukan selesai ya tapi Maksudnya kita dari monolit kalau misalnya udah mentok kita coba optimalin dulu monolitnya kalau udah mentok lagi baru pindah ke cek URS kalau udah mentok gitu ya baru kita ke microservice Jadi tahapannya kurang lebih ya seperti ini ya dari sini ke sini dan ini bertahap enggak tiba-tiba loncat dari monorid langsung ke microservice misalnya atau dari monolit ke cqrs gitu ya Enggak Enggak seperti ini Oke kita jelasin satu persatu ya mungkin ini videonya agak sedikit panjang ee tapi nanti saya coba persingkat Oke jadi dari awal itu ya pastikan kita kalau mau bikin aplikasi Ya udah gitu di awal itu bikinnya monolit dulu aja jadi setah itu konsepnya ada yang bilang monolit first ya jadi pokoknya di awal monolit dulu kenapa monolit ya pertanyaannya Kenapa gitu ya Eh yang pertama itu dia Simpel simpel ya dan dia juga single deployment jadi otomatis eh lebih easy ya untuk eh deployment-nya dan EE e ngapa-ngapain tuh kodenya simpel lalu gampang dibaca gitu ya Eh logiknya ya lebih tepatnya logiknya jadi kalau kita ee punya logic aplikasi itu terpusat di satu aplikasi jadi ini ya E easy to read ini kod-nya ya nah jadi monolit itu adalah versi yang paling simpel ya Dan kalau kita benar bikin kode monolitnya baik gitu ya bagus ngikutin best practice ya itu harusnya lebih gampang jadi bacanya gampang deployment-nya gampang ee nambah fitur gampang dan lain-lain gampang Nah kalau tidak pernah ada masalah di monolit aplikasi kita Saran saya sih Ya udah enggak usah diwite ke microservice buat apa gitu ya capek-capek juga padahal kan monolitnya udah e berjalan sesuai gitu ya dengan apa yang kita mau jadi kalau kita enggak butuh microservice ya enggak butuh sebenarnya banyak aplikasi yang sebenarnya enggak butuh tapi orang maksa microservice contoh yang paling simpel misalnya kita bikin aplikasi untuk misal aja untuk ee perusahaan internal contohnya buat admin atau misalnya buat orang Finance dan lain-lain gitu ya Artinya ituh sebenarnya yang dipakainya sama perusahaan sendiri penggunanya Mas penggunanya masih dikit misalnya kayak 10 orang 20 orang gitu ya dan enggak butuh spek e performat tinggi juga sebenarnya hal-hal seperti itu ya simpel kita bikin pakai monolit aja gitu ya ngapain pusing-pusing dari awal harus bikin microservice gitu ya Nah karena nanti bakal lebih kompleks lagi terutama untuk deployment maintain dan lain-lainnya jadi di awal Kalau saran saya kalau misalnya bisa langsung dari monolit Ya udah Bikinnya di monolit aja nah cuma Nanti biasanya saat kita di monolit pasti ada beberapa kendala lagi kalau misalnya aplikasinya udah besar gitu ya jadi ini ini ee kita Tandain warna hijau gitu ya Nah ini pro-nya ya Nah kita nyari sekarang ee jeleknya apa nah jeleknya ee kalau misalnya kita sudah dapat problem ee di monolitnya misal Ya misalnya apa ya Misalnya biasanya performa ya slow misalnya seperti ini rata-rata sih kalau di monel itu performanya aja sih biasanya ya problemnya tuh performanya slow nah sebenarnya banyak orang yang bikir Wah saya harus ke microservice karena aplikasi monolit saya udah berat sebenarnya enggak ada hubungannya ya monolit aplikasinya berat sama microservice bakal jadi cepat enggak ada kalau kita kodenya masih jelek juga gitu ya enggak optimal juga percuma juga Pindah ke microservice enggak ada hubungannya aplikasinya jadi cepat tetap ada tetap aja slow juga gitu ya apalagi kalau kita ee enggak ngerti cara optimasi aplikasi jadi jatuhnya bakal slow juga nah jadi anggap aja misal aja gitu ya E kenapa nih slownnya ternyata datanya udah gede gitu ya jadi di sini misalnya eh datanya udah besar ya besar banyak udah miliaran dan lain-lain jadi setiap kali query walaupun querynya sederhana misalnya tetap jatuhnya lemot misalnya seperti itu nah kalau kita udah kena problem ini Saran saya enggak tiba-tiba langsung pindah ke microservice saran saya adalah pindah ke ini ke bagian pase namanya optimasi si monolitnya jadi optimisasi aplikasi kita jadi enggak perlu reate nih tapi lebih ke optimasi kenapa enggak dari awal optimasi aja ya Dari awal kan rata-rata kita yang penting aplikasinya sesuai dulu jalan gitu ya Nah biasanya optimasi itu akan terjadi ketika nanti kita menghadapin contohnya datanya makin banyak prosesnya makin kompleks dan lain-lain Nah baru kita optimalkan oke Ada banyak cara melakukan optimasi Oke kita detailkan jadi Sudah ngerti ya Dari sini ya jadi setelah monolit kita sudah dapat problem seperti ini contohnya slow dan lain-lain Nah kita akan pindah ke tahapan optimasi si monolitnya Nah ada banyak sebenarnya yang kita bisa lakukan optimasi optimasi monolitnya nah yang pertama misalnya Ya sebenarnya sih untuk optimasi kita harus cek juga ya problemnya itu apa karena e ya kita cek problem dulu misalnya cek problem karena problem itu bisa aja ada yang EE app-nya yang lemot gitu ya atau database-nya yang lemot ya Jadi kita biasanya sih rata-rata di dua ini ya jadi aplikasinya Ah ya atau kalau misalnya kita punya integrasi dengan third party contohnya dengan logistik atau payment Gateway nah ini misalnya third party-nya yang lemot ya Nah ini kita beda juga ini cara optimasinya Oke kita bahas dari yang pertama misalnya database-nya lemot gitu ya yang sering banget kejadian Oke database-nya ini lemot nih database ini lemot apa yang terjadi kalau database lemot ya simpel sih kita harus eh database lemot misalnya ya Ada banyak yang pertama Ya tuning si e sql-nya pastikan Apakah misalnya SQL kita udah benar query-nya misalnya ya kalau join udah benar atau enggak gitu ya habis itu misalnya ya pastikan e indeksnya ada atau tidak jadi contohnya kita query ke kolom yang ternyata tidak ada indeksnya Jadi otomatis kan akan full table scan nah itu jadi bakal lemot gitu ya makin banyak datanya makin lemot atau misalnya tadinya pationnya e banyak datanya gitu ya kita ganti jadi misalnya lazy page kayak gitu nah jadi pakai e search after Nah itu juga banyak tekniknya untuk optimasi database-nya jadi baik lagi ya kita bisa Banyak teknik untuk estimasi jadi contohnya ke database nah gimana kalau aplikasinya yang lemot nah ini cek juga nih kalau misalnya aplikasinya yang lemot nih kalau aplikasinya lemot ada banyak caranya juga sebenarnya ya contohnya kalau misalnya eh app-nya lemot gitu ya lemot-nya juga kenapa gitu ya lemot-nya itu kan banyak ya Ada ternyata lemot-nya misalnya eh logicnya Kompleks gitu ya dia itu CPU eh Bond gitu ya jadi pokoknya banyak butuh kalkulasi yang berat kayak gitu nah atau misalnya ya memang di sini misalnya salah logic gitu ya atau ee logiknya terlalu panjang seperti ini Nah ini banyak juga ya contohnya kalau CPU atau logicnya Kompleks e Kompleks gitu ya kita bisa eh casing hasil e kalkulasinya misalnya jadi kalkulasi pertama kita case detailnya hasilnya Nah nanti kalkulasi yang keduanya Nah kita bisa ee ambil dari hasil yang sebelumnya juga jadi kita bisa implementen contohnya e cash gitu ya salah logic ya ini berarti fix dulu logicnya gitu ya logic terlalu panjang nah ini bisa kita perbaiki contohnya di split ya eh diplit logicnya atau bahkan di e bikin jadi asing proses jadi enggak dibikin dalam kode yang sekuensial karena mungkin terlalu lambat gitu ya Nah atau sebenarnya si database juga ini kita bisa implement case juga kalau teman-teman mau contohnya datanya memang eh berat query-nya dan enggak bisa dioptimalkan lagi ya kita implementen case juga gitu gitu oke nah terus yang third party yang lemot ada juga kan kadang-kadang Ya gimana nih aplikasi kita udah bagus tapi ternyata pas manggil payment Gateway lemot gitu ya payment gateway-nya ini aplikasi Nah kalau payment gon-nya yang lemot gimana ya itu sih enggak ada obat ya percuma juga kita mau optimalin aplikasi kita kalau ternyata third party-nya yang lemot kita enggak bisa ngapa-ngapain teknik yang rata-rata biasa dilakukan kalau misalnya third party lemot gitu ya Artinya kan kita memanggil third party-nya itu lemot nah biasanya yang dilakukan ya simpel sih kalau ini kalau ini cuma banyak orang yang melakukan cashing aja jadi ini contohnya eh third party lemot ya itu banyak orang yang melakukan cash jadi simpelnya adalah kita manggil contohnya payment gateway-nya ternyata payment gateway-nya eh pertama kali kita ambil datanya kita simpan di case dulu contohnya di memori ya lalu ketika kedua kalinya Ya udah kita Panggil dulu dari cash-nya aja nanti kalau cash-nya udah expire baru kita panggil lagi Nah untuk detail case Gimana cara mekanismenya mungkin saya enggak akan bahas di sini ya teman-teman bisa ee Googling ya nah gimana tekniknya atau saya juga pernah bikin Vlog ya E Gimana cara eh casing itu e bekerja nah Jadi intinya adalah ya setelah monolit selanjutnya ke tahapan optimasi si monolitnya ada banyak tekniknya ya dan masih banyak juga mungkin selain ini yang penting intinya masih banyak oke di beberapa kasus kadang-kadang ee e kita udah optimasi aplikasi monolitnya tapi ternyata masih tetap enggak bisa ngebantu juga contoh kasus Seperti apa Oke jadi contoh kasus seperti ini mungkin kita sering banget ya Eh bikin aplikasi bentuknya kayak gini aplikasinya misalnya lalu kan kita bikin tabel di bawahnya kayak gitu itu nanti dibagi per kolom ya tabelnya lalu di atas itu kan ada headernya header kolomnya ya kolom Misalnya ini kolom e e id eh Misalnya ini tabel ini e UI produk Ya misalnya daftar produk misalnya kayak gini nah ini kan contohnya ada di sini itu ada filter untuk ID misalnya atau eh kode gitu ya Nah ini misalnya ada filter untuk nama ini ada filter untuk misalnya price ya Nah ini ada filter lagi untuk stok Ya intinya kayak data table lah jadi Nanti orang itu bisa masukin kalau mau nyari berdasarkan kode tinggal masukin kodenya kalau orang nyari berdasarkan nama tinggal masukin namanya tapi kan bisa kombinasi antara kode dan juga nama atau Saya mau nyari nama tapi ada kombinasi dengan price juga atau Saya mau e nama dan stok jadi kombinasinya banyak Nah kalau seperti ini problemnya adalah berarti ini itu dinamis ya Jadi nanti itu e problem di sini adalah query eh yang kita buat itu dinamis sesuai dengan input user artinya Apa artinya ini enggak bisa terprediksi karena bisa aja query yang pertama dia pakai kode aja habis itu query yang kedua kode dan Price queri yang ketiga tiba-tiba dia ganti nama dan juga price atau queri yang keempat price aja atau queri yang kelima stok aja queri yang keenam stok dan nama dan terus kombinasinya tuh banyak banget bisa enggak kita bikin indeks kalau gitu Ya bisa aja sebenarnya cuma kombinasi indeksnya mau berapa ratus gitu ya kombinasinya ini baru dari empat aja jadi Oke kita kalau bikin indeks misalnya seperti ini kita ya udah deh bikin indeks berarti indeks yang pertama ee yang pertama kita bikin indeksnya itu Eh ini ya yang dari tadi itu kode aja misalnya pakai indeks kode yang kedua Eh kode koma nama indeks yang ketiga eh kode nama price gitu ya indeks yang keempat eh kode nama price stock gitu ya indeks yang kelima misalnya Oh dia bisa langsung nyari berdasarkan nama aja oke nama indeks yang keen dia bisa nama dan juga price indeks yang keetu misalnya dia bisa nyari berdasarkan e nama price dan juga stok kayak gitu oke ternyata dia ada kombinasi bisa kode dan Price juga nah ini ribet lagi ya kode dan Price belum ada di sini nih jadi Oh keedel berarti kode price Oh Ternyata ata dia bisa kode price dan stok ya ber kees9 bikin lagi indek kode price stok ini apa ribet banget ya kalau kita harus bikin semua kombinasi aja database bisa sebenarnya E bikin indeks langsung ke beberapa kolom tapi masalahnya urutannya harus sama contohnya saya bikin indeks kayak gini nih kode nama price Nah kita bisa nih Nyarinya berdasarkan kode aja habis itu kode dan nama habis itu kode nama dan Price habis itu kode nama price stok nah tapi tiba-tiba kalau saya bikinnya nama dan Price itu enggak bisa ya atau price dan stok itu enggak bisa indeksnya enggak kepakai jadi kalau kita bikin indeksnya kayak gini yang kepakai ini aja nih yang tiga di atas itu bisa digunakan sama yang keempat tapi kalau kombinasinya di di apa ya istilahnya itu di skip satu contohnya kode dan press itu enggak bisa jadi kita harus bikin lagi indeks baru Nah ini ini ribet banget kalau kita harus bikin seluruh indeks problemnya lagi adalah semakin banyak indeks yang kita tambahkan ke database semakin lambat proses Insert update-nya ya Kenapa karena saat kita melakukan Insert data itu kan nanti data itu akan disimpan Selain itu akan disisipkan ke dalam indeks-indeksnya indeks database-nya semakin banyak indeks database-nya contohnya kita di sini punya 100 indeks database jadi saat kita masukin satu data datanya udah masuk ke barisnya tapi data itu kombinasi indeksnya akan dimasukkan ke 100 indeks itu jadi makin gede atau makin banyak Data indeksnya makin lemot kasus seperti ini ini susah banget dan problemnya adalah kasus yang kayak gini itu bakal banyak ee dialamin sama programmer ya kalau dia bikin data tabel kayak gini Biasanya sih kalau saya di awal contohnya saya tahu nih data itu contohnya saya jualan toko online gitu ya produk saya tuh cuma 1000 Gitu ya mungkin saya enggak butuh gitu ya enggak apa-apa 1000 itu walaupun enggak pakai indeks cepat-cepat aja toh datanya dikit tapi kalau udah masuk ke jutaan datanya bahkan ratusan juta atau bahkan miliaran nah ini Jadi problem ini enggak bisa lagi walaupun kita sudah melakukan tahap yang namanya optimasi monolitnya nah gimana kalau kita casing aja tetap aja casing itu queri pertama akan lemot ya Bahkan parah banget kalau datanya udah miliaran itu bakal Ya bisa aja nanti database-nya e Spike ya cpu-nya Jadi mau enggak mau semua proses ke database yang sama itu bakal keganggu nah pada kasus seperti ini ini kita udah enggak bisa lagi udah mentok ya di optimasi monolitnya jadi cara-cara seperti ini udah enggak bisa Nah kalau kasusnya seperti ini nah saya sarankan pindah ke tahapan selanjutnya yaitu adalah cek qrs atau common query responsibility segregation Oke kita bahas nih detailnya Oke kita bahas cqrs ya jadi dia singkatan ya cqrs common ya jadi c-nya itu Sori comman ya comman query responsibility segregation responsibility segregation jadi pemisahan tanggung jawab ya antara command dan juga query command itu ya perintah query itu ya ya query gitu ya pengambilan data jadi simpelnya itu adalah kita akan bedakan ya antara yang comman ya dan juga yang query jadi ini simpelnya adalah kalau kita bikin aplikasi kita akan bedakan mana yang bagian command atau print mana yang bagian query kalau teman-teman bingung perintah itu apa perintah itu kayak contohnya eh simpelnya itu kayak Insert data update data delete data get data gitu ya query itu apa query itu adalah pencarian data atau ya Eh ya query select ya tapi yang kompleks kayak gitu jadi di sini simpelnya kita catat di sini berarti Yang komen itu contohnya Yang komen ya itu contohnya Insert update delete atau select yang sederhana misalnya buy ID gitu ya yang udah jelas indeksnya atau ya select byy yang indeksnya udah jelas gitu ya seperti ini ini yang masuk ke komennya ini komennya Nah terus gimana kalau yang query-nya Nah kalau query-nya ya itu berarti ya istilahnya itu search aja gitu ya search itu ya select yang tidak terprediksi gitu ya jadi bisa yang kayak tadi Nah yang ini nah ini ini kan simpelnya dia pencarian data ya pencarian data produk dia bisa masukin kode nama price dan lain-lain pokoknya kombinasinya udah aneh-aneh deh kita enggak bisa prediksi kira-kira inputnya mau seperti apa Oke jadi simpelnya adalah saat kita nanti bikin aplikasi ya Nah tadinya kan kita bikin aplikasinya adalah satu ya monolit Nah saat kita pindah ke cqs kita akan pecah aplikasinya itu dalam bentuk dua aplikasi aplikasi yang pertama adalah aplikasi e commannya ya aplikasi yang kedua adalah apasi yang query-nya Nah kenapa kita lakukan ini biasanya adalah saat kita pisahkan aplikasinya enaknya itu adalah kita bisa Tentukan teknologi yang cocok untuk command dan teknologi yang cocok untuk query contohnya misalnya kalau kita pakai database misal aja ya di sini saya pakainya misalnya post greay atau e micell gitu ya Nah ini kan ribet ya kalau kita harus bikin semua banyak indeksnya kalau indeksnya masih terprediksi mungkin simpel Nah dengan kita memisahkan antara aplikasi command dan juga aplikasi query-nya jadi simpelnya nanti aplikasi di sini ini misalnya aplikasinya berarti Eh misalnya kita bikin eh apa ya aplikasi toko online ini toko online yang comman-nya misalnya dia teknologinya pakai eh PHP misalnya di sini database-nya pakai SQL seperti ini nah jadi ini saat kita bikin nah kita bikin nanti bentuknya jadi dua jadi ini Fokusnya ke query pakai apa misalnya teman-teman tetap pakai PHP Oke Enggak masalah tapi database-nya kita bisa ganti databas-nya kita bisa ganti ngikutin sesuai dengan kebutuhannya contohnya kalau kebutuhan yang seperti ini ini agak susah kalau kita pakai postgay atau my SQL contohnya nah tapi ada database yang dikhususkan untuk pencarian seperti ini mau kombinasi e kombinasi indeksnya mau ribuan jutaan itu enggak masalah misalnya nah jadi kita bisa pakai yang sesuai contohnya di sini adalah Elastic search kayak gitu Jadi nanti dia pakai di sini yang aslinya yang monolit habis itu kita bikin satu aplikasi baru namanya query Nah nanti ya aplikasi itu kan jadi ada dua ya jadi aplikasi itu nanti kalau ini eh aplikasi ini aplikasi yang tadi ya comman Dan ini aplikasi yang query-nya jadi nanti user itu misalnya di sini user pengguna kalau dia melakukan proses command kayak Insert data update data delete data select by ID select by Index dan lain-lain pokoknya maka dia akan kirimkan request-nya ke command nah tapi kalau dia mau melakukan pencarian data maka dia akan kirimkan ke query Jadi pas di halaman ini nih di halaman daftar pencarian produk misalnya maka dia enggak perlu nyarinya itu ke ini ke komannya karena koman itu dia di belakangnya dia pakai database-nya misalnya MySQL gitu ya Nah Sedangkan ini pakai database-nya di belakangnya adalah Elastic search kayak gitu nah jadinya seperti ini atau kalau nanti mungkin kenyataannya akan ada satu aplikasi di depan ya E sebagai load balancer di depannya eh biar kan nanti kan user itu kan enggak perlu peduli ya di belakang ada aplikasi berapa jadi di sini ya kayak gini mungkin ini misal aja load balancer-nya pakai engine X gitu jadi user itu Cuma ngirim ke enginex kalau misalnya slash e apa gitu ya pokoknya yang bukan pencarian maka masuknya ke aplikasi comand kalau misalnya slash ke yang search gitu ya Nah kita masuknya ke query di sini nah jadi nanti aplikasinya Cukup dua aja aplikasi command dan aplikasi query Nah karena teknologinya berbeda ini optimal untuk e storage data biasa nah ini optimal untuk pencarian nah pertanyaannya lah kalau gitu Mang dari awal langsung aja monolitnya pakai sixers gitu ya ngapain juga bikin dua kayak gini jadi kan kita enggak perlu e pusing lagi nah problemnya adalah database yang khusus untuk pencarian itu rata-ratanya eh no squel no squel itu artinya enggak ada fitur kayak transaksional enggak ada fitur kayak join tabel enggak ada fitur eh Real Time juga datanya enggak Real Time jadi saat kita Insert enggak langsung keluar datanya Karena kan dia butuh melakukan eh optimalisasi indeks gitu ya masukin data ke indeks dan sebagainya jadi but waktu jadi biasanya ketika kita Insert mungkin satu atau du detik kemudian datanya baru bisa dicari nah kita kan enggak mau gitu ya ada orang masukin data produk di elastices pas dilihat halaman produknya loh kok ggak nongol datanya gitu ya dia refresrees baru 2 detik kemudian keluar nah kita kan gak mau e ada experience seperti itu makanya tetap e kalau untuk Insert data aja kita akan masukkan ke masqel Nah nanti baru pas pencarian data masuknya ke El pertanyaannya Gimana caranya data ini bisa ba sinkron ya antara data di MySQL sama elastices Nah itu mah tekniknya banyak ya sebenarnya ada teknik contohnya eh dari komen langsung aja jadi saat kita Insert data atau update data dan lain-lain dari komen juga langsung update ke elastices kayak gitu kalau mau langsung atau ya ini sebenarnya enggak cocok ya karena berarti dia sharing database satu aplikasi connect ke dua database kayak gini nah idealnya sih ya jangan ya idealnya mungkin bagusnya di query bikin api untuk Insert data J nanti dia bisa kirim ke si ini kayak gitu jadi saat saya Insert ke sini nanti komennya akan ngirim ke query untuk query yang akan Insert datanya ke Elastic search seperti itu Jadi kalau ini cuma ngirim pakai json aja misalnya nah jadi bisa seperti ini atau kalau teman-teman tidak mau intervensi eh aplikasi contohnya enggak mau ada kode aplikasi yang ngelakuin hal itu kita juga bisa eh instal aplikasi yang namanya CDC ya atau change data capture kayak gitu nah ini ini juga bisa jadi simpelnya adalah setiap ada perubahan ee di di database masql contohnya jadi contohnya Ini berubah gitu ya dia akan diterima oleh si aplikasi CDC ini dan aplikasi CDC ini akan mengirimkan langsung otomatis ke eltices-nya Nah itu juga bisa Ada banyak ya tool untuk CDC jadi banyak banget teman-teman tinggal pakai aja jadi simpel banget nah jadi ada seperti ini juga jadi banyak tekniknya kalau teman-teman mau gimana caranya ada dua database yang berbeda data ya bisa sinkron jadi ada banyak tekniknya Nah tapi intinya seperti ini nah jadi ini tahapan yang biasa saya rekomendasiin kalau teman-teman mau terjun ke microservice gitu ya jadi di awal jangan langsung terjun ke microservice tapi ikutin tahapan ini dari monolate dulu kalau udah mentok baru optimasi kalau udah mentok baru ke cekqrs nah sebenarnya kalau kita perhatikan dengan kita menggunakan cqr sebenarnya udah aman ya Eh karena kan kita sudah optimasi -nya bakal cepat juga habis itu ya untuk problem yang tadi kayak data tabel ini juga kita bisa handle dengan eh cek QS Jadi sebenarnya udah enggak ada kehawaitaran lagi gitu ya Bahkan kita mungkin udah enggak perlu lagi ke microservice nah tapi pertanyaannya tapi kenapa gitu ya tetap kok Eh ada masanya Kita pindah ke microservice nah ketika kita pindah ke microservice problemnya itu sebenarnya udah bukan lagi problem teknikal karena secara optimasi sudah optimal udah cepat juga aplikasinya Apalagi sudah ter terpisah sistem antara command dan juga query-nya gitu ya dan sebenarnya udah enggak ada masalah secara teknis nah biasanya orang pindah ke microservice itu bukan gara-gara hal teknis lagi tapi melainkan hal non teknis semakin ke sini kalau teman-teman punya toko online atau aplikasi apapun itu kan makin ke sini makin banyak ya eh fiturnya makin banyak orang-orangnya programmernya juga makin banyak misal aja awalnya cuma 5 orang ya kita bisa handle monolid dengan baik optimasi monolit dengan baik cek Q juga dengan baik 5 orang makin ke sini itu makin banyak orangnya 10 20 30 bahkan sampai 50 orang nah pertanyaannya 50 orang itu bisa maintain satu aplikasi atau enggak karena pasti akan ribet banget ya banyak konflik dan lain-lain termasuk kalau misalnya tim projectnya udah beda-beda misalnya ada project a project B Project C tiga-tiganya punya timeline yang berbeda Nah itu susah banget tuh kalau satu aplikasi dikeroyok rameai-rame dengan timeline Project berbeda-beda nah pada kasus seperti itu mau enggak mau baru kita Kita pindah ke microservice jadi microservice itu alasannya alasannya sudah bukan lagi tchnikal melainkan nontechnikal contohnya yang tadi ya Ee tim terlalu besar jadi kalau udah terlalu besar ya enggak bisa lagi ya kita eh satu Project ya digulung rame-rame itu udah enggak bisa lagi jadi tim terlalu besar contohnya ee e project timeline sudah beda-beda gitu ya lalu kita pengin ada yang namanya ownership dari fitur aplikasi kita jadi misalnya kan nanti itu kalau aplikasinya udah gede banget enggak mungkin satu orang harus bisa ngerti semuanya mungkin ada cuma satu atau dua orang atau satu tim cuma butuh bagian payment-nya aja artinya ownership dari bagian payment itu ya milik si eh tim payment-nya nah problemnya kalau di satu aplikasi itu ribet ketika dia menambah fitur menambah Framework atau menambah library itu takutnya kena impact ke semua eh tim yang lain gitu ya karena aplikasinya sama tapi kalau kita udah keluarin jadi aplikasi yang berbeda jadi microservice maka itu udah enggak masalah lagi Jadi kalau teman-teman pindah ke microservice itu jangan gara-gara Alasan teknis ya jadi karena lemot lah enggak optimal gitu ya Eh dan sebagainya tapi lebih ke alasannya adalah non teknis jadi contohnya Ti nya udah terlalu besar aplikasinya cuma satu udah susah maintain-nya timeline Project Udah beda-beda Ee PMA pengin rilis-nya Kapan PMB pengin risnya kapan dan lain-lain dan terakhir adalah ownership dari aplikasinya agar jelas kalau ada masalah payment tim payment masalah produk ya Tim produk masalah seller ya Tim seller jadi dengan seperti itu baru deh kita pindah ke microservice jadi ini tahapan yang biasa saya rekomendasiin kalau teman-teman mau ke microservice jadi di awal saya selalu tanya dulu timnya ada berapa lima ya kalau lima ngapain gitu ya Ee kita ke microservice sudah lakukan ini aja ee manolit optimasi dan cekqrs jadi ini Mungkin Vlog ya tentang Gimana caranya sebelum kita pindah ke microservice kalau teman-teman ada pertanyaan teman-teman bisa masukkan di kolom komentar Nanti kita diskusi juga ya eh di kolom komentar atau bisa diskusikan di discord-nya programmer zamano bye bye