Microservices.pptx

Microservices
Eko Kurniawan Khannedy

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

- Technical architect at one of the biggest
ecommerce company in Indonesia
- 11+ years experiences
- www.programmerzamannow.com
- youtube.com/c/ProgrammerZamanNow

Untuk Siapa Materi Ini?
● Web Programmer
● Backend Programmer
● Software Architect
● DevOps Engineer

Fokus Materi Belajar Microservices
● Teori dan Konsep
● Contoh Kasus
● Tidak Spesifik ke Teknologi Tertentu

Kenapa Perlu Belajar Microservices?
● Kekinian
● Ekosistem Pendukung
● Banyak Digunakan di Tech Company
● Sudah Jadi Pengetahuan Wajib untuk Senior Engineer

Apa itu Arsitektur Monolith?
● Single Deployment Unit
● Dimana semua fitur dibuat dalam sebuah aplikasi besar

Mulailah dari Aplikasi Monolith

Kelebihan Arsitektur Monolith
● Mudah di Develop
● Mudah di Deploy
● Mudah di Test
● Mudah di Scale

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

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

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

Masalah di Arsitektur Microservices
● Distributed system
● Komunikasi antar service yang rawan error
● Testing interaksi antar service lebih sulit

Pembagian Aplikasi Microservices
Merchant
Product
Shipping

Seberapa Kecil Aplikasi Microservices?
● Single responsibility
● Sekecil mungkin sehingga bisa dimengerti oleh satu orang
● Bisa di kerjakan sejumlah X developer

Monolith
● Simplicity
● Consistency
● Easy to Refactor
● Partial Deployment
● Availability
● Multiple Platform
● Easy to Scale
Microservices

Decentralized Database
MySQL Mongo Postgre Oracle

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

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

Apa itu NoSQL?
● NoSQL bukanlah NO (TIDAK/BUKAN) SQL
● NoSQL singkatan dari Not Only SQL

Jenis-Jenis NoSQL
● Document Oriented Database
● Key-Value Database
● Column Families Database
● Graph Database
● Search Database
● Time Series Database
● Dan lain-lain

Contoh NoSQL Database
● MongoDB : Document Oriented Database
● Elasticsearch : Search Database
● Redis : Key-Value Database
● Apache Cassandra : Column Families Database
● Neo4J : Graph Database
● InfluxDB : Time Series Database

Kenapa Butuh Tahu NoSQL?
● Agar bisa disesuaikan dengan kebutuhan
● Bisa mencari alternatif cara mengolah data
● Mempercepat dalam proses penulisan atau pencarian

Ketika Service butuh Data Service Lain

Komunikasi Antar Service
● Idealnya komunikasi dilakukan melalui RPI (Remote Procedure Invocation) atau RPC (Remote
Procedure Call)
● Tidak direkomendasikan komunikasi dilakukan via database

Contoh Remote Procedure Invocation
● RESTful API (HTTP)
● gRPC
● Apache Thrift
● SOAP
● Java RMI
● Corba (Common Object Request Broker Architecture)
● dan lain-lain

Keuntungan Menggunakan RPI
● Sederhana dan Mudah
● Biasanya digunakan untuk komunikasi Request - Reply
● Biasanya digunakan untuk proses Sync (yang butuh menunggu jawaban)

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

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

Komunikasi Menggunakan Messaging

Contoh Message Broker
● Redis (PubSub)
● Apache Kafka
● RabbitMQ
● NSQ
● Google PubSub
● Amazon Web Service SQS
● dan lain-lain

Keuntungan Menggunakan Messaging
● Proses lebih cepat karena tidak harus menunggu response
● Service pengirim data tidak perlu peduli terhadap penerima data

Tipe Microservices
● Stateless Microservice
● Persistence Microservice
● Aggregation Microservices

Stateless Microservices
● Biasanya tidak memiliki database
● Digunakan untuk melakukan tugas sederhana
● Biasa digunakan juga sebagai utility untuk microservice lain
● Tidak bergantung dengan microservice lain

Contoh Stateless Microservices

Persistence Microservices
● Biasanya memiliki database
● Bisa juga disebut sebagai Master Data Microservice
● Biasa digunakan untuk mengolah data di database (CRUD)

Contoh Persistence Microservices

Aggregation Microservices
● Tergantung dengan microservice lain
● Biasa digunakan sebagai pusat business logic aplikasi
● Boleh memiliki database ataupun tidak
● Tidak bisa berdiri sendiri

Contoh Aggregation Microservices

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.

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

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

Kekurangan Service Orchestration

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.

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

Keuntungan Service Choreography

Kekurangan Service Choreography
● Lebih sulit di-debug ketika terjadi masalah
● Business logic akan terdistribusi di semua Microservices, sehingga sulit untuk dimengerti secara
keseluruhan

Masalah Mengekspos Microservices
● Semua service bisa diakses dari luar
● Jika butuh Autentikasi, harus diimplementasikan di semua service
● Rawan terjadi kebocoran data

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

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

Contoh API Gateway
● Nginx
● Apache HTTPD
● Kong
● Netflix Zuul
● Spring Cloud Gateway

Authentication & Authorization

Bagaimana Mengamankan Microservices?

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.

API Gateway sebagai Middleware

Teknologi Pendukung
● Secure Cookie
● Oauth
● JSON Web Token
● Basic Auth
● API Key / Secret Key

Permasalahan Banyak Jenis Frontend

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

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

Keuntungan Backend for Frontend
● Pengembangan backend untuk tiap frontend bisa terisolasi satu sama lain
● Logic untuk frontend tidak tercampur di satu backend

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.

GraphQL : Alternative Backend for Frontend

Kekurangan Menggunakan GraphQL
● Butuh melakukan development GraphQL Server di Backend
● Butuh melakukan development GraphQL Client di Frontend

CQRS (Command Query
Responsibility Segregation)

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

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

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

Komunikasi Antar Microservices

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

Contoh Router atau Load Balancer
● Nginx
● Apache HTTPD
● Traefik

Kekurangan Server Side Discovery

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

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

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

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

Registrasi ke Service Registry

Health Check di Service Registry

Contoh Aplikasi Service Registry
● Hashicorp Consul https://www.consul.io/
● Netflix Eureka https://github.com/Netflix/eureka

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?

Contoh Lokasi Konfigurasi
● Database
● File
● Environment Variable

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

Contoh Aplikasi Centralized Configuration
● Hashicorp Consul https://www.consul.io/
● Hashicorp Vault https://www.vaultproject.io/
● Etcd https://etcd.io/
● Zookeeper https://zookeeper.apache.org/
● Doozerd https://github.com/ha/doozerd

Migrasi dari Monolith ke Microservices

SAGA Pattern
(Distributed Transaction)

Mencari Masalah Dalam Messaging

● Telegram : @khannedy
● Facebook : fb.com/khannedy
● Twitter : twitter.com/khannedy
● Instagram : instagram.com/programmerzamannow
● Email : echo.khannedy@gmail.com

Microservices.pptx

More Related Content

What's hot (20)

Similar to Microservices.pptx (20)

More from Ans Sembiring (12)

Recently uploaded (7)

Microservices.pptx

Editor's Notes