Back to IF3110 Pengembangan Aplikasi Berbasis Web
Topic
Questions/Cues
Apa itu Monolith?
Single-Process Monolith?
Modular Monolith?
Distributed Monolith?
Masalah Monolith: Delivery Contention?
Masalah: Arsitektur vs Organisasi?
(Conway’s Law)
Kelebihan Monolith?
Reference Points
- Slides IF3110-11b-Intro-to-Microservices-Arch.pdf (Slide 12-19)
Definisi Monolith
Microservices sering didiskusikan sebagai alternatif dari arsitektur monolithic.
Monolith adalah sebuah sistem di mana semua fungsionalitas harus di-deploy bersama-sama sebagai satu unit deployment tunggal.
Jenis-Jenis Monolith
Single-Process Monolith:
Contoh paling umum. Semua kode (UI, business logic, database access) digabung dan dijalankan sebagai satu proses tunggal.
Biasanya terhubung ke satu database besar.
Modular Monolith:
Varian dari single-process monolith di mana kode di dalamnya dibagi menjadi modul-modul terpisah (misal: modul Shipping, modul Inventory).
Setiap modul bisa dikerjakan secara independen, TAPI semuanya tetap harus digabung untuk di-deploy sebagai satu proses.
Ini adalah arsitektur yang sangat baik, bisa memiliki database terpisah per modul atau database bersama.
Distributed Monolith:
Sistem yang terdiri dari beberapa layanan terdistribusi (terlihat seperti microservices), TAPI karena satu dan lain hal (misal: shared database, komunikasi yang tightly coupled), seluruh sistem harus di-deploy bersama-sama.
Gagal memberikan kelebihan SOA/Microservices (seperti independent deployability) namun memiliki semua kekurangan sistem terdistribusi (kompleksitas, latensi).
Masalah Utama Monolith
Delivery Contention (Perselisihan Pengiriman):
- Ini adalah masalah **organisasi**. - Semakin banyak orang bekerja di _codebase_ yang sama, mereka akan **saling menghalangi** satu sama lain. - Contoh: Tim A ingin _merilis_ fitur baru, tapi Tim B menemukan _bug_ kritis yang memaksa _deployment_ ditunda. Tim A jadi terhambat. - _Microservices_ memberikan **batasan yang konkret** (layanan) di mana garis kepemilikan tim dapat ditarik, mengurangi masalah ini.Alignment of Architecture and Organization (Hukum Conway):
Model Tradisional (Monolith): Organisasi dibagi berdasarkan lapisan teknis.
Tim Frontend (mengurus UI)
Tim Backend (mengurus Business Logic)
Tim DBA (mengurus Database)
Masalah: Perubahan sederhana (misal: “tambah tombol genre”) memerlukan koordinasi dan tiket antar tiga tim. Ini sangat lambat.
Model Microservice: Organisasi dibagi berdasarkan domain bisnis.
Tim Stock (mengurus UI, logic, & DB untuk Stock)
Tim Purchase (mengurus UI, logic, & DB untuk Purchase)
Tim Profile (mengurus UI, logic, & DB untuk Profile)
Hasil: Tim “Profile” dapat mengimplementasikan fitur “tambah tombol genre” secara independen tanpa perlu bicara dengan tim lain. Ini sangat cepat.
Kelebihan Monolith
Monolith bukanlah arsitektur yang buruk. Ia memiliki beberapa kelebihan signifikan:
Topologi Deployment Sederhana: Jauh lebih mudah dioperasikan. Tidak ada masalah latency jaringan, service discovery, dll.
Alur Kerja Developer Sederhana: Developer hanya perlu menjalankan satu proses di mesin lokal.
Monitoring & Testing Sederhana: Troubleshooting dan end-to-end testing jauh lebih mudah karena semua terjadi dalam satu proses.
Code Reuse Sederhana: Jika Anda butuh fungsi dari modul lain, Anda tinggal memanggilnya. Tidak perlu membuat API, library, atau menyalin kode.
Monolith adalah arsitektur di mana semua fungsionalitas digabung menjadi satu unit deployment tunggal. Variannya termasuk Single-Process (satu proses), Modular (kode terstruktur, tapi deploy tunggal), dan Distributed Monolith (sistem terdistribusi yang gagal deploy mandiri). Masalah utama monolith bersifat organisasi, yaitu delivery contention (tim saling menghalangi) yang disebabkan oleh struktur tim yang selaras dengan lapisan teknis (Frontend, Backend, DBA) bukannya domain bisnis. Namun, monolith memiliki kelebihan besar dalam hal kesederhanaan deployment, monitoring, testing, dan code reuse.
Additional Information
Topik Teknis: Hukum Conway (Conway’s Law)
Diagram di slide 12 adalah ilustrasi sempurna dari “Hukum Conway”, yang menyatakan:
“Setiap organisasi yang merancang sistem… akan menghasilkan desain yang strukturnya adalah salinan dari struktur komunikasi organisasi tersebut.”
Jika Anda memiliki 3 tim (Frontend, Backend, DBA), Anda pasti akan menghasilkan arsitektur 3-lapis (3-tier) monolith, karena begitulah cara tim tersebut harus berkomunikasi.
Jika Anda ingin membangun microservices, Anda harus terlebih dahulu mengubah struktur organisasi Anda menjadi tim-tim kecil yang otonom dan cross-functional (misal: “Tim Shipping” yang berisi engineer frontend, backend, dan DB).
Inilah mengapa slide 30 menyebut microservices adalah solusi untuk masalah organisasi, bukan hanya masalah teknis.