Arsitektur MACH tidak ada hubungannya dengan angka Mach (ukuran kecepatan) atau kernel Mach yang berada di bawah GNU Hurd; ini adalah akronim untuk membangun perangkat lunak perusahaan dari bagian-bagian yang dapat diganti. MACH adalah singkatan dari Microservices, API-first, Cloud-native, dan Headless, dan dipromosikan oleh MACH Alliance, sebuah badan industri nirlaba yang dibentuk pada tahun 2020. Panduan ini mendefinisikan setiap pilar dalam bahasa sederhana, membandingkan MACH dengan pendekatan monolit dan SOA yang digantikannya, serta menunjukkan di mana posisinya, termasuk melihat platform API yang akan Anda gunakan untuk ekosistem microservices.
Apa Arti MACH Sebenarnya
MACH adalah seperangkat prinsip desain, bukan produk yang bisa Anda beli. Setiap huruf mewakili satu prinsip, dan sebuah sistem hanya dianggap MACH jika mengikuti keempatnya. MACH Alliance sangat ketat dalam hal ini: menunjukkan satu atau dua ciri saja tidak memenuhi syarat.
Berikut singkatan tersebut secara sekilas.
| Huruf | Prinsip | Artinya |
|---|---|---|
| M | Microservices | Setiap kapabilitas bisnis adalah layanan yang dapat di-deploy secara independen |
| A | API-first | Setiap fungsi diekspos melalui API, dirancang sebelum kode |
| C | Cloud-native | Dibangun untuk berjalan sebagai SaaS di infrastruktur cloud, elastis dan terkelola |
| H | Headless | Front end terpisah dari back end dan berkomunikasi melalui API |
Idenya adalah kompositabilitas. Alih-alih satu produk besar yang melakukan segalanya, Anda merakit layanan terbaik di kelasnya yang masing-masing melakukan satu hal, dan Anda dapat menukar salah satu di antaranya tanpa membangun ulang sisanya. Itu adalah tujuan yang sama di balik gerakan "perusahaan kompositabel" yang lebih luas; MACH adalah resep teknis yang memungkinkan kompositabilitas.
Mikroservis
Monolit menggabungkan setiap fitur ke dalam satu basis kode dan satu deployment. Mikroservis memisahkannya. Logika katalog, keranjang belanja, pencarian, dan pembayaran Anda masing-masing menjadi layanan terpisah dengan data dan siklus rilisnya sendiri. Satu tim dapat merilis layanan pencarian pada hari Selasa tanpa menyentuh layanan keranjang belanja sama sekali.
Kompensasinya adalah kompleksitas operasional. Anda sekarang menjalankan banyak layanan, banyak basis data, dan banyak panggilan jaringan di antara mereka. Jika Anda ingin versi lengkapnya, lihat aplikasi monolit vs. mikroservis.
Utamakan API
Utamakan API berarti API adalah titik awal, bukan sekadar pelengkap. Anda merancang kontrak, endpoint, bentuk permintaan dan respons, sebelum ada yang menulis implementasinya. Setiap kapabilitas dalam sistem MACH mencapai dunia luar melalui API tersebut, sehingga kontrak menjadi permukaan produk yang sebenarnya.
Ini adalah pilar yang paling memengaruhi cara tim bekerja sehari-hari, dan di sinilah tooling paling berperan. Kita akan membahasnya lagi di bawah. Untuk prinsip-prinsipnya, pengembangan API-first mencakup dasarnya.
Cloud-native
Cloud-native dalam konteks MACH sangat condong ke arah SaaS. Komponen-komponennya dibangun untuk berjalan di infrastruktur cloud dan biasanya dikonsumsi sebagai layanan terkelola. Anda tidak perlu menambal server atau merencanakan kapasitas untuk lonjakan lalu lintas; layanan akan berskala secara elastis dan vendor yang menangani pembaruan. Ini berbeda dengan "kami memindahkan aplikasi lama kami ke VM di cloud." Cloud-native berarti perangkat lunak dirancang untuk lingkungan tersebut sejak awal.
Headless
Headless memisahkan lapisan presentasi dari logika bisnis. Back end tidak memiliki front end bawaan; ia hanya menyajikan data dan operasi melalui API. Situs web, aplikasi seluler, jam tangan pintar, kios, atau asisten suara Anda masing-masing mengonsumsi API yang sama dan menampilkan pengalaman mereka sendiri.
Manfaatnya adalah jangkauan. Satu back end dapat melayani banyak front end, dan Anda dapat mendesain ulang tampilan toko tanpa memigrasi mesin perdagangan di bawahnya. Sebuah API headless menjadi produk karena itu adalah satu-satunya cara untuk mengaksesnya.
MACH vs. Monolit vs. SOA
Ada baiknya melihat posisi MACH dibandingkan dengan pola-pola yang ada sebelumnya.
| Monolit | SOA | MACH | |
|---|---|---|---|
| Unit deployment | Satu aplikasi | Layanan kasar di bus | Mikroservis berbutir halus |
| Integrasi | Panggilan dalam proses | Enterprise service bus, seringkali SOAP | API REST/GraphQL yang ringan |
| Front end | Terkopel, dirender server | Seringkali terkopel | Headless, sepenuhnya terpisah |
| Hosting | Server yang Anda kelola | On-prem atau dihosting | SaaS Cloud-native |
| Menukar komponen | Membangun ulang dan mendeploy ulang | Sulit, terkopel bus | Ganti satu layanan |
Monolit cepat untuk dimulai dan mudah dipahami, itulah mengapa masih menjadi pilihan tepat bagi banyak tim kecil. SOA mencoba menguraikan sistem satu dekade sebelumnya tetapi seringkali memusatkan segalanya pada bus layanan yang berat, yang menjadi bottleneck-nya sendiri. MACH mempertahankan ide dekomposisi dan menghilangkan bus, menghubungkan layanan dengan API sederhana dan mendorong hosting ke cloud.
MACH pada dasarnya adalah jawaban modern era cloud untuk pertanyaan yang diajukan SOA. Jika Anda ingin peta gaya yang lebih luas, gaya arsitektur API menyajikannya.
Kapan Mengadopsi MACH (dan Kapan Tidak)
MACH memecahkan masalah nyata, tetapi tidak gratis. Adopsi jika kendalanya sesuai.
- Anda mencapai batas platform monolitik, dan siklus rilis lambat karena semuanya dirilis bersamaan.
- Beberapa tim perlu bekerja secara paralel tanpa saling mengganggu.
- Anda melayani konten atau perdagangan ke beberapa saluran (web, seluler, di toko) dan menginginkan satu back end di belakang semuanya.
- Anda ingin menukar vendor untuk satu kapabilitas tanpa perlu replatforming penuh.
Pikirkan dua kali jika:
- Anda adalah tim kecil dengan produk sederhana. Overhead operasional dari banyak layanan, pipeline, dan kontrak akan lebih memperlambat Anda daripada monolit.
- Anda belum memiliki keterampilan platform. MACH mengasumsikan kenyamanan dengan infrastruktur cloud, CI/CD, dan desain API.
- Lalu lintas dan tim Anda stabil dan sederhana. Fleksibilitas yang Anda bayarkan mungkin tidak pernah terpakai.
Jalan yang umum dan jujur adalah memulai dengan monolit yang terstruktur dengan baik, lalu melepaskan layanan saat muncul masalah spesifik. Anda tidak harus langsung menerapkan MACH sepenuhnya pada hari pertama.
Ekosistem Tooling
MACH dirancang untuk bersifat netral vendor, tetapi arsitektur tipikal mengambil dari beberapa kategori:
- CMS Headless untuk konten, seperti Contentstack atau Contentful.
- Mesin commerce headless atau kompositabel seperti commercetools.
- Pencarian dan personalisasi sebagai layanan API terpisah.
- CDN dan edge untuk pengiriman cloud-native, seringkali dipasangkan dengan front end bergaya Jamstack. Dokumentasi Jamstack Netlify adalah referensi yang berguna untuk sisi front end yang terpisah.
- API gateway dan identitas untuk merutekan, mengamankan, dan mengautentikasi lalu lintas antar layanan.
Benang yang mengikat semuanya adalah API. Setiap kotak dalam daftar itu berkomunikasi dengan yang lain melalui kontrak, sehingga kualitas kontrak-kontrak tersebut menentukan apakah seluruh sistem akan bertahan.
Di Mana Kontrak API Menjadi Produk
Ini adalah "A" dalam MACH, dan ini adalah bagian yang paling Anda kontrol secara langsung. Dalam sistem mikroservis headless, tidak ada yang menyentuh layanan Anda melalui UI yang Anda bangun. Mereka menyentuh API. Jadi, kontrak adalah produk, dan membutuhkan perhatian yang sama seperti produk apa pun: desain, mock, pengujian, dan dokumentasi.
Apidog adalah lapisan kualitas API untuk pekerjaan tersebut. Ini bukan CMS, mesin commerce, atau gateway, dan tidak "melakukan" MACH atau headless untuk Anda. Di sinilah Anda menangani kontrak itu sendiri:
- OpenAPI yang mengutamakan desain. Anda mendefinisikan kontrak setiap mikroservis di Apidog sebelum implementasi, sehingga tim pengonsumsi menyepakati bentuknya di awal.
- Server mock. Apidog membuat mock dari spesifikasi, sehingga tim front end dapat membangun terhadap API keranjang sebelum layanan keranjang ada. Tim yang tidak terikat berhenti saling memblokir.
- Eksekusi pengujian headless. Apidog CLI menjalankan pengujian API Anda tanpa GUI, langsung di CI, yang sesuai dengan sistem headless: kontrak diverifikasi oleh mesin, bukan diklik secara manual.
- MCP untuk agen. Melalui MCP, Anda dapat mengelola dan mengkueri API dari agen AI atau IDE Anda, sehingga kontrak tetap dapat diakses dari alat yang sudah digunakan tim Anda.
Itu menjaga Apidog jujur tentang perannya. Ia memiliki pilar API-first, sehingga layanan Anda tetap dijelaskan dengan baik, dapat diuji, dan dapat di-mock di seluruh ekosistem. Pemikiran yang sama muncul dalam API sebagai produk, yang persis seperti pola pikir yang dipaksakan MACH pada Anda. Ingin mencobanya? Unduh Apidog dan arahkan ke spesifikasi salah satu layanan.
Pertanyaan yang Sering Diajukan
Apakah MACH Sama dengan Arsitektur Kompositabel?
Keduanya terkait erat tetapi tidak identik. Arsitektur kompositabel adalah gagasan bisnis yang lebih luas: membangun tumpukan Anda dari bagian-bagian yang dapat dipertukarkan yang dapat Anda gabungkan kembali. MACH adalah pola teknis spesifik (mikroservis, API-first, cloud-native, headless) yang membuat kompositabilitas dapat dicapai. Anda dapat menganggap MACH sebagai cetak biru rekayasa untuk perusahaan kompositabel.
Apakah Saya Perlu Menjadi Anggota MACH Alliance untuk Menggunakan MACH?
Tidak. MACH Alliance adalah organisasi nirlaba yang mensertifikasi vendor berdasarkan empat prinsip, yang membantu pembeli menemukan produk yang benar-benar kompositabel. Anda dapat membangun sistem MACH sepenuhnya dari alat non-anggota, atau bahkan layanan Anda sendiri. Prinsip-prinsipnya terbuka; keanggotaan adalah sertifikasi vendor, bukan lisensi untuk menggunakan pola tersebut.
Bagaimana MACH Berbeda dari Penyiapan Mikroservis Biasa?
Mikroservis adalah salah satu dari empat pilar MACH, bukan keseluruhan. Back end mikroservis dengan front end yang sangat terkopel dan hosting on-prem bukanlah MACH. MACH menambahkan disiplin API-first, model SaaS cloud-native, dan decoupling headless di atasnya. Jika Anda memilih infrastruktur untuk layanan, cara memilih platform API untuk mikroservis menjelaskan apa yang perlu dipertimbangkan.
Apakah MACH Hanya untuk E-commerce?
Ini dimulai di bidang perdagangan, di mana menukar vendor checkout atau pencarian tanpa replatform memiliki nilai yang jelas, tetapi pola ini berlaku di mana pun Anda melayani banyak saluran dari logika back end bersama. Produk media, perbankan, perjalanan, dan SaaS semuanya menggunakan decoupling gaya MACH.
Menyatukan Semuanya
MACH adalah cara membangun perangkat lunak dari bagian-bagian yang dapat Anda ganti: mikroservis untuk deployment independen, API-first sehingga setiap kapabilitas memiliki kontrak yang jelas, cloud-native sehingga berskala sebagai SaaS, dan headless sehingga satu back end melayani banyak front end. Ini sangat kuat ketika Anda memiliki skala dan tim untuk menggunakannya, dan berlebihan jika Anda tidak memilikinya.
Ke mana pun Anda condong, kontrak API adalah bagian penopang beban. Ketika kontrak adalah produk, desainlah dengan baik, buat mock sejak awal, dan uji di CI. Apidog memberi Anda lapisan kualitas API tersebut sehingga ekosistem MACH Anda tetap dijelaskan dengan baik dari layanan pertama hingga terakhir.