Hubungi kami untuk penawaran FinMV yang disesuaikan dengan kebutuhan Anda.
Direktur teknis perusahaan Anda, saat merencanakan peluncuran platform keuangan, harus memilih opsi arsitektur proyek. Pilihan arsitektur apa yang tersedia untuknya dan mana yang lebih baik untuk dipilih?
Arsitektur monolitik seperti bola salju. Anda memulai sebuah proyek dan Anda memiliki sedikit bola salju. Ini sangat kecil sehingga dapat dikembangkan dan digulirkan oleh tim kecil. Beberapa tahun berlalu, dan sekarang bola salju Anda telah menjadi sangat besar sehingga 20 pengembang telah mendorongnya. Dalam beberapa tahun lagi, ratusan pengembang akan meluncurkan bola salju Anda dengan banyak kode, tetapi peluncuran fitur baru akan menjadi sangat lambat.
Akibatnya, pemilik mulai mengganti direktur teknis, anggota tim, tetapi itu semakin memburuk. Anggota tim baru tidak tahu detail sejarah, mengapa bola salju seperti itu dan bukan yang lain. Dokumentasi produk dengan cepat menjadi usang.
Mengapa tidak melakukannya dengan benar dari awal? Pertama, di awal sebuah bisnis, selalu ada sumber daya yang terbatas, tidak ada cukup pengembang, keahlian, dan waktu. Manual ini mendesak, dan para pemrogram sedang terburu-buru untuk melakukannya secepat mungkin.
Kedua, insinyur teknis berpikir: "Baiklah, biarkan arsitektur monolitik untuk saat ini, tetapi ketika bisnis tumbuh, maka kami akan mengulang semuanya". Sayangnya, pada kenyataannya, mentransfer proyek monolitik yang ada ke arsitektur layanan mikro akan puluhan kali lebih sulit daripada menulis semuanya dari awal.
Kami akan segera membuat platform keuangan Anda berdasarkan arsitektur layanan mikro.
Arsitektur layanan mikro dapat dibandingkan dengan paving slab di jalan setapak. Saat proyek Anda berkembang, lebih banyak ubin ditambahkan ke jalan Anda. Jika ada komponen yang kedaluwarsa, cukup mengganti ubin ini dengan yang baru.
Arsitektur ini memiliki banyak kelebihan, tetapi saya akan menyebutkan yang paling penting:
Contoh pertama. Manajemen platform pinjaman P2P dengan sejumlah besar pengguna memutuskan untuk memasuki pasar negara-negara dengan mata uang yang berbeda. Platform ini memiliki arsitektur monolitik dan hanya mencakup satu mata uang - euro, dan untuk memasuki pasar Swedia (kroner Swedia), Polandia (Zloty Polandia), Republik Ceko (mahkota Ceko) perlu untuk memperkenalkan multicurrency.
Butuh waktu berbulan-bulan bagi seluruh tim untuk menerapkan fungsi ini, dan pengembangan fungsi baru semakin melambat. Dalam hal arsitektur layanan mikro, semuanya akan jauh lebih mudah dan lebih cepat.
Contoh kedua. Awalnya, pembuat situs diluncurkan dalam bahasa asli dan pengelolaannya tidak akan meluas ke pasar lain. Proyek ini memiliki arsitektur monolitik, dan fungsionalitasnya berkembang pesat. Skema platform adalah web yang kompleks di mana semuanya terhubung ke segalanya. Suatu hari, bisnis memutuskan untuk merilis versi platform dalam bahasa lain. Pada awalnya, tampaknya cukup untuk menambahkan hanya file bahasa dan sekarang kita akan menerjemahkan seluruh antarmuka.
Dalam praktiknya, seluruh proyek harus dikerjakan ulang. Misalnya, nama perusahaan dan produk dalam database sekarang harus disimpan tidak hanya dalam satu bahasa, tetapi dalam setiap bahasa. Tidak mungkin untuk menggandakan informasi karena logika bisnis, perlu untuk menyimpan nama untuk semua bahasa sekaligus. Dengan demikian, hal ini menyebabkan perubahan antarmuka kabinet dan back office. Perubahan antarmuka memerlukan perubahan aturan untuk memvalidasi data yang masuk, templat surat karena prinsip akhiran yang berbeda dalam bahasa yang berbeda, mengubah tes, dll.
Karena semuanya terhubung ke semuanya, keputusan dibuat untuk pindah ke arsitektur layanan mikro bersama dengan peluncuran bahasa baru. Proses transisi dari arsitektur monolitik ke layanan mikro membutuhkan waktu lebih dari satu tahun.
Contoh ketiga. Platform fintech dibuat dengan PHP dan Laravel versi lama. Memutakhirkan ke versi yang lebih baru, serta mengubah database dari MariaDB ke PostgreSQL, hampir tidak mungkin, karena seluruh tim hanya harus menangani proses migrasi selama beberapa bulan.
Versi baru PHP dan Laravel pada saat itu dapat mempercepat proyek dan pengembangan lebih lanjut, tetapi arsitektur monolitik tidak mengizinkan pembaruan tumpukan teknologi
.
