Penjelasan microservicenya kurang tepat, harusnya antar service tidak ada saling panggil, karena kalau ada saling panggil sama aja kayak monolith, karena tiap service itu berdiri sendiri, tanpa bergantung dari service yg lain. kenapa gitu kalau ada saling panggil nantinya couplingnya terlalu gede, dan resilieance tiap servicenya nggak ada. Jika salah satu service itu mati harusnya nggak mempengaruhi service yg lain, jadi service yg lain tetep jalan. biasanya calling service bisa diganti pake kafka. Terus buat authentication service nggak dilakuin di tiap service tapi di api gw nya
agree,best practicenya minim handshaking antar service,karena berdiri sendiri, akan banyak data duplication,,untuk menghindari dependency antar service,trus bagaimana syncnya,,disini kunci kenapa butuh messaging,,,kalo pun ada handshaking,,itu hanya terkait authentication n authorization
wah mantap bang penjelasannya, semoga di respon creator, btw suka banget kalau ada diskusi kaya gini, saya yang awam di microservice dapat insight baru jadinya
Yak betul. Jadi karena memang microservice ini is a broad concept, jadi memang banyak approach yang dipake. Tergantung kebutuhan aja mau pake approach yang mana. Yang jelas jangan mau dibrainwash ya "microservice harus begini", ngga semua guidelines harus diikutin, tapi kita harus tau semua guidelines untuk referensi 😘
cmiiw setauku emang ada 2 jenis sih microservice dari sisi implementasi yaitu service orchestration dan service discovery/choreography, kalo yg masih calling api antar service itu masuknya service orchestration dan emang couplingnya gede antar serrvice tapi implementasinya lebih mudah dan kalo yang anda bicarakan juga microservice tapi jenisnya service discovery/choreography (implementasinya lebih rumit biasanya buat aplikasi dgn user banyak) yang biasanya pake teknik messaging coupling antar service emang kecil tapi coupling service ke message brokernya dan api gateway nya jadi gede jadi pastikan instance AG dan MB harus selalu berjalan dengan baik karena kalo mati ya wassalam wkwkwk.
biasanya ini FOMO ( rasa takut merasa “tertinggal” karena tidak mengikuti aktivitas tertentu. ) jadi ikut2 tan padahal mah project nya masih pas dan sanggup banget di arch monolith saat ini wkwkw ...... emang mirocservice ini bener2 harus mateng dipikirin kalo mau migrasi system arch dari mono ke micro
Setuju. "Sub-Monitoring" per service harus dipersiapkan dan didesain dengan baik. Sebenarnya sangat mudah untuk menentukan Kapan baiknya menerapkan konsep Microservice atau tidak. Dan tentang auth, bisa terapkan logic/method Zanzibar. Dan dalam banyak kasus, Small Simple Monolith adalah Microservice
10 Software Engineer, Companynya pake Architecture Microservice, dan ada 70 service. Trus log nya pake syslog tanpa pake platform kaya Loki, Kibana, dkk. Fix, bulan depan berkabung (engineernya masuk rumah sakit) *sad. #canda
Microservice emg pisau bermata dua. Kalo emg msh tahap awal plg bnr monolith entar kalo tim udh gede/proses berat yg kaya IO/ payment yg harus konsisten datanya baru migrate MS pelan2
Om bahas N.A.T.S dong. Gue suka banget, cuma kok gak populer disini ya 🤔 . Padahal kalau pertimbanganya masalah persistence, sekarang kan udah ada jetstream.
Jika client sebanyak 100 M rquest data bersamaan ke server. Bagaimana caranya agar semua client mendapatkan data secara bersamaan dari server dalam waktu 5 detik?
Di sini kasusnya 100m request ke server utk operasi GET. Diasumsikan utk mengambil data dari DB. Ada 2 possible bottleneck. Di DB, dan di servernya. Utk handle server bottleneck, pke load balancer utk handle load besar. Biasanya replica severnya bs belasan. Utk masalah DB, ini lbh tricky. Karena semua tgantung operasi. Klo operasi hanya read, berarti perlu read replica utk db nya. Nah klo writenya jg besar, perlu db sharding
kalo skala apss lu masih mumpuni di monolith , ga usah sok2 an lah ganti ke microservices 😷, belum lg kalo dev nya cuma 2 biji begitulah yg disampaikan beliau ini...
@@zachedo3538 ya nerima project + ngawasin aja. problem solve, ngembangin fitur dan masalah proyek dll. yg mikir staf. udah gitu semua permintaan client di acc terus sm dia (apapun). btw dia ngerangkap juga jd PM. lagi pula kita berdua gak bisa show off ke atas, karena lead ini terlalu licik wkwkwk.. akhirnya kita ber2 keluar gatau dah tuh kantor gimana sekarang wkwkwk..
