Dokumen ini membahas tentang arsitektur microservices, termasuk penjelasan tentang apa itu microservices, kelebihan dan kekurangannya dibandingkan arsitektur monolith, pembagian aplikasi menjadi microservices, database per service, komunikasi antar microservices menggunakan RPI dan messaging, serta beberapa pattern komunikasi seperti service orchestration, service choreography, API gateway, CQRS, server side discovery dan client side discovery.
2. License
● Dokumen ini boleh Anda gunakan atau ubah untuk keperluan non komersial
● Tapi Anda wajib mencantumkan sumber dan pemilik dokumen ini
● Untuk keperluan komersial, silahkan hubungi pemilik dokumen ini
3. Eko Kurniawan Khannedy
- Technical architect at one of the biggest
ecommerce company in Indonesia
- 11+ years experiences
- www.programmerzamannow.com
- youtube.com/c/ProgrammerZamanNow
5. Untuk Siapa Materi Ini?
● Web Programmer
● Backend Programmer
● Software Architect
● DevOps Engineer
6. Fokus Materi Belajar Microservices
● Teori dan Konsep
● Contoh Kasus
● Tidak Spesifik ke Teknologi Tertentu
7. Kenapa Perlu Belajar Microservices?
● Kekinian
● Ekosistem Pendukung
● Banyak Digunakan di Tech Company
● Sudah Jadi Pengetahuan Wajib untuk Senior Engineer
13. Masalah di Arsitektur Monolith
● Mengintimidasi Developer yang baru bergabung
● Scaling development dengan banyak Developer agak menyulitkan
● Butuh kontrak panjang dengan teknologi yang digunakan (bahasa pemrograman, database, dan
lain-lain)
● Scaling pada bagian tertentu tidak bisa dilakukan
● Running app Monolith sangat berat
15. Apa itu Arsitektur Microservices
● Aplikasi-aplikasi kecil yang saling bekerja sama.
● Fokus mengerjakan satu pekerjaan dengan baik
● Independent, dapat di deploy dan diubah tanpa tergantung dengan aplikasi lain
● Setiap komponen pada sistem dibuat dalam service
● Komunikasi antar service biasanya melalui network-call
17. Kelebihan Arsitektur Microservices
● Mudah dimengerti, karena relative kecil ukuran service nya
● Lebih mudah di develop, di maintain, di test dan di deploy
● Lebih mudah bergonta-ganti teknologi
● Mudah di scale sesuai kebutuhan
● Bisa dikerjakan dalam tim-tim kecil
18. Masalah di Arsitektur Microservices
● Distributed system
● Komunikasi antar service yang rawan error
● Testing interaksi antar service lebih sulit
20. Seberapa Kecil Aplikasi Microservices?
● Single responsibility
● Sekecil mungkin sehingga bisa dimengerti oleh satu orang
● Bisa di kerjakan sejumlah X developer
24. Kenapa Harus Database per Service?
● Memastikan bahwa antar service tidak ketergantungan
● Tiap service bisa menggunakan aplikasi database sesuai dengan kebutuhan
● Service tidak perlu tahu kompleksitas internal database service lain
28. Kapan Harus Shared Database?
● Ketika melakukan transisi dari aplikasi Monolith ke Microservices
● Ketika bingung memecahkan data antar Service
● Ketika dikejar waktu, sehingga tidak ada waktu untuk bikin API
34. Kenapa Butuh Tahu NoSQL?
● Agar bisa disesuaikan dengan kebutuhan
● Bisa mencari alternatif cara mengolah data
● Mempercepat dalam proses penulisan atau pencarian
38. Komunikasi Antar Service
● Idealnya komunikasi dilakukan melalui RPI (Remote Procedure Invocation) atau RPC (Remote
Procedure Call)
● Tidak direkomendasikan komunikasi dilakukan via database
41. Keuntungan Menggunakan RPI
● Sederhana dan Mudah
● Biasanya digunakan untuk komunikasi Request - Reply
● Biasanya digunakan untuk proses Sync (yang butuh menunggu jawaban)
45. Masalah di Komunikasi RPI
● Proses lama (pada Email Service dan SMS Service)
● Mengirim data yang sama berkali-kali (pada Finance Service dan Report Service)
● Membuat Paralel Process sangat rumit
46. Komunikasi dengan Cara Messaging
● Messaging biasanya digunakan untuk komunikasi Async
● Async artinya komunikasi dilakukan tanpa harus menunggu selesai di proses
● Dalam async, kadang tidak perlu peduli balasan dari service yang dituju
● Biasanya komunikasi Messaging membutuhkan Message Channel sebagai jembatan untuk
mengirim dan menerima data
● Direkomendasikan menggunakan aplikasi Message Broker untuk melakukan management
Message Channel
48. Contoh Message Broker
● Redis (PubSub)
● Apache Kafka
● RabbitMQ
● NSQ
● Google PubSub
● Amazon Web Service SQS
● dan lain-lain
49. Keuntungan Menggunakan Messaging
● Proses lebih cepat karena tidak harus menunggu response
● Service pengirim data tidak perlu peduli terhadap penerima data
52. Stateless Microservices
● Biasanya tidak memiliki database
● Digunakan untuk melakukan tugas sederhana
● Biasa digunakan juga sebagai utility untuk microservice lain
● Tidak bergantung dengan microservice lain
54. Persistence Microservices
● Biasanya memiliki database
● Bisa juga disebut sebagai Master Data Microservice
● Biasa digunakan untuk mengolah data di database (CRUD)
56. Aggregation Microservices
● Tergantung dengan microservice lain
● Biasa digunakan sebagai pusat business logic aplikasi
● Boleh memiliki database ataupun tidak
● Tidak bisa berdiri sendiri
60. Service Orchestration
● Sebelumnya kita sudah bahas tentang tipe Aggregation Microservices
● Cara Aggregation Microservices berkomunikasi dengan Microservices lain, jika menggunakan
Remote Procedure Invocation, maka dinamakan Service Orchestration Pattern
● Dalam Service Orchestration Pattern, Aggregation Microservices bertugas untuk mengatur alur
business logic sistem.
62. Keuntungan Service Orchestration
● Mudah dibuat, karena kode business logic akan terpusat di Aggregation Microservices
● Mudah dimengerti, karena kode business logic akan terpusat di Aggregation Microservices
63. Kekurangan Service Orchestration
● Aggregation Microservices terlalu ketergantungan dengan Microservices lain
● Aggregation Microservices akan lebih lambat karena harus terkoneksi dengan Microservices lain
● Aggregation Microservices akan lebih mudah error jika di Microservices lain terdapat masalah
● Jika perlu Microservices baru, perlu dilakukan perubahan di Aggregation Microservices
66. Service Choreography
● Service Choreography berbeda dengan Service Orchestration.
● Dalam Service Choreography, komunikasi Aggregation Service dengan Microservices lainnya
menggunakan Messaging.
● Dalam Service Orchestration, Aggregation Microservice adalah service yang sangat kompleks dan
mengerti semua alur business logic, sedangkan berbeda dengan Service Choreography, semua
Microservices dituntut untuk menjadi pintar, tidak hanya diperintah oleh Aggregation
Microservices.
68. Keuntungan Service Choreography
● Aggregation Microservices tidak tergantung dengan Microservices lainnya
● Aggregation Microservice akan lebih cepat, karena tidak perlu berkomunikasi dengan
Microservices lainnya
● Jika ada Microservice baru, Aggregation Microservice tidak perlu melakukan perubahan lagi
70. Kekurangan Service Choreography
● Lebih sulit di-debug ketika terjadi masalah
● Business logic akan terdistribusi di semua Microservices, sehingga sulit untuk dimengerti secara
keseluruhan
73. Masalah Mengekspos Microservices
● Semua service bisa diakses dari luar
● Jika butuh Autentikasi, harus diimplementasikan di semua service
● Rawan terjadi kebocoran data
74. API Gateway
● API Gateway adalah aplikasi yang bertugas sebagai gerbang dari luar ke dalam
● Luar adalah akses dari internet, dan Dalam adalah aplikasi microservices
● API Gateway bertugas sebagai proxy server ke semua aplikasi microservices
● Aplikasi microservices hanya bisa diakses dari luar melalui API Gateway
76. Keuntungan API Gateway
● Lebih aman karena satu gerbang
● Service tidak perlu mengimplementasikan proses Autentikasi, cukup dilakukan di API Gateway
● API Gateway juga bisa digunakan sebagai load balancer
● Bisa digunakan sebagai rate limiter
● Bisa digunakan sebagai pengaman sehingga error dari service tidak terekspos
77. Contoh API Gateway
● Nginx
● Apache HTTPD
● Kong
● Netflix Zuul
● Spring Cloud Gateway
80. Authentication dan Authorization
Authentication :
● Memvalidasi kredensial untuk
memverifikasi pemilik identitas
● Contoh proses Authentication adalah
proses login menggunakan username dan
password, dan banyak yang lainnya.
Authorization :
● Authorization adalah proses yang
dilakukan setelah proses Authentication
● Memvalidasi apakah pemilik identitas
memiliki hak akses untuk mengakses
resource yang diminta
● Contoh proses Authorization adalah
Access-Control List, dan banyak yang
lainnya.
87. Permasalahan Banyak Jenis Frontend
● Tiap frontend punya mekanisme autentikasi berbeda
● Kecepatan bandwidth tiap frontend berbeda
● API yang dibutuhkan tiap frontend berbeda
● Semua kebutuhan jenis frontend harus diimplementasikan di satu API Gateway
88. Backend for Frontend
● Backend for Frontend adalah menyediakan backend khusus untuk frontend tertentu
● Biasanya satu backend akan melayani satu frontend secara specific
● Makin banyak jenis frontend, makin banyak backend yang dibuat
90. Keuntungan Backend for Frontend
● Pengembangan backend untuk tiap frontend bisa terisolasi satu sama lain
● Logic untuk frontend tidak tercampur di satu backend
91. GraphQL : Alternative Backend for Frontend
● GraphQL adalah query language untuk API
● GraphQL dapat digunakan untuk memanipulasi response API secara runtime
● Frontend bebas menentukan data apa aja yang ingin didapatkan
● Backend hanya perlu menyediakan data lengkap, dan Frontend bisa dengan bebas menentukan
data apa aja yang diinginkan.
96. Command Query Responsibility Segregation
● CQRS adalah proses membedakan operasi Command dan operasi Query
● Operasi Command adalah operasi mengubah data (Create, Update, Delete)
● Operasi Command adalah operasi mengambil data (Get, Search)
● Dalam CQRS, biasanya service atau database dibedakan untuk kebutuhan Command dan
kebutuhan Query
98. Keuntungan CQRS
● Bisa memilih database berbeda yang optimal untuk proses Command dan Query, sehingga operasi
Command dan Search bisa lebih cepat, karena database nya sudah disesuaikan dengan kebutuhan
● Membedakan model untuk Command dan Query di aplikasi akan lebih mudah dibanding digabung
di satu model yang sama untuk proses Command dan Query
● Performa aplikasi akan lebih baik, karena kita membedakan component untuk Command dan
Query
100. Keuntungan CQRS Menggunakan Messaging
● Aplikasi Command dan Query terpisah, sehingga bisa dikerjakan oleh tim yang berbeda secara
paralel
● Aplikasi Command tidak perlu pusing memikirkan struktur data Aplikasi Query, hanya cukup
mengirim datanya ke Message Broker
● Scaling aplikasi bisa sesuai dengan kebutuhan, baik itu Command atau Query
● Jika Aplikasi Query sedang stop atau error, data dari Aplikasi Command akan tetap aman
tersimpan di Message Broker
● Mekanisme retry akan lebih mudah dilakukan jika melalui Message Broker
103. Server Side Discovery
● Membuat server khusus sebagai router atau load balancer ke service
● Client hanya butuh terkoneksi ke router atau load balancer
● Jika jumlah node service bertambah atau berkurang, router yang hanya perlu dirubah, client tidak
perlu berubah
107. Kekurangan Server Side Discovery
● Tiap service harus memiliki router atau load balancer
● Agar tidak terjadi single point of failure, maka router atau load balancer harus di setup sebanyak 2
instance
● Cost biaya akan lebih mahal, karena 1 service harus menjalankan 2 router
109. Kekurangan Server Side Discovery
● Tiap service harus memiliki router atau load balancer
● Agar tidak terjadi single point of failure, maka router atau load balancer harus di setup sebanyak 2
instance
● Cost biaya akan lebih mahal, karena 1 service harus menjalankan 2 router
110. Client Side Discovery
● Client side discovery adalah solusi agar client harus bisa tahu lokasi semua lokasi service yang
akan dituju
● Tidak perlu lagi ada router atau load balancer untuk berkomunikasi dengan Service lain
● Semua logic untuk mendistribusikan traffic harus dilakukan di client atau service yang akan
melakukan request
112. Kekurangan Client Side Discovery
● Client harus tahu lokasi semua service
● Jika jumlah node service bertambah atau berkurang, client harus diubah untuk lokasi baru nya
● Jika client salah mengimplementasikan logic untuk load balancer, maka traffic ke service yang
dituju bisa tidak merata pembagiannya
114. Kekurangan Client Side Discovery
● Client harus tahu lokasi semua service
● Jika jumlah node service bertambah atau berkurang, client harus diubah untuk lokasi baru nya
● Jika client salah mengimplementasikan logic untuk load balancer, maka traffic ke service yang
dituju bisa tidak merata pembagiannya
115. Service Registry
● Service Registry adalah aplikasi yang digunakan sebagai tempat untuk menyimpan semua
informasi yang berhubungan dengan lokasi service
● Semua service akan meregistrasikan alamat lokasi nya di Service Registry ketika pertama kali
nyala
● Semua service akan laporan ke Service Registry jika akan berhenti beroperasi, sehingga Service
Registry akan menghilangkan informasi service tersebut agar tidak mendapat traffic dari service
yang bertanya
121. Dimana Menyimpan Konfigurasi?
● Konfigurasi adalah sesuatu yang tidak asing lagi saat membuat aplikasi
● Tiap aplikasi biasanya memiliki konfigurasi, seperti konfigurasi database misalnya
● Pertanyaannya, dimana sebaiknya menyimpan konfigurasi? Agar mudah untuk di maintain dan
digunakan oleh aplikasi kita?
123. Centralized Configuration
● Centralized Configuration adalah pattern dimana kita menyimpan semua konfigurasi di sebuah
aplikasi atau service
● Service yang butuh konfigurasi akan bertanya ke aplikasi tersebut untuk mendapatkan data
konfigurasinya