diskusi.tech (beta) Community

loading...

Tanya Kodenol: Microservice

mimindeeptech profile image Mimin Deep Tech ・4 min read

Dalam perkembangannya, sebuah aplikasi membutuhkan pemisahan antara logic antar-muka, logic bisnis, dan data. Ini yang dinamakan three-tier, bagian dari arsitektur software monolith. Namun ini juga masih belum cukup memenuhi kebutuhan aplikasi, sehingga dibuatlah beberapa service kecil yang saling berinteraksi, dinamakan dengan microservice.

Pada 24 Juni 2020, Deep Tech berkesempatan untuk tanya jawab di twitter bareng Andi Pangeran, Tech Lead at GoPay membahas topik microservice. Yuk simak rangkumannya di bawah ini.

Deep Tech Foundation (@deeptech_id)

Nah saatnya kita memasuki waktu Indonesia bagian Tanya #KodeNol. Ngobrolin Microservice, yuk. Sekarang mimin panggilkan @A_Pangeran untuk bales semua pertanyaanmu hari ini! Yang mau tanya, reply tweet ini dan jangan lupa pake hashtag #KodeNol. Mari kita mulai!

Wah kayaknya masi pada malu-malu nih. Yauda mimin tanya duluan deh... Mas @A_Pangeran, boleh tolong jelasin gak Microservice sendiri itu maksudnya apa sih?

A: Halo Deep Tech, thanks nih buat kesempatan yang diberikan.

Jadi topiknya microservice yah, bakal agak panjang nih kalau mau dijelasin. Sebelum berbicara panjang lebar tentang microservice, baiknya kita flashback dulu gimana perkembangan dari software architecture. (Yang pernah pelajarin masa kuliah bisa flashback juga)

Pada awalnya, architecture dalam pengembangan aplikasi begitu simple. Hanya terdiri dari aplikasi (dimana logic berada) dan storage/database, yang mana keduanya akan dijalankan di satu komputer yang sama, ini disebut juga dengan one-tier architecture.

Pembuatan aplikasi seperti ini pun masih ada sampai sekararang, tidak ada yang salah dengan itu. Ada kelebihan dan kekurangannya. Untuk case one-tier, kelebihannya:

  1. Untuk dapat mengoperasikan hanya membutuhkan satu komputer, dari sisi biaya jadi lebih murah.
  2. Proses instalasinya lebih mudah, karena hanya satu komputer dan tidak butuh setup network.

Kekurangannya:

  1. Aplikasi hanya bisa digunakan hanya pada komputer tersebut, sehingga hanya bisa satu pengguna dalam satu waktu (gantian kalau mau :P)

  2. Resiko data yang disimpan akan hilang ketika komputer-nya rusak.

  3. Pengguna dari aplikasi tentu mempunyai akses juga ke databasenya, risk terhadap manipulasi data pun meningkat

Menjawab kekurangan ini, muncullah ide agar aplikasi dan database di pisahkan. Dan aplikasi kini sudah dapat digunakan oleh beberapa user dari berbagai komputer (tidak perlu gantian lagi :D)

Issue kehilangan data ketika komputer rusak tentu masi ada, akan tetapi berkurang karena bukan komputer yang di bawah/digunakan pengguna. Tapi jadinya butuh biaya tambahan untuk beli komputer (server) khusus database, kemudian instalasi network :D

Ada juga issue terkait aplikasi yang di komputer pengguna perlu akses ke database, sebaiknya network akses hanya dibuka untuk LAN (local area network) atau dibuat bisa diakses dari lingkungan kantor saja yah.

Architecture begini disebut dengan nama two-tier. Biasanya app ini hanya support satu jenis antaramuka apakah desktop saja, atau web aja. Belum lagi logic bisnis dan antarmuka-nya yang menyatu, ketika implement antarmuka yang baru terjadi duplication logik bisnisnya :D

Tidak ada cara lain selain memisahkan logik antar-muka | logik bisnis | dan data, jadilah three-tier :D

Singkat cerita, aplikasi makin berkembang, pengguna makin banyak. Yang awalnya satu aplikasi saja yang memproses semua request dari pengguna, kini sudah tidak mampu lagi. Segala cara improvment telah dilakukan termasuk menambah daya memory/disk/processor.

Muncullah ide untuk memisahkan satu aplikasi tadi (yang biasa kita sebut monolith), ke beberapa service kecil dan saling berinteraksi.

Gitu kira-kira kak @deeptech_id tentang microservice :P

Paturik-kun (@selintasku)
Denger denger kabar banyak yg balik lagi ke sistem monolith karena cost, resource sama complexity buat microservice sangat tinggi

A: Hehehe iya, karena banyak yang berpindah ke microservice tidak sesuai kebutuhannya / belum waktunya, lebih ke ikutin trend aja :D

Termasuk, sebenarnya agar dapat membuat aplikasi microservice yang benar dan rapi, sebaiknya kita harus bisa dulu buat aplikasi monolith yang rapi.

Musa IR (@musair_dev)
Jadi kriteria untuk segera ganti ke arsitektur microservice itu apa Mas? Biar gak salah karena ngikutin hype aja

A: Pertimbangan pertamanya mungkin dilihat dari sisi aplikasi-nya dulu, apakah emang app butuh ngeserve load sebanyak itu. Cari tau bagian mana/feature apa yang paling butuh improvement. Lihat apakah ada ruang improvement, kadang nih penambahan index database aja itu cukup kok :D

Dan banyak lagi pertimbangannya tentu saja. Apapun itu software architecture itu tentang trade-off, silahkan dihitung saja. Mungkin yang perlu dinotes adalah sebisa mungkin proses perpindahannya jangan bigbang, dan punya mekanisme rollout yang baik. Rollout, monitoring, improve.

Chaidir Yahya (@chaidiryahya)
Misal nih, sebuah web punya fitur A, B, C. Nah yg B ini makan load paling besar. Segala improvisasi sudah mentok. Berarti kalau dari penjelasan yg diatas, cukup B yg service nya dipisah sedangkan A dan C tetap monolith?

A: iya sebaiknya seperti itu, kecuali punya developer banyak dan waktu yang banyak juga. Proses pemecahan aplikasi kan agak panjang. Contoh buat case B, ditelaah dulu domainnya, pecahnya jadi brp ? anggaplah b1, b2, b3. Rollout plannya gimana dari B ke pecahannya, Migrasi datanya ?

Fajar Hidayat (@fajarhide)
Microservicenya pake kubernetes ya mas? Kalo iya mau tanya bagaimana debuging service di dalam pod, tanpa perlu masuk ke pod kube nya. Casenya service saya pake PHP jadi ketika ada issue kadang masih perlu masuk ke pod dan edit code di dalam pod buat debug nah kendala saat podnya replica.

A: Iya, wah berarti lognya kurang yah jadi masi butuh masuk ke box buat liat. Saran, service dibuat punya instrumentation yang enak dulu ,termasuk Logging / metric / tracing.

Eka (@bitw1z)
Tanya di luar microservice boleh gak ya. Mas @A_Pangeran pernah pakai metode blue green deployment gak? cara handle perubahan stucture databasenya gimana ya?

A: Boleh dong. Pernah banget. Boleh di elaborasi lagi gak issue nya apa? Kalau terkait migration schema, usahain aja tidak melakukan perubahan schema yang gak backward compatible. Contoh delete field sedangkan field itu masi dipakai di versi lainnya.

Nah itu tadi tanya jawab soal microservice bareng Andi Pangeran, Tech Lead at GoPay. Masih ada pertanyaan soal microservice? Yuk tanyain di kolom komentar!

Discussion

pic
Editor guide