Back to IF3110 Pengembangan Aplikasi Berbasis Web
Topic
Questions/Cues
5 Kelebihan Microservices?
Technology Heterogeneity?
Scaling?
Ease of Deployment?
Organizational Alignment?
Composability?
8 Kerugian (Pain Points)?
Developer Experience?
Technology Overload?
Cost?
Reporting?
Monitoring / Troubleshooting?
Security?
Testing?
Latency & Data Consistency?
Kesimpulan: Haruskah pakai?
Alternatif: Monolith First?
Reference Points
- Slides IF3110-11b-Intro-to-Microservices-Arch.pdf (Slide 22-31)
5 Kelebihan Utama Microservices
Technology Heterogeneity (Keberagaman Teknologi):
Kita bisa memilih tools yang tepat untuk pekerjaan yang tepat.
Contoh: Layanan
Postspakai Ruby (dengan Document store), layananFriendspakai Golang (dengan Graph DB), layananPicturespakai Java (dengan Blob store).Scaling (Penskalaan):
Dengan layanan yang lebih kecil, kita bisa men-scale hanya layanan yang membutuhkan.
Contoh: Jika layanan
Picturessangat sibuk, kita bisa menjalankan 6 instancePictures, sementaraPosts(3 instance) danFriends(2 instance) tetap sedikit. Di monolith, kita harus men-scale semuanya bersama-sama.Ease of Deployment (Kemudahan Deployment):
Perubahan 1 baris di monolith 1 juta baris mengharuskan seluruh aplikasi di-deploy ulang (risiko tinggi).
Di microservices, kita bisa ubah 1 layanan dan men-deploy hanya layanan itu (risiko rendah, independen).
Organizational Alignment (Kesejajaran Organisasi):
Tim yang lebih kecil yang bekerja di codebase yang lebih kecil cenderung lebih produktif.
Microservices memungkinkan kita menyelaraskan arsitektur dengan organisasi (tim per domain bisnis).
Composability (Dapat Disusun):
Membuka peluang untuk reuse fungsionalitas. Fungsionalitas (misal: layanan
Shipping) dapat dikonsumsi dengan cara yang berbeda oleh konsumen yang berbeda (misal: oleh aplikasi web internal dan aplikasi mobile eksternal).Kerugian / Pain Points Microservices
Microservices memiliki biaya dan kompleksitas yang tinggi.
Developer Experience: Bisa jadi sulit. Menjalankan 50 microservices di 1 laptop developer bisa sangat berat.
Technology Overload: Terlalu banyak teknologi baru (Docker, Kubernetes, gRPC, Kafka, dll) yang harus dipelajari.
Cost: Biaya meningkat. Kita menjalankan lebih banyak proses, butuh lebih banyak server, mungkin lebih banyak lisensi software, dan ada biaya waktu untuk mempelajari semua ini.
Reporting: Menjadi jauh lebih sulit. Di monolith, data ada di satu database (mudah di-JOIN). Di microservices, data tersebar di puluhan database yang terisolasi.
Monitoring & Troubleshooting: Jauh lebih kompleks. Jika sebuah request gagal, di mana letak kegagalannya? (di layanan A, B, atau C?). Butuh tools distributed tracing.
Security: Permukaan serangan lebih luas. Kita harus mengamankan komunikasi data antar layanan di jaringan (data in transit).
Testing: End-to-end testing menjadi mimpi buruk karena harus men-deploy dan mengkonfigurasi banyak layanan yang berbeda hanya untuk 1 skenario tes.
Latency & Data Consistency: Masalah inti dari sistem terdistribusi.
Latency: Panggilan fungsi in-process di monolith sangat cepat. Panggilan API antar layanan via jaringan jauh lebih lambat.
Data Consistency: Menjaga konsistensi data di banyak database (transaksi terdistribusi) adalah masalah yang sangat sulit (seringkali harus menerima eventual consistency).
Kesimpulan: Haruskah Saya Menggunakan Microservices?
Bukan default: Ini adalah sebuah pendekatan, bukan satu-satunya pendekatan.
Masalah Organisasi: Microservices seringkali merupakan solusi untuk masalah organisasi (memungkinkan tim besar bekerja paralel), BUKAN masalah teknis.
Bertahan dengan Monolith:
Kecuali Anda punya alasan yang sangat kuat, berhati-hatilah.
Ada banyak keuntungan membangun Monolith First. Jauh lebih sederhana untuk dioperasikan dan dipahami.
Modular Monolith: Anda dapat mengatasi banyak tantangan scaling dan developer experience dengan membangun Modular Monolith (kode terstruktur dengan batasan domain yang jelas). Ini seringkali merupakan titik awal terbaik.
Microservices menawarkan keunggulan kuat dalam Technology Heterogeneity (pilih tools terbaik), Scaling (granuler), Ease of Deployment (independen, risiko rendah), dan Organizational Alignment (tim kecil produktif). Namun, keunggulan ini dibayar mahal dengan Pain Points yang signifikan, terutama kompleksitas sistem terdistribusi seperti Latency, Data Consistency, dan kesulitan ekstrem dalam Reporting dan End-to-End Testing. Microservices seringkali merupakan solusi untuk masalah organisasi (skala tim), bukan teknis. Banyak sistem lebih baik dimulai sebagai Modular Monolith yang terstruktur dengan baik.
Additional Information
Topik Teknis: Strategi “Monolith First”
Slide terakhir (slide 31) menyiratkan strategi yang sangat populer di industri: “Monolith First”.
Ide: Jangan memulai proyek baru dengan arsitektur microservices. Anda akan menghabiskan 6 bulan untuk membangun infrastruktur (Kubernetes, Kafka, CI/CD) sebelum 1 baris kode bisnis ditulis.
Langkah 1: Mulailah dengan membangun Modular Monolith. Fokus pada batasan yang bersih antar modul Anda. Ini memungkinkan Anda bergerak cepat, menghindari pusingnya sistem terdistribusi, dan menemukan product-market fit.
Langkah 2: Seiring pertumbuhan aplikasi, Anda akan mulai “merasakan sakit”. Delivery contention akan mulai terjadi. Mungkin 90% sistem baik-baik saja, tapi modul
PaymentatauReportingsangat lambat berubah dan butuh scaling khusus.Langkah 3: Hanya pada saat itu, Anda “mengukir” (carve out) modul
Paymentmenjadi microservice pertama Anda.Dengan cara ini, Anda berevolusi ke microservices secara pragmatis, berdasarkan kebutuhan nyata, bukan berdasarkan hype arsitektur.