Mashum Abdul Jabbar

Q: Konsep microservices yang sudah Pak Lucky jelaskan, best practice-nya itu seperti apa? Kapan kita harus memisahkan database itu per services dan kapan database itu bisa dibagikan? Dan Apa challenge-nya dari kedua hal tersebut?

A: Pertanyaan yang cukup menarik terutama berkaitan dengan migrasi dari monolitik ke microservices. Hal pertama yang harus dilakukan saat kita bicara services apakah services-services ini benar-benar menguasai modul-modul yang spesifik atau tidak? Contohnya kasus promotion calculation dari suatu retail, ternyata dia mengurusi ada berbagai macam promo misalnya ada 20 model promo, dari 20 model promo perlu identifikasi dahulu apakah mereka harus saling terkait atau independent bisa dibuat modul kecil-kecil, model promo tipe 1 hingga promo tipe 20, benar-benar spesifik untuk mengurusi untuk promo pertipe. Namun ternyata diidentifikasi promo tersebut saling terkait, berarti memang tidak bisa dipecahkan. Tetapi promotion modul bisa kita keluarkan dari modul (services) yang paling utamanya. Jadi, kita harus identifikasi dulu, selanjutnya dari sisi database. Apakah database ini jumble atau terpisah-pisah dalam sistem monolitik ini. Semisal saya memiliki 50 tabel, 3 diantaranya mengurusi transaction, 5 mengurus produk, 5 mengurusi promo, dst. Ternyata masing-masing bisa dipecahkan atau dikeluarkan karena tidak berhubungan. Oleh karena tidak ada hubungannya, maka pisahkan ke dalam databasenya masing-masing.
Concern nya adalah, ketika melakukan retention terjadi masalah padahal sudah dipecah berdasarkan database yang berbeda kemudian terjadi masalah, otomatis 3 modul itu tidak berjalan sama sekali. Alhasil dispesifikasikan modul A untuk connect ke database A, modul B ke database B, dan modul C ke database C, jika ada masalah maka tidak terganggu karena sudah terpisah. Kemudian mengenai share database, yang dilanjutkan dengan share normalization. Contohnya saat memiliki data dengan tabel transaksi, employee, dan user. Pada tabel employee mempunyai data-data detail mengenai employee, pada di tabel user ada username, dan informasi role employee di perusahaan, serta di tabel transaksi mengenai informasi terkait. Dari ketiga tabel apa yang dapat kita ambil? Apakah kita bisa melaksanakan normalisasi atau tidak? Normalisasi memiliki arti seperti Transactions ID, Employee ID, dan User ID. Dan saya mempunyai informasi nama yang ada dari ketiga tabel tersebut. Hal tersebut mengartikan bahwa adanya duplikasi dari ketiga tersebut. Sehingga username bisa dikeluarkan dalam satu database atau tabel terpisah yang sudah di normalisasi. Dan ketika sudah dikeluarkan, bisa jadi memiliki modul lagi dan service untuk mendapatkan username dan services untuk mendapatkan hal tersebut hanya khusus untuk username saja, dan inilah yang dipisahkan. Dan hal tersebut kita sebut dengan di share atau di normalizations. Selanjutnya tantangan database salah satunya ketika kita harus menentukan normalisasinya seperti apa? Dan bisa tidak database tersebut dipisah-pisahkan. Tantangan utama menentukan data bisa dipisahkan atau tidak.

Mashum Abdul Jabbar

Q: Kalau misalkan dalam satu aplikasi yang sudah menerapkan sistem microservices namun aplikasi digunakan oleh multiple company. Kemudian kita mau pisahkan per Company dengan dibuat database yang terpisah. Secara konsep microservices, apakah masih terpenuhi atau tidak? Dan best Practice nya seperti apa ya dengan case tersebut?

A: Kalau berbicara bukan dalam approach microservice, kita sama-sama memiliki proses bisnis yang sama, yang membedakan hanya Instansinya. Pendekatannya bisa dua yaitu menggunakan instance yang sama berbeda database name atau menggunakan database yang sama berbeda skema. Kemudian terkait dengan multi tendensi dalam database. Bagus tidak kita pisahkan bukan per database nya, tapi perskema, butuh tidak adanya komunikasi antar Company tersebut? Saya rasa tidak, karena masing-masing company memiliki sistem dan data tersendiri. Sehingga kita bisa menghapus opsi untuk memisahkan satu database name dengan satu skema per Company. Kemudian setelah dipisahkan per database name, atau dipisahkan per instance? Kedua hal tersebut sebenarnya dapat digunakan, karena tidak begitu signifikan. Karena connection string nya berbeda dari aplikasi nya. Namun jika terjadi masalah pada database instance tersebut, artinya semua Company akan terdampak. Sehingga kita dapat pisahkan kedalam instance-instance yang berbeda kedalam server-server yang berbeda. Yang kita separasikan adalah persistemnya, bukan per user atau Company nya.

Amat Basir

Q: Kasusnya adalah ada satu database yang diakses beberapa microservices dengan banyak thread sehingga sering kehabisan session dari database. Apakah ada advice/strategi untuk menghemat session database connection ketika kita implement microservices?

A: Salah satu caranya adalah dengan menggunakan connection pool, contohnya di postgreSQL ada yang namanya PgBouncer. Semua aplikasi ini tinggal ditambahkan saja namun tetap menembak ke sisi pool-nya kemudian akan menimbulkan antrian. Dalam kondisi database tidak memiliki performance yang cukup tinggi, padahal aplikasinya jauh lebih cepat daripada databasenya. Jadi kita dapat gunakan poll tersebut agar connection-connection tersebut mengantri, sehingga database nya pun tidak out of resource. Atau kita dapat menseparasikan database nya. Contohnya kita memiliki 1 instance danh 3 database name, dimana masing-masing nya sistem terpisah. Ada baiknya kita menggunakan 1 database instance untuk 1 sistem saja, sehingga tidak menembak ke 1 database yang sama untuk multiple sistem. Dengan demikian kita dapat lebih spesifik dan mampu memaintain dengan baik sistem tersebut, sehingga tidak kehabisan port seperti yang disampaikan. Kehabisan section terjadi karena adanya kelambatan. Yang perlu dilakukan adalah tuning dari sisi databasenya. Jangan sampai transaction ini terlalu lama dieksekusi, sehingga menimbulkan penumpukan yang menyebabkan maksimum connection. Maksimum connection akan menyebabkan transaksi balik tidak dapat masuk. Intinya, kita dapat menggunakan connection pool atau dipisahkan per instance/per server, dan melakukan tuning dari sisi databasenya. Seringnya aplikasi sudah menjalankan transaction tetapi tidak secara graceful menutup transaction tersebut. Aplikasi mungkin bisa saja dinyatakan selesai, tapi connection nya masih menggantung.

Abu Hdz

Q: Pada aplikasi enterprise apakah sebaiknya database di cluster dimana proses read dan write terpisah? Dan pada case dimana aplikasi memiliki jumlah user besar ada kasus dimana database memakan resource sehingga koneksi user terhambat. Kalau Database di cluster dengan microservices apakah akan ada keuntungannya? Kemudian apa yang harus diterapkan agar Database tetap bisa melayani walaupun jumlah pengguna tetap bertambah?

A: Pertama-tama harus disepakati cluster itu seperti apa. Di awal sempat disebutkan adanya read and write. Jika di PostgreSQL ada yang namanya master and replication, di mana ada master dan mirroring dan apakah itu bisa disebut cluster? Tujuannya apa? Bukan melakukan load balancing secara master and master replication. Sebenarnya tidak seperti itu. Namun apa yang kita bagi bukan didalam 1 transactionnya. Karena hal tersebut tidak akan bisa. Kalaupun mau melakukan load balancing, artinya kita membagikan beban reporting and transaction, itulah yang lebih tepatnya. Transaction itu membutuhkan kecepatan, writing yang cepat, karena akan ada transaction lock. Best practise nya kita menggunakan highest IOPS for the storage. Sementara dari sisi reporting yang memiliki banyak select dan select-nya multiple join kedalam table-table dan membutuhkan memori yang cukup tinggi. Hal tersebut akan menjadi beban pada 1 instance tersebut. Jadi yang disebut dengan load balancing disini adalah memisahkan read and write tetapi bukan dalam 1 transaction.
Yang kedua, kita tambahkan beban dari aplikasi menjadi beban juga pada databasenya. Hal pertama adalah apakah tuning sudah dilakukan dengan baik? Solusinya bukanlah dengan melakukan cluster database, tetapi lebih ke arah apakah semua bisnis proses itu harus menulis langsung kedalam database atau tidak? Sehingga yang tadinya monolitik yang semuanya menulis ke database, bisa diangkat bebannya bukan ke database lagi namun dengan menggunakan Kafka, komunikasi antar aplikasi. Kita juga harus melaksanakan identifikasi terkait restrukturisasi databasenya. Restruktur yang dimaksud adalah dengan memecah instance nya. Dan secara bisnis proses mulai dari login sampai dengan pembelian menggunakan modul apa saja. Jadi pendekatan itu bukan dengan menambah database server yang kemudian direplikasi, tetapi coba untuk pecahkan business prosesnya. Dengan demikian bisa difokuskan misalnya service untuk payment. Terkait CPU seats pada database. Pastinya akan ada slow query, itulah yang menyebabkan CPU yang tinggi, resource meningkat, dan concurrence pun semakin tinggi. Kita harus mengidentifikasi slow query tersebut datang dari mana dan penyebabnya apa? misalnya kurangnya index, bisa ditambahkan kembali index yang sesuai dengan query-nya. Jadi yang pertama yang harus dilakukan adalah identifikasi database dan permasalahannya, selanjutnya melakukan restructure database dengan salah satunya melakukan tuning. Agar performance database yang belum begitu bagus, dapat ditahan dahulu jangan sampai databasenya menjadi bermasalah. Kemudian mengenai approach terkait separasi databasenya.

Abu Hdz

Q: Concurrence yang tinggi menyebabkan bottleneck dari sisi aplikasinya. Kalau menghadapi hal tersebut apa yang perlu kami lakukan ya?

A: Ketika berbicara mengenai resources yang tinggi terhadap database tersebut, kita tidak perlu masuk dahulu ke dalam microservices architecture atau clustering read and write. Kita coba monitoring terlebih dahulu dalam instance tersebut. Hardware menjadi salah satu hal yang dapat mempengaruhi database. Jika menggunakan VM, maka diperlukan virtualisasi. Karena ada virtualisasi disitu sehingga memiliki layer-layer yang harus dilewati yang menyebabkan database tidak dapat digunakan secara maksimal. Kami selalu merekomendasikan menggunakan implementasi database di barmetal. Berhubungan dengan concurrence yang tinggi, maka harus dibersamai dengan CPU clock yang tinggi juga. Karena saat menggunakan clock yang tinggi, waktunya pun akan semakin cepat. Lebih baiknya bukan menambahkan jumlah core tapi meningkatkan clock. Dan terakhir melakukan monitoring slow query-nya. Karena penggunaan CPU dan memori yang intensif sangat dipengaruhi oleh slow query tersebut. Kalau clock sudah tinggi namun masih kurang. Barulah ditambahkan core nya. Jika setelah ditambahkan core masih kurang juga, bisa langsung diseparasikan saja. Yang perlu digaris bawahi adalah quey nya. Dan yang terakhir adalah mengenai vacum. Apakah sering dilakukan vacum atau tidak?

Bambang Wijanarko

Q: Dari sisi security untuk microservices architecture, apakah cukup dengan penerapan SSL ataukah ada konfigurasi lainnya yang diperlukan?

A: SSL salah satu hal untuk melakukan encryption terhadap komunikasi data, selain memproteksi komunikasi tapi juga memproteksi database, data encryption jangan sampai dapat dibongkar. Bukan hanya dari encryption datanya saja, namun dari aksesnya. Apakah tersebut memiliki akses untuk data tersebut? Saya rasa tidak hanya SSL saja. Ada metode-metode lainnya yang dapat digunakan seperti encryption dan juga token.

Mawardie

Q: Jika kami multi Company dan ada beberapa core services implementation apakah kontainer pilihan yang tepat pak?

A: Jadi kalau multicompany seperti yang telah dibicarakan kita bicara mengenai Multi Tenancy database apakah kita mau simpan dalam instance yang sama atau mau memisahkan sistemnya. Jika ingin dipisahkan bisa menggunakan containerization, didalamnya terdapat aplikasi dan database. Oleh karena menggunakan container, resource bisa langsung digunakan dan diisolasikan, sehingga tidak bercampur. Bedanya dengan penggunaan VM, dalam VM kita tidak dapat menseparasikan penggunaannya. Sehingga isolasi dan containerization nya pun menjadi tidak berjalan. Jadi tidak masalah menggunakn coutainerization untuk mulkticompancy.

Mawardie

Q: Microservices ini secara skalabilitas jika diakumulasi dengan transaksi yg tinggi atau aliran data yg very high, apakah bisa deliver dan receive dengan smooth tanpa ada lost? Bagaimana perhitungan skala microservicenya? Adakah parameter dan best practicenya seperti apa?

A: Komunikasi antar service memang menjadi tantangan dalam topology microservices, karena memberikan tambahan latency ketika sebuah business process berjalan. Pemisahan business process ini tentunya akan membuat kompleksitas per modulnya menjadi lebih sederhana. Tinggal bagaimana komunikasi antar modul tersebut dapat dioptimasi dengan baik, untuk tetap menjaga integritas data dan transaksi, mulai dari starting state sampai dengan final state.
Untuk skalabilitas sendiri, kembali lagi kita perlu identifikasi kompleksitas dan business process sampai dengan struktur database. Namun keuntungan yang akan didapatkan adalah dapat dengan mudah menambahkan service-service aplikasi dengan cepat.

Nanang Adyagraha

Q: Kriteria apa saja yang dibutuhkan bagi perusahaan agar segera mengganti ke arsitektur microservice?

A: Microservice architecture pada dasarnya bukan menjadi suatu keharusan, karena pada dasarnya adalah sebuah pendekatan terhadap optimasi sistem. Jika kita bicara kriteria, bisa dilakukan identifikasi terlebih dahulu apakah secara aplikasi yang berjalan dapat dengan mudah di-breakdown? Apakah banyak modul-modul dalam aplikasi saat ini yang sebetulnya dapat berdiri secara independen? Apakah memiliki tingkat agility atau pengembangan bisnis yang tinggi? Hal ini yang saya rasa dapat menentukan secara awal, apakah perlu mengadopsi microservice atau tidak. Baru setelah itu kita melihat kesiapan teknologi untuk mengadopsinya.

Nanang Adyagraha

Q: Kalau Microservicenya pakai kubernetes, bagaimana debugging service di dalam pod, tanpa perlu masuk ke pod cube nya?

A: Debugging bisa dilakukan dengan beberapa cara, yang paling mudahnya adalah melakukan pemantauan dari sisi log file. Jika menggunakan cube pod, seharusnya log file tetap dapat diakses via host. Jika memang mau melakukan debugging melalui seperti contohnya GDB, maka mau tidak mau harus memang masuk ke dalam pod tersebut.

Nanang Adyagraha

Q: Apa benar terkait issue kalau banyak yg balik lagi ke sistem monolitik karena cost, karena resource sama complexity buat microservice sangat tinggi?

A: Dalam hal ini mungkin saya tidak membicarakan mengenai cost-nya. Tetapi dari sisi teknis, memang betul kompleksitas, khususnya komunikasi antar service yang perlu sangat diperhatikan, karena hal tersebut menimbulkan latency dan perlu memanfaatkan beberapa teknologi tambahan. Namun demikian, kita bisa gain beberapa keuntungan:

• Faster feature deployment and troubleshooting.
• Load separation.
• Easier scalability

Maka dari itu, kembali lagi kepada identifikasi apakah sistem sudah butuh untuk dibuat menjadi microservices. Jika memang lebih baik tetap menjadi monolitik karena dependensi antar modul yang ketat, maka tidak masalah.

Nanang Adyagraha

Q: Berbicara tentang microservices, istilah docker/container pasti sering juga disebut. Apakah ada perbedaan antara keduanya?

A: Docker itu adalah salah 1 product containerization, sama seperti Kubernetes dan LXC.

Nanang Adyagraha

Q: Apakah memungkinkan untuk memigrasikan aplikasi monolith ke arsitektur microservices menggunakan OpenShift? Bagaimana dengan databasenya?

A: Bisa saja, inti dari migrasi ke microservice architecture adalah memecahkan business process ke dalam service yang lebih kecil dan modular. Penggunaan teknologi bisa apa saja. Database seperti yang sudah dijelaskan di beberapa point di atas.

Nanang Adyagraha

Q: Apakah Enterprise Service Bus (ESB) dan microservices memiliki konsep ataupun fungsi yang sama, yaitu untuk mengorkestrasi aplikasi dan layanan yang ada?

A: Telah disampaikan ESB dan Microservice, pada dasarnya dua hal berbeda, ESB adalah tool, sedangkan microservice adalah arsitekturnya. Konsep microservice architecture adalah pemisah modul-modul, kemudian bagaimana cara mempermudah berkomunikasi? maka bisa diterapkan ESB, dimana diberikan aturan konfigurasi. ESB bertugas untuk melakukan orkestrasi terhadap servis-servis yang memang tersebar dan memiliki modul masing-masing. ESB adalah teknologi yang digunakan untuk mempermudah komunikasi antar service dalam microservice architecture.

Nanang Adyagraha

Q: Apa saja keuntungan menggunakan arsitektur Microservice?

A: Dapat mengacu ke pertanyaan nomor 12 dan penjelasan sepanjang webinar.

Nanang Adyagraha

Q: Apakah keuntungan suatu software yang menggunakan desain Microservice?

A: Telah dijelaskan di point sebelumnya

Nanang Adyagraha

Q: Mengapa microservices wajib ada di cloud?

A: Tidak wajib ada di cloud. Pendekatan microservices biasanya adalah menggunakan containerization yang mana bisa saja pada server on-premise.

Nanang Adyagraha

Q: Mengapa microservices Architecture MSA digunakan oleh perusahaan?

A: Telah dijelaskan di point sebelumnya

Budi Hertanto

Q: kalau melihat dan mendengar penjelasan pak Lucky, sepertinya cukup simple untuk menerapkan microservice. pertanyaan saya dalam realitasnya perlu berapa lama untuk migrasi dari monolitik ke microservices, persyaratan awal apa yang harus dipenuhi yang bisa menentukan sukses tidaknya proses migrasi ini dan point-point apa saja yang umumnya akan dihadapi ketika menerapkan/migrasi ke microservices ini?

A: Perkara waktu tentunya tergantung pada besar dan kompleksitas data. Kalau ternyata cukup mudah proses bisnisnya dan sudah cukup modular, maka akan sangat cepat. Kembali lagi mengenai struktur dari database. Kalau ternyata saling terkait, maka diperlukan challenge untuk memisahkannya dengan melakukan normalisasi, restructuration, dan perubahan topologinya. Intinya, proses bisnisnya seperti apa, apakah secara arsitektur memungkinkan, apakah sudah ada skeleton ketika membangun aplikasi diawalnya? Bilamana susah untuk dibangun, maka tidak perlu dimigrasikan namun cukup dengan membuat suatu sistem yang baru untuk menggantikan sistem yang lama. Apabila mudah, maka dapat langsung memigrasikan permodulnya. Microservice architecture ini pada dasarnya bukan migrasi yang dapat dilaksanakan secara big bang, tetapi dengan istilah mengikis/memisahkan satu persatu. Karena untuk waktu kembali lagi kepada kompleksitasnya.

Farhan Awwaliy Maulana Muhammad

Q: Tadi sempat dibahas perihal membagi DB per modulnya/fungsinya. Bagaimana cara mengatasi delay/latency karena harus mengakses DB yang beda instance/server?

A: Kembali lagi bahwa microservices approach kita akan dihadapi dengan tantangan komunikasi. Karena yang awalnya satu kemudian kita pecah, dan ketika dipecah masing-masing modulnya ternyata mengakses database instance yang berbeda-beda. Satu hal yang harus diperhatikan, bagaimana aplikasi bisa mengakses database dengan cepat, sehingga dengan bisnis proses semakin kecil. Dengan bisnis proses yang semakin kecil, maka kompleksitas bisa diperkecil sehingga akses bisa dipercepat. Contohnya ketika menggunakan API yang integrasinya per services-services itu sendiri. Bukan melakukan join terhadap multiple instance secara database. Sehingga yang sebelumnya menjadi beban database, kita angkat menjadi beban services-services tersebut. Selanjutnya apabila kita ingin mengagregasikan datanya, kita perlu melihat bagaimana logic dari aplikasi tersebut atau menggunakan ESB. Contoh dalam penggunaan ESB adalah ketika kita menginginkan memiliki satu data yang mana data tersebut dapat across ke tiga data lainnya. Bisa saja ketika kita melakukan request, langsung dijalankan secara paralel dan langsung mengakses ke databasenya masing-masing. Setelah datanya kembali, kita dapat melakukan orkestrasi lagi diatasnya, transformasi, maupun agregasi diatasnya. Jadi peranan dari middleware adalah untuk melakukan agregasi data pada ESB bukan pada databasenya. Dan dengan bisnis proses bisnis yang tepat akan mendapatkan performance yang sama.

Yong Ong

Q: Sebelumnya dari penjelasan gambar microservices untuk penerapan aplikasi tersebut juga disertai pembagian layanan ke database juga. Apabila database tetap satu sedangkan di sisi front end dibagi menjadi layanan kecil-kecil, apakah hal tersebut bisa dikatakan aplikasi microservices?

A: Sebetulnya bisa saja, pendekatan microservice architecture pada dasarnya adalah untuk membagi modul-modul menjadi kecil. Kita dapat sampaikan hal tersebut menjadi bagian dari microservices architecture. Hanya saja hal tersebut bukan menjadi best practice dari microservices. Karena kalau masing-masing service mengakses database yang sama artinya akan ada latency communication sehingga bisa dibilang kurang efektif. Kenapa kita mengangkat monolitik menjadi microservice architecture? Karena ingin mengurangi beban kompleksitas dari sisi database. Dengan pemecahan database dan aplikasi yang kecil-kecil, agar ketika satu database mati maka tidak akan berdampak kepada database lainnya. Itulah alasan mengapa kita perlu memisahkan bisnis proses-nya.

Yong Ong

Q: Bila kita migrasi dari aplikasi monolith ke microservices, apakah juga harus disertai pembaharuan hardware?

A: Tidak selalu, bergantung kepada bagaimana rancangan topologi sistem tersebut dan kebutuhanya.

Yong Ong

Q: Apakah terdapat pengaruh penggunaan processor AMD maupun INTEL terhadap development aplikasi microservices?

A: Tentunya AMD merupakan pilihan yang lebih baik dalam membangun sebuah high performance system. Untuk lebih lengkap, dapat dilihat pada hasil benchmark kami.

Makpui

Q: Jika instance dipisah bagaima handle ACID dan strategi untuk DRC?

A: Kalau DRC apakah masing-masing instance sudah menggunakan server yang sama apa tidak. Kalau menggunakan server yang sama, kita dapat replikasi per masing-masing instance nya ke dalam DRC server. Ketika suatu saat kita menginginkan swing over, kita dapat langsung mematikan dan menaikkannya saja. Intinya ketika berbicara mengenai DRC, tidak ada bedanya dipecah secara multiple instance atau single instance, karena tidak membicarakan AHA. Lalu, ACID yang dimaksud adalah transaction, transaction tersebut tentunya di handle oleh masing-masing instance, oleh karena itu ACID akan tetap terjaga. Hanya saja bilamana terjadi transaction yang dipecah, maka hal tersebut bukan lagi menjadi ranahnya ACID database. Tetapi menjadi bagian dari proses bisnis dari sisi aplikasinya.

Budi Hertanto

Q: Sebelumnya, terkait virtualisasi tidak disarankan karena mengurangi performance karena ada proses di virtualisasi tsb, Bagaimana dengan encryption data, bukankah juga akan memakan resource juga? Apakah tidak mengurangi performance?

A: VM yang disebutkan masih secara global. Semua proses yang berjalan di atas mesin yang divirtualisasikan, akan memiliki performa yang berbeda. Termasuk data encryption, karena diatas virtualization ada HAL (Hardware Abstraction Layer) nya. Inilah yang akan mempengaruhi performance sehingga sangat disarankan untuk melakukan isolasi, kita perlu menggunakan container. Karena dapat langsung mengakses ke memorinya. Contoh, bilamana disk dengan terpaksa menggunakan VM. maka disk tersebut dapat langsung di direct attach kan ke dalam VM nya dan jangan di virtualisasikan lagi. Semakin banyak virtualisasi, akan menyebabkan double kelambatan.

Rahmat Putra

Q: Apakah ada skenario dimana database monolitik dengan arsitektur aplikasi micro services memberikan keuntungan, dibandingkan dengan multi datastore? contohnya backup lebih sederhana dan konsistensi backup menjadi lebih mudah.

A: Ada beberapa skenario, dengan beberapa keuntungan diantaranya mengenai model backup. Model backup tersebut dapat dilakukan lebih mudah karena maintenance satu database saja. Dan dalam konteks HA, akan lebih mudah karena hanya ada 1 point of maintenance. Tinggal bagaimana approach nya dalam melakukan housekeeping dalam menjaga data retensinya. Kalau database ditumpuk-tumpuk, maka makin lama akan banyak transaksi dan dapat mempengaruhi performance. Saya tidak selalu mewajibkan untuk memecah database. Karena ada beberapa proses bisnis yang sebetulnya ada di dalam 1 instance yang ada. Jadi tujuannya dipisahkan adalah untuk mengurangi beban database sehingga dapat lebih cepat.

Thomas Meidiyanto

Q: Menurut Bapak, apakah memungkinkan aplikasi ERP yang tadinya monolitik dijadikan MicroServices? Karena aplikasi ERP sangat membutuhkan integrasi antar modulnya.

A: Aplikasi ERP apa yang digunakan? Apakah sudah bersifat monolitik? Memang ada yang disampaikan secara open source sehingga bisa pecah-pecahkan modulnya. Yang paling memungkinkan pada dasarnya seperti ERP kepegawaian, payroll, dsb. Itu bisa saja dipisah namun tergantung dari capability ERP tersebut. Apakah open API atau tidak? Approachnya bukan ERP bisa apa tidak, namun aplikasi ERP nya mendukung microservice atau tidak.

Ade Kristo

Q: Ini dipastikan akan menambah Cost. Lalu akan memakan berapa banyak resource/space storage pada hardwarenya? Dan ada fitur-fitur apa yg menarik?

A: Berbicara mengenai cores mungkin kurang relate dengan microservice architecture. Karena tujuannya bukan menambah hardware tetapi lebih membuat modul menjadi lebih kecil dan kompleksitas. kalau bicara mengenai hardware cost itu relatif dari bagaimana kita mau mendekati. Seharusnya dengan memisahkan modul-modul tersebut tidak perlu menambah hardware cukup dengan menggunakan container dan server yang sama, hal tersebut tetap bisa digunakan.

Bambang Wijanarko

Q: Bagaimana cara memonitor efektifitas & utilisasi microservices yang telah dibuat?

A: Efektifitas dan utilitas sebenarnya cukup mudah dimonitoring melalui endpoint. Kita dapat melakukan pengecekan dimasing-masing message queue nya atau dimasing-masing keluar masuk databasenya. Melalui endpoint kita dapat langsung melihat performanya, besaran transaksi yang masuk, massage yang diterima, dst. Pada dasarnya performance pada sistem itulah yang berhubungan dengan user. Yang perlu diingat adalah mengenai komunikasinya, seberapa banyak massage yang berjalan dalam message queue, seberapa cepat dan seberapa banyak API merespon data yang diinginkan. Dapat dimonitor pada masing-masing endpoint atau dilakukan monitoring di ujung yang paling dekat dengan user.

Budi Hertanto

Q: Dalam konteks microservices, seberapa besar peranan dari spesifikasi server, khususnya dalam konteks jumlah cores, clock speed processor & memory, dibandingkan dengan spesifikasi ketika masih monolitik?

A: Spesifikasi server sangat berpengaruh dari concurrency. Semakin tinggi concurrency nya maka kita harus meningkatkan clock yang memadai. Apakah akan dipengaruhi oleh berapa jumlah services yang berjalan? Jumlah services yang berjalan itu akan menangani beberapa concurrency? Kembali lagi pada bisnis prosesnya. Dalam microservices architecture ini, kita berbicara mengenai logic-logic dari modul yang dipisah. Semakin banyak yang dipisah maka semakin meningkat juga concurrency-nya.

Apriadi Apriadi

Q: saat ini saya menggunakan open source Idempiere menggunakan database postgresql, dimana memang multi company saat ini suka lambat sekali, kira2 seperti apa untuk setingnyaa

A: Yang bisa saya sampaikan hanya secara umum dari sisi database adalah apakah sudah memiliki indexing yang sesuai? Apakah sudah menerapkan storage yang tercepat untuk transaction log? Dan apakah parameter seperti shared buffer, work memory, dan yang berhubungan dengan memory lain sudah di-tuning sesuai kebutuhan?