Arsitektur komposable adalah cara membangun sistem perangkat lunak dari komponen-komponen terbaik yang independen, dapat dipertukarkan, dan saling berkomunikasi melalui API, alih-alih satu platform besar serba ada. Ini adalah gagasan yang lebih luas di mana gerakan headless berada, dan terkait erat dengan MACH Alliance, badan industri netral vendor yang mempromosikan teknologi perusahaan yang terbuka dan komposable.
Disambiguasi singkat terlebih dahulu
Kata “komposable” muncul di tiga tempat yang sangat berbeda. Mari kita jelaskan sekarang agar sisa panduan ini masuk akal.
- Arsitektur komposable (artikel ini) adalah pendekatan desain perangkat lunak. Anda merakit aplikasi dari komponen bisnis terpisah, yang masing-masing terintegrasi melalui API.
- Infrastruktur komposable adalah konsep perangkat keras dan pusat data. Komputasi, penyimpanan, dan jaringan dikumpulkan dan dialokasikan ke beban kerja sesuai permintaan. Ini berada di bawah sistem operasi, bukan dalam kode aplikasi Anda.
- Komposabilitas DeFi adalah ide blockchain, sering disebut “lego uang.” Kontrak pintar seperti protokol pinjaman dan pertukaran bertumpuk satu sama lain untuk menciptakan produk keuangan baru.
Kata dasar yang sama, tiga lapisan yang tidak berhubungan. Selanjutnya, “komposable” berarti dalam pengertian arsitektur perangkat lunak.
Apa Arti Sebenarnya dari Arsitektur Komposable
Sistem komposable dibangun dari unit-unit modular, mandiri yang masing-masing memiliki fungsi bisnis lengkap. Anda memilih alat terbaik untuk setiap tugas, menghubungkannya melalui API, dan dapat menggantinya nanti tanpa membangun ulang segalanya di sekitarnya.
Unit komposisi memiliki nama: packaged business capability, atau PBC. Gartner mendefinisikan PBC sebagai kapabilitas yang dapat di-deploy secara independen yang mencakup data, logika, dan proses bisnis mandiri, serta berinteraksi dengan aplikasi lain melalui API dan saluran acara (event channels).
Bayangkan PBC sebagai keseluruhan domain bisnis dalam satu kotak. PBC “pembayaran” memiliki metode pembayaran, pemeriksaan penipuan, pengembalian dana, dan perselisihan. PBC “pencarian” memiliki pengindeksan, peringkat, dan penanganan kueri. Masing-masing mengekspos API tingkat bisnis, bukan tabel database mentah, dan Anda dapat memperolehnya dari vendor atau membangunnya sendiri. Anda menyusun produk Anda dari blok-blok ini seperti Anda merakit bagian-bagian dari satu kit.
Komposable vs Monolit
Monolit menggabungkan setiap kapabilitas ke dalam satu aplikasi yang dapat di-deploy dengan database bersama. Itu sederhana untuk memulai dan menjadi lebih sulit untuk diubah seiring pertumbuhannya. Arsitektur komposable memisahkan kapabilitas-kapabilitas tersebut sehingga masing-masing dapat berkembang secara mandiri. Jika Anda pernah membaca tentang perpecahan monolit versus microservices, komposable adalah pembingkaian kapabilitas bisnis dari pergeseran yang sama: microservices adalah dekomposisi teknis, PBC adalah dekomposisi domain bisnis.
Berikut adalah kontrasnya secara sekilas.
| Dimensi | Monolit | Arsitektur Komposable |
|---|---|---|
| Unit perubahan | Seluruh aplikasi | Satu PBC |
| Data | Satu database bersama | Setiap kapabilitas memiliki datanya sendiri |
| Pilihan vendor | Satu platform, ambil semuanya | Terbaik di kelasnya (best-of-breed) per kapabilitas |
| Front end | Terkait erat dengan back end | Terpisah, sejumlah saluran apa pun |
| Integrasi | Panggilan fungsi internal | API dan acara (events) |
| Risiko keterikatan vendor (lock-in) | Tinggi | Lebih rendah, komponen dapat diganti |
Ada pertukaran yang nyata. Komposable memberi Anda fleksibilitas dan kemampuan penggantian. Ini juga memberi Anda lebih banyak bagian bergerak untuk diintegrasikan, dipantau, dan dijaga dalam kontrak.
MACH: Standar yang dimaksud kebanyakan orang
Ketika tim mengatakan “komposable,” mereka biasanya merujuk pada tumpukan yang mengikuti prinsip MACH. MACH adalah akronim, dan MACH Alliance (didirikan pada tahun 2020) mempromosikannya sebagai arsitektur untuk sistem yang terbuka dan komposable.
- M, Microservices. Kapabilitas dibangun sebagai layanan kecil yang dapat di-deploy secara independen daripada satu blok.
- A, API-first. Setiap fungsi diekspos melalui API. UI hanyalah salah satu konsumen dari API tersebut, bukan satu-satunya jalan masuk.
- C, Cloud-native. Komponen dibangun untuk cloud, menggunakan penskalaan elastis dan layanan terkelola.
- H, Headless. Front end dipisahkan dari back end, sehingga Anda dapat mengirimkan ke web, mobile, kios, atau apa pun dari API yang sama.
Perhatikan bahwa komposable, headless, dan MACH bukanlah sinonim. Headless adalah satu huruf dari MACH. MACH adalah cara spesifik dan berpendapat untuk membangun sistem komposable. Komposable adalah payung yang mencakup semua itu.
Tulang Punggung API-first
Tarik salah satu dari benang ini dan Anda akan sampai pada poin yang sama: API adalah lapisan integrasi yang menyatukan sistem komposable. Jika komponen-komponen bersifat independen dan masing-masing memiliki datanya sendiri, satu-satunya hal yang menghubungkan mereka adalah kontrak di antara mereka.
Itulah mengapa pengembangan API-first adalah pilar yang tidak dapat ditawar. Dalam monolit, dua modul dapat mengakses database yang sama dan saling memanggil fungsi secara langsung. Dalam sistem komposable, jalan pintas itu hilang. Suatu kapabilitas hanya akan berguna sejauh API yang dieksposnya, dan suatu sistem hanya akan stabil sejauh kontrak di antara bagian-bagiannya.
Ini juga saat di mana API tidak lagi menjadi pintu samping dan menjadi produk itu sendiri. Ketika front end bersifat headless dan kapabilitas dapat ditukar, API adalah produk yang sebenarnya dikonsumsi oleh tim dan mitra Anda. Rancanglah dengan sembarangan dan setiap konsumen di hilir akan merasakannya.
Manfaat dan Pertukaran
Singkatnya, argumen untuk komposable:
- Terbaik di kelasnya (Best-of-breed). Gunakan alat terkuat untuk setiap kapabilitas alih-alih puas dengan modul terlemah dari satu vendor.
- Perubahan independen. Ganti atau tingkatkan satu PBC tanpa menyentuh bagian lainnya.
- Kurang keterikatan vendor (lock-in). Komponen yang dapat ditukar berarti Anda tidak terikat pada satu platform.
- Tim paralel. Kapabilitas yang terpisah memungkinkan tim untuk melakukan rilis sesuai jadwal mereka sendiri.
- Multi-saluran. Front end headless memungkinkan satu set API melayani banyak permukaan (channel).
Dan biaya jujurnya:
- Overhead integrasi. Lebih banyak komponen berarti lebih banyak koneksi untuk dihubungkan dan dipantau.
- Disiplin kontrak. Perubahan yang merusak pada satu API dapat menyebar ke semua yang memanggilnya.
- Kompleksitas operasional. Pemantauan, otentikasi, dan pembuatan versi mencakup banyak layanan, bukan hanya satu.
- Desain awal. Anda menghabiskan lebih banyak waktu untuk batasan dan kontrak sebelum Anda melakukan rilis.
Komposable sangat cocok ketika Anda membutuhkan fleksibilitas, skala, dan multi-saluran. Ini berlebihan jika monolit tunggal yang dibangun dengan baik sudah cukup.
Posisi Apidog: pilar API-first
Apidog tidak membuat arsitektur Anda menjadi komposable. Ini bukan CMS, mesin perdagangan, API gateway, atau platform MACH, dan tidak akan menggantikan salah satu dari itu. Yang dilakukannya adalah memiliki huruf “A” dalam MACH, pilar API-first, yang merupakan lapisan tempat semua hal lain dalam sistem komposable bergantung.
Karena API adalah satu-satunya antarmuka antara komponen-komponen independen Anda, kontrak harus tepat. Apidog adalah tempat Anda merancang, menguji, membuat mock, dan mendokumentasikan kontrak tersebut:
- Kontrak design-first. Definisikan API setiap kapabilitas sebagai kontrak OpenAPI sebelum siapa pun menulis implementasinya, sehingga konsumen dan penyedia menyepakati bentuknya di awal.
- Server mock. Tim yang terpisah tidak perlu saling menunggu. Server mock memungkinkan front-end atau mitra untuk membangun berdasarkan kontrak sementara PBC pendukung masih dibangun.
- Eksekusi pengujian tanpa kepala (headless). CLI Apidog menjalankan pengujian API Anda tanpa GUI, langsung di CI. Itu adalah rima konseptual yang nyata dengan “headless,” pengujian berjalan berdasarkan kontrak, bukan melalui layar.
- Kelola dari alat Anda. Melalui MCP, Anda dapat menggerakkan proyek API Anda dari agen AI atau IDE.
Jika sistem Anda mengikuti model API adalah produk, ini adalah lapisan kualitas yang menjaga kontrak tetap jujur. Unduh Apidog untuk merancang dan membuat mock kontrak sebelum backend ada.
Kapan Mengadopsi Arsitektur Komposable
Gunakan komposable ketika lebih dari satu hal berikut ini benar:
- Anda perlu melayani beberapa saluran (web, mobile, toko fisik, suara) dari logika yang dibagikan.
- Kapabilitas yang berbeda berubah dengan kecepatan yang sangat berbeda, dan Anda lelah mendeploy ulang semuanya untuk perbaikan kecil.
- Anda menginginkan vendor terbaik di kelasnya (best-of-breed) untuk setiap kapabilitas alih-alih satu suite lengkap.
- Keterikatan vendor (vendor lock-in) merupakan risiko bisnis yang nyata bagi Anda.
- Anda memiliki tim dan disiplin untuk mengelola kontrak API dan integrasi seiring waktu.
Jika Anda adalah tim kecil yang merilis satu produk dengan jadwal ketat, monolit yang bersih seringkali merupakan pilihan yang lebih cerdas. Komposable menunjukkan kompleksitasnya pada skala besar.
Pertanyaan yang Sering Diajukan
Apakah arsitektur komposable sama dengan microservices?
Tidak, tetapi keduanya tumpang tindih. Microservices adalah cara teknis untuk memecah sistem menjadi layanan-layanan kecil yang dapat di-deploy. Arsitektur komposable memecah berdasarkan kapabilitas bisnis (PBC) dan menambahkan ide komponen terbaik di kelasnya yang dapat ditukar dan dihubungkan oleh API. Microservices biasanya adalah cara Anda membangun back end dari sistem komposable. Untuk perbedaan yang lebih luas, lihat monolit versus microservices.
Apa perbedaan antara komposable dan headless?
Headless berarti front end dipisahkan dari back end, sehingga klien mana pun dapat mengonsumsi API yang sama. Komposable adalah pendekatan yang lebih luas: merakit seluruh sistem dari kapabilitas independen yang terhubung API. Headless adalah salah satu prinsip (huruf “H” dalam MACH) yang cenderung diikuti oleh sistem komposable. Anda bisa menjadi headless pada satu kapabilitas tanpa sepenuhnya komposable di seluruh tumpukan.
Apa itu packaged business capability (PBC)?
PBC adalah unit mandiri yang memiliki fungsi bisnis lengkap, termasuk data, logika, dan API-nya. Gartner menggambarkan PBC sebagai kapabilitas yang dapat di-deploy secara independen yang berinteraksi dengan aplikasi lain melalui API dan saluran acara (event channels). Komponen “pencarian,” “pembayaran,” atau “inventaris,” yang masing-masing mengekspos API tingkat bisnis, adalah PBC yang khas.
Apakah saya membutuhkan platform API untuk menjadi komposable?
Anda membutuhkan cara untuk merancang, menguji, dan menjaga kontrak API Anda stabil, karena kontrak-kontrak itulah satu-satunya hal yang menyatukan komponen-komponen independen. Itu bisa berupa seperangkat alat terpisah atau satu platform yang mencakup desain, mocking, pengujian, dan dokumentasi di satu tempat. Intinya adalah disiplin kontrak, bukan produk tertentu.
Ringkasan
Arsitektur komposable adalah genusnya, dan headless, MACH, serta microservices adalah spesies di dalamnya. Garis besarnya sederhana: kapabilitas independen, pilihan terbaik di kelasnya (best-of-breed), dan API sebagai jaringan penghubung. Bagian terakhir itulah tempat sebagian besar risiko berada, karena kontrak adalah sistemnya. Lakukan desain API, mocking, pengujian, dan dokumentasi dengan benar menggunakan alat seperti Apidog, dan sisa janji komposable (dapat ditukar, multi-saluran, bebas keterikatan vendor) memiliki dasar yang kuat untuk berdiri.