Microservices atau Satu Aplikasi Utuh: Mana yang Cocok untuk Bisnis Anda

Kalau vendor atau developer Anda menyebut microservices, yang sedang dibicarakan hanya cara kode dipecah. Sistem bisa dibangun sebagai satu aplikasi, atau sebagai beberapa aplikasi kecil yang saling bicara lewat jaringan. Keduanya bisa menjalankan proses bisnis yang sama.

Untuk sebagian besar UKM di Indonesia, satu aplikasi utuh lebih murah dan lebih mudah dirawat. Keputusan ini pantas Anda pegang karena mengubah biaya bulanan, siapa yang bisa direkrut, dan seberapa mudah developer berikutnya meneruskan pekerjaan. Kami kumpulkan keputusan arsitektur lain yang sebaiknya Anda pegang sendiri di panduan arsitektur software untuk pemilik bisnis.

Apa yang sebenarnya dimaksud dua istilah itu

Pakai contoh sistem pesanan. Di dalamnya ada tiga pekerjaan: checkout, pengurangan stok, dan pembuatan invoice.

Kalau tiga pekerjaan itu berada dalam satu program yang dipasang ke satu server, bentuknya monolith. Satu aplikasi, satu proses rilis, satu database. Istilahnya terdengar seperti celaan, padahal hanya berarti utuh.

Kalau ketiganya dipisah jadi tiga aplikasi, masing-masing dipasang sendiri dan saling mengirim pesan lewat jaringan, bentuknya microservices. Checkout memanggil layanan stok, layanan stok menjawab, lalu layanan invoice jalan sendiri setelahnya. Dari sisi pelanggan tidak ada bedanya. Yang berbeda adalah jumlah bagian yang harus dijalankan, diawasi, dan dirawat.

Kenapa microservices jadi jawaban default

Bentuk ini lahir dari masalah perusahaan besar. Kalau ada ratusan developer di satu kode yang sama, mereka saling menunggu. Satu tim tidak bisa merilis perbaikan kecil karena harus ikut jadwal rilis tim lain. Memecah sistem membuat setiap tim punya bagian sendiri dan bisa merilis kapan pun.

Masalah kedua soal beban. Di perusahaan dengan trafik sangat tidak merata, satu bagian sistem dipakai jauh lebih berat daripada bagian lain. Memisahkannya membuat bagian itu bisa diperbesar sendiri tanpa menggandakan seluruh aplikasi.

Dua masalah itu nyata, dan pemecahannya masuk akal untuk yang mengalaminya. Lalu caranya ditiru oleh tim yang tidak punya masalah seperti itu. Istilahnya juga enak dipakai di penawaran. Microservices terdengar lebih maju daripada "satu aplikasi", jadi kata itu ikut dipasang sebagai penanda bahwa vendornya mengikuti perkembangan. Sebelum menilai arsitekturnya, pastikan dulu bahwa membangun sendiri memang langkah yang tepat. Urutannya kami bahas di panduan pembangunan software custom.

Biaya dari memecah sistem jadi banyak bagian

Setiap layanan yang dipisah butuh proses rilis, pemantauan, dan log sendiri. Di atas itu ada soal yang lebih sulit: batas datanya harus jelas supaya dua layanan tidak mengubah angka stok yang sama. Tiga layanan berarti tiga rangkaian pekerjaan itu.

Mencari penyebab masalah juga jadi lebih panjang. Pada satu aplikasi, developer menelusuri satu jalur kode dari awal sampai akhir. Kalau ada lima layanan, satu pesanan yang gagal bisa berhenti di mana saja di antara lima aplikasi dan jaringan di antaranya. Developer harus menggabungkan log dari lima tempat dulu sebelum tahu bagian mana yang salah. Sementara itu admin melihat pesanan menggantung tanpa status, dan pelanggan menunggu jawaban yang belum bisa diberikan sampai penyebabnya ketemu.

Biayanya muncul di tiga pos: hosting, waktu pembangunan, dan perawatan setelah peluncuran. Hosting naik sebanding dengan jumlah layanan yang jalan: lima layanan berarti lima hal yang harus dibayar dan diawasi tiap bulan, bukan satu. Anggaran yang habis untuk perlengkapan itu tidak jadi fitur, dan halaman pesanan yang dipakai admin setiap hari selesai belakangan. Setelah peluncuran, pilihan orang yang sanggup merawatnya menyempit, dan itu yang paling terasa. Untuk bisnis yang tidak punya tim engineering sendiri, ini risiko yang paling mahal.

Kapan satu aplikasi utuh jadi pilihan yang tepat

Biasanya cirinya kelihatan dari bisnisnya: satu tim kecil mengerjakan satu produk, trafiknya masih nyaman di satu server, dan kebutuhannya masih bergerak karena bentuk akhir prosesnya belum pasti.

Pada keadaan seperti itu, pemisahan yang Anda butuhkan bisa dikerjakan di dalam satu aplikasi. Checkout, stok, dan invoice kami tulis sebagai modul terpisah di dalam satu aplikasi, masing-masing dengan datanya sendiri dan satu titik masuk yang dipanggil modul lain. Developer berikutnya bisa membaca satu modul tanpa memahami seluruh sistem, dan ia tetap bisa menjalankan semuanya di laptopnya sendiri untuk mencoba.

Kami menilai arsitektur dari apakah developer berikutnya bisa merawat sistemnya, bukan dari seberapa modern bentuknya. Karena itu kami membangun dengan teknologi yang umum dan sudah terbukti, lalu mencatat alasan di balik setiap keputusan di sebelah kodenya. Developer baru mewarisi pemikirannya juga, tidak hanya kumpulan file.

Tanda-tanda yang betul-betul membenarkan pemecahan

Ada keadaan yang membuat pemisahan layak dibayar. Cocokkan daftar ini dengan kondisi bisnis Anda, dan tanyakan ke orang yang memakai prosesnya setiap hari, karena pola pemakaian paling jelas terlihat dari sana.

• Satu bagian sistem punya pola beban yang tidak dimiliki bagian lain. Misalnya pencarian produk dipakai ribuan kali per jam, sementara pembuatan invoice jalan beberapa kali sehari.
• Satu bagian butuh bahasa atau runtime yang berbeda. Pengolahan gambar atau model AI kadang memang hidup di lingkungan lain.
• Ada tim terpisah yang memegang area terpisah, dan jadwal rilis mereka saling mengganggu.
• Satu bagian harus tetap jalan ketika bagian lain mati. Checkout yang tetap menerima pesanan walau sistem pelaporan sedang bermasalah termasuk di sini.

Kalau tidak ada satu pun dari empat keadaan ini di bisnis Anda, kemungkinan besar Anda membayar perlengkapan untuk masalah yang belum ada. Kalau prosesnya sudah selesai dengan alat siap pakai yang dijual bulanan, kami akan bilang begitu, dan pertanyaan arsitekturnya hilang sekaligus. Cara membandingkan dua pilihan itu kami uraikan di membangun sendiri atau pakai alat siap pakai.

Anda tidak harus memilih sekali untuk selamanya

Urutan yang biasanya paling murah dimulai dari satu aplikasi dengan batas internal yang rapi. Jalankan dulu, lihat bagian mana yang benar-benar berat dipakai, baru keluarkan bagian itu jadi layanan sendiri kalau memang terbukti perlu. Keluarkan satu bagian saja, jangan lima sekaligus.

Cara ini cocok dengan pembangunan yang dimulai kecil lalu ditambah sesuai pemakaian nyata. Alasannya kami bahas di membangun kecil dulu lalu berkembang.

Keputusan arsitektur bisa diubah kalau batas internalnya sudah rapi sejak awal, alasan keputusan pertamanya tercatat, dan kode serta akunnya atas nama Anda. Batas yang rapi membuat satu modul bisa dikeluarkan tanpa membongkar sisanya. Catatan alasan membuat orang berikutnya tahu apa yang dulu dipertimbangkan dan apa yang berubah sejak itu. Tanpa kepemilikan kode, server, domain, dan semua akun, perubahan arsitektur hanya bisa dikerjakan oleh vendor yang membuatnya, dan keputusannya pindah ke tangan mereka. Di Arktik semuanya atas nama Anda sejak hari pertama, jadi tidak ada yang bergantung pada kami masih ada atau tidak.

Pertanyaan untuk orang yang membangunnya

Anda tidak perlu menilai kodenya untuk menilai jawabannya, dan lima pertanyaan berikut sudah cukup.

• Apa yang rusak kalau sistem ini dibuat sebagai satu aplikasi, bukan lima?
• Berapa biaya hosting dan layanan per bulan untuk bentuk yang Anda usulkan, dibandingkan bentuk yang lebih sederhana?
• Siapa yang bisa merawat ini setelah handover, dan berapa banyak developer di pasar yang menguasai perlengkapannya?
• Di mana alasan keputusan ini dicatat, dan apakah saya bisa membacanya?
• Kalau nanti ternyata keliru, berapa besar pekerjaan untuk mengubahnya?

Bentuk jawabannya sudah memberi petunjuk. Jawaban yang bisa dipakai menyebut angka rupiah per bulan, nama teknologi, dan tempat catatannya. Jawaban yang perlu dicurigai hanya menyebut skalabilitas dan masa depan tanpa satu pun angka.

Bawa pertanyaan arsitektur Anda ke obrolan pertama

Tidak perlu menyiapkan istilah teknis. Ceritakan saja proses yang ingin Anda pindahkan ke software dan berapa orang yang akan memakainya. Kalau sudah ada penawaran dari pihak lain, bawa penawarannya. Kita bahas bentuk mana yang masuk akal untuk ukuran bisnis Anda, langsung dengan engineer yang akan mengerjakannya. Obrolan pertamanya gratis dan tanpa deck.

Kalau Anda sudah punya developer sendiri dan hanya butuh pendapat kedua atas satu keputusan arsitektur, kami juga melayani itu. Seluruh pembangunan tidak perlu diserahkan ke kami. Kalau memang perlu dibangun, discovery memberi rencana tertulis dan harga tetap. Dokumen itu milik Anda apa pun keputusan Anda setelahnya. Gunakan formulir kontak yang membuka WhatsApp, atau kirim email ke hello@arktik.id.