Robertus - DevOps & SRE Expert

Perbandingan Mendalam: AWS VPC vs Google Cloud VPC

2025-10-25T10:00:00+07:00

Setelah beberapa tahun bekerja dengan kedua platform cloud ini, saya sering mendapat pertanyaan tentang perbandingan mendalam antara AWS VPC dan Google Cloud VPC. Keduanya memiliki filosofi desain yang sangat berbeda, dan pemahaman yang tepat tentang perbedaan ini sangat penting untuk arsitektur yang optimal.

Pengalaman saya menunjukkan bahwa pilihan antara AWS dan GCP VPC tidak hanya tentang fitur, tapi juga tentang cara berpikir dalam mendesain jaringan cloud. Mari kita eksplorasi perbedaan fundamental ini.

Arsitektur Fundamental: Regional vs Global

AWS VPC: Regional Approach

AWS VPC menggunakan pendekatan regional yang sangat ketat. Setiap VPC terbatas pada satu region saja, dan untuk koneksi antar region, kita perlu menggunakan VPC Peering atau Transit Gateway.

# Membuat VPC di region us-east-1
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --region us-east-1

# Untuk koneksi ke region lain, perlu setup terpisah
aws ec2 create-vpc \
  --cidr-block 10.1.0.0/16 \
  --region us-west-2

Yang menarik dari pendekatan ini adalah isolasi yang sangat kuat antar region. Jika ada masalah di satu region, tidak akan mempengaruhi region lain. Tapi ini juga berarti kompleksitas yang lebih tinggi untuk aplikasi yang membutuhkan komunikasi global.

GCP VPC: Global Approach

GCP mengambil pendekatan yang sangat berbeda dengan VPC global. Satu VPC bisa span multiple regions, dan subnets bisa dibuat di region yang berbeda dalam VPC yang sama.

# Membuat VPC global
gcloud compute networks create my-global-vpc \
  --subnet-mode custom

# Membuat subnet di region berbeda dalam VPC yang sama
gcloud compute networks subnets create subnet-us \
  --network my-global-vpc \
  --range 10.0.0.0/24 \
  --region us-central1

gcloud compute networks subnets create subnet-asia \
  --network my-global-vpc \
  --range 10.0.1.0/24 \
  --region asia-southeast1

Pendekatan global ini sangat powerful untuk aplikasi yang membutuhkan komunikasi internal antar region tanpa perlu konfigurasi tambahan.

Manajemen IP dan Subnet

AWS VPC: CIDR Block Management

AWS memerlukan CIDR block yang didefinisikan saat membuat VPC. Semua subnet harus berada dalam CIDR block ini.

# VPC dengan CIDR 10.0.0.0/16
# Subnet bisa dibuat dengan range:
# - 10.0.1.0/24 (us-east-1a)
# - 10.0.2.0/24 (us-east-1b)
# - 10.0.3.0/24 (us-east-1c)

Kelemahan dari pendekatan ini adalah jika kita salah planning CIDR block di awal, akan sulit untuk mengubahnya nanti. AWS memang mendukung secondary CIDR blocks, tapi prosesnya tidak semudah yang diharapkan.

GCP VPC: Flexible Subnet Management

GCP tidak memerlukan CIDR block di level VPC. Setiap subnet bisa memiliki CIDR block yang independen, dan kita bisa menambah CIDR range ke subnet yang sudah ada tanpa perlu recreate.

# Subnet bisa memiliki range yang tidak berurutan
# Subnet 1: 10.0.1.0/24
# Subnet 2: 192.168.1.0/24
# Subnet 3: 172.16.1.0/24

# Dan bisa di-expand tanpa recreate
gcloud compute networks subnets expand-ip-range subnet-1 \
  --prefix-length 23

Fleksibilitas ini sangat berguna untuk organisasi yang memiliki IP planning yang kompleks atau yang perlu mengintegrasikan dengan jaringan on-premise.

Security Model: Layered vs Unified

AWS VPC: Multi-Layer Security

AWS menggunakan model security yang berlapis dengan Security Groups dan Network ACLs.

# Security Group (stateful, instance level)
aws ec2 create-security-group \
  --group-name web-servers \
  --description "Security group for web servers"

# Network ACL (stateless, subnet level)
aws ec2 create-network-acl \
  --vpc-id vpc-xxxxxxxxx

Security Groups bersifat stateful dan diterapkan di level instance, sementara Network ACLs bersifat stateless dan diterapkan di level subnet. Ini memberikan granular control yang sangat detail, tapi juga kompleksitas yang tinggi.

GCP VPC: Unified Firewall Rules

GCP menggunakan sistem firewall rules yang unified dan stateful. Rules bisa diterapkan berdasarkan network tags atau service accounts.

# Firewall rule berdasarkan network tags
gcloud compute firewall-rules create allow-web \
  --network my-global-vpc \
  --allow tcp:80,tcp:443 \
  --target-tags web-server \
  --source-ranges 0.0.0.0/0

Pendekatan ini lebih sederhana untuk di-manage, tapi mungkin kurang granular dibandingkan AWS. Yang menarik, GCP firewall rules bisa diterapkan secara global dalam VPC.

Load Balancing: Regional vs Global

AWS VPC: Regional Load Balancers

AWS memiliki berbagai jenis load balancer yang semuanya regional:

Application Load Balancer (ALB)
Network Load Balancer (NLB)
Classic Load Balancer (CLB)

# ALB hanya bisa di satu region
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-aaaa1111 subnet-bbbb2222

Untuk multi-region, kita perlu setup load balancer terpisah di setiap region dan menggunakan Route 53 untuk traffic distribution.

GCP VPC: Global Load Balancers

GCP menawarkan global load balancers yang bisa span multiple regions dengan failover otomatis.

# Global HTTP(S) Load Balancer
gcloud compute backend-services create web-backend \
  --global \
  --protocol HTTP

# Bisa menambahkan backend di region berbeda
gcloud compute backend-services add-backend web-backend \
  --global \
  --instance-group us-central1-group \
  --instance-group-region us-central1

Ini sangat powerful untuk aplikasi yang membutuhkan high availability dan low latency global.

Hybrid Connectivity

AWS VPC: Direct Connect dan VPN

AWS menawarkan Direct Connect untuk dedicated connection dan Site-to-Site VPN untuk IPsec-based connectivity.

# Site-to-Site VPN
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-xxxxxxxxx \
  --vpn-gateway-id vgw-xxxxxxxxx

Direct Connect memberikan dedicated bandwidth dan lower latency, tapi harganya cukup mahal dan memerlukan setup yang kompleks.

GCP VPC: Cloud Interconnect dan Cloud VPN

GCP menawarkan Cloud Interconnect (dedicated) dan Cloud VPN dengan high availability.

# Cloud VPN dengan HA
gcloud compute vpn-tunnels create tunnel-1 \
  --peer-address 203.0.113.1 \
  --shared-secret secret123 \
  --target-vpn-gateway vpn-gateway-1 \
  --local-traffic-selector 0.0.0.0/0 \
  --remote-traffic-selector 0.0.0.0/0

Yang menarik, GCP Cloud VPN mendukung active-active configuration yang memberikan redundancy yang lebih baik.

Monitoring dan Observability

AWS VPC: VPC Flow Logs

AWS VPC Flow Logs bisa dikirim ke CloudWatch Logs atau S3 untuk analisis.

# Enable VPC Flow Logs
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-xxxxxxxxx \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-flow-logs-bucket

Integrasi dengan GuardDuty dan Athena memberikan security monitoring yang comprehensive.

GCP VPC: Rich Flow Logs

GCP VPC Flow Logs lebih kaya metadata dan terintegrasi dengan Cloud Logging.

# Enable VPC Flow Logs
gcloud compute networks subnets update subnet-1 \
  --region us-central1 \
  --enable-flow-logs \
  --logging-aggregation-interval interval-5-sec \
  --logging-flow-sampling 0.5

Data bisa di-export ke BigQuery untuk analisis yang lebih advanced.

Pricing Model

AWS VPC: Pay-per-Use dengan Kompleksitas

AWS menggunakan model pricing yang cukup kompleks dengan berbagai komponen:

Data transfer antar AZ: $0.01/GB
NAT Gateway: $0.045/hour + $0.045/GB
VPC Endpoints: $0.01/GB

Yang sering mengejutkan adalah biaya data transfer yang bisa sangat tinggi untuk aplikasi yang banyak komunikasi antar AZ.

GCP VPC: Simplified Pricing

GCP memiliki pricing yang lebih sederhana:

Data transfer antar region: $0.12/GB (first 1TB)
Cloud NAT: $0.045/hour + $0.045/GB
Tidak ada biaya untuk data transfer dalam region

Yang menarik, GCP tidak mengenakan biaya untuk data transfer dalam region yang sama.

Pros dan Cons Summary

AWS VPC - Pros:

Ecosystem yang sangat mature dengan third-party integrations yang luas
Granular control yang sangat detail untuk networking components
Security features yang robust dan battle-tested
Dokumentasi dan community support yang sangat baik
Integrasi yang seamless dengan layanan AWS lainnya

AWS VPC - Cons:

Learning curve yang sangat steep karena kompleksitas
Pricing structure yang kompleks dan bisa unpredictable
Regional limitation yang memerlukan setup tambahan untuk global connectivity
Management overhead yang tinggi untuk multi-region deployments
Biaya data transfer yang bisa sangat mahal

GCP VPC - Pros:

Global networking yang simplified dan powerful
Pricing model yang lebih predictable dan cost-effective
Performance yang excellent untuk AI dan data analytics workloads
Global load balancing dengan failover otomatis
Flexible IP management dan subnet expansion

GCP VPC - Cons:

Market share yang lebih kecil, sehingga community resources lebih terbatas
Enterprise support yang masih berkembang dibandingkan AWS
Global reach yang lebih terbatas dengan fewer data centers
Learning curve untuk team yang sudah familiar dengan AWS
Beberapa advanced networking features masih dalam development

Use Cases dan Rekomendasi

Pilih AWS VPC jika:

Aplikasi membutuhkan granular control yang sangat detail
Sudah memiliki investment yang besar di AWS ecosystem
Memerlukan compliance dan security features yang sangat ketat
Team sudah familiar dengan AWS dan tidak ingin learning curve tambahan
Aplikasi bersifat regional dan tidak memerlukan global connectivity yang kompleks

Pilih GCP VPC jika:

Aplikasi membutuhkan global connectivity dan multi-region deployment
Budget adalah concern utama dan ingin pricing yang lebih predictable
Aplikasi heavy di AI/ML dan data analytics
Ingin simplified networking management
Aplikasi membutuhkan global load balancing dengan high availability

Refleksi dan Pembelajaran

Setelah bekerja dengan kedua platform ini, beberapa insight yang saya dapatkan:

Philosophy Matters: AWS dan GCP memiliki filosofi desain yang sangat berbeda. AWS fokus pada granular control dan flexibility, sementara GCP fokus pada simplicity dan global connectivity.
Trade-offs are Real: Tidak ada solusi yang perfect. AWS memberikan control yang lebih detail tapi dengan kompleksitas yang tinggi. GCP memberikan simplicity tapi dengan flexibility yang lebih terbatas.
Cost Implications: Pricing model yang berbeda bisa memberikan impact yang signifikan pada total cost of ownership, terutama untuk aplikasi yang data-intensive.
Team Expertise: Pilihan platform seringkali dipengaruhi oleh expertise team yang ada, dan ini adalah faktor yang valid untuk dipertimbangkan.
Future-Proofing: Kedua platform terus berkembang, dan fitur yang tidak ada hari ini mungkin akan tersedia besok.

Yang paling penting adalah memahami kebutuhan aplikasi dan organisasi dengan baik sebelum memilih platform. Tidak ada jawaban yang benar atau salah - yang ada adalah pilihan yang tepat untuk konteks yang spesifik.

Dalam pengalaman saya, banyak organisasi yang akhirnya menggunakan multi-cloud strategy, memanfaatkan strength dari masing-masing platform untuk use case yang berbeda. Ini adalah pendekatan yang semakin populer dan bisa memberikan best of both worlds.

Belajar Setup AWS Application Load Balancer dengan AWS CLI

2025-10-04T10:00:00+07:00

Baru-baru ini saya memutuskan untuk belajar lebih dalam tentang AWS Application Load Balancer (ALB) dengan mencoba setup dari nol menggunakan AWS CLI. Meskipun sudah familiar dengan konsep load balancing, ternyata ada banyak detail teknis yang perlu dipahami ketika melakukan setup manual via command line.

Pengalaman ini memberikan insight yang cukup menarik tentang bagaimana AWS mengelola infrastruktur load balancing di balik layar, dan juga beberapa gotcha yang tidak terduga.

Persiapan Environment

Sebelum memulai eksperimen, saya perlu memastikan beberapa hal:

1. AWS CLI sudah terinstall Saya cek dulu versi yang terinstall:

aws --version

2. AWS credentials sudah dikonfigurasi

aws configure

Saya menggunakan region us-east-1 dan output format json untuk konsistensi.

3. Infrastructure yang sudah ada:

VPC ID (vpc-xxxxxxxxxxxxxxxxx)
Dua subnet dalam VPC yang sama
Security group yang mengizinkan inbound HTTP (port 80)
Dua instance EC2 yang menjalankan web server (Apache)

Saya sengaja menggunakan environment yang sudah ada untuk meminimalisir biaya eksperimen.

Membuat Load Balancer

Langkah pertama adalah membuat Application Load Balancer. Saya memilih ALB karena lebih modern dibandingkan Classic Load Balancer dan mendukung advanced routing features.

aws elbv2 create-load-balancer \
  --name my-LB \
  --subnets subnet-aaaa1111 subnet-bbbb2222 \
  --security-groups sg-cccc3333

Yang menarik, command ini langsung menghasilkan output JSON dengan LoadBalancerArn:

arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-LB/abcd1234efgh5678

Saya menyimpan ARN ini karena akan digunakan di hampir semua command selanjutnya. Ini adalah pattern yang konsisten di AWS CLI - setiap resource yang dibuat akan menghasilkan ARN yang unik.

Membuat Target Groups

Konsep target group ini cukup baru bagi saya. Ternyata ALB tidak langsung mengarahkan traffic ke instance, tapi melalui target group dulu. Ini memberikan fleksibilitas untuk mengelompokkan instance berdasarkan kriteria tertentu.

Saya membuat dua target group untuk eksperimen:

aws elbv2 create-target-group \
  --name TG1 \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx

aws elbv2 create-target-group \
  --name TG2 \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx

Setiap target group menghasilkan ARN yang unik:

arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG1/aaaa1111bbbb2222
arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG2/cccc3333dddd4444

Saya mulai memahami mengapa AWS menggunakan ARN - ini memungkinkan referensi yang unik dan konsisten di seluruh layanan.

Registrasi EC2 Instances ke Target Groups

Ini adalah bagian yang cukup tricky. Saya perlu mendaftarkan instance EC2 ke target group yang sesuai. Awalnya saya bingung, kenapa tidak bisa langsung assign instance ke load balancer?

Ternyata konsepnya adalah: Load Balancer → Target Group → EC2 Instances

aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG1/aaaa1111bbbb2222 \
  --targets Id=i-1111aaaa2222bbbb

aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG2/cccc3333dddd4444 \
  --targets Id=i-3333cccc4444dddd

Sekarang TG1 memiliki instance1, TG2 memiliki instance2. Saya mulai melihat pola arsitektur AWS yang lebih modular dibandingkan solusi tradisional.

Membuat Listener untuk Load Balancer

Ini adalah bagian yang paling membingungkan bagi saya. Load balancer tanpa listener tidak akan menerima traffic sama sekali! Listener adalah “telinga” yang mendengarkan request masuk.

aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-LB/abcd1234efgh5678 \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG1/aaaa1111bbbb2222

Saya set TG1 sebagai default action, artinya semua traffic yang tidak match dengan rule lain akan pergi ke TG1. Ini adalah konsep “catch-all” yang cukup berguna.

Membuat Rules untuk Path-Based Routing

Ini adalah fitur yang paling menarik bagi saya! ALB bisa melakukan routing berdasarkan path pattern. Saya ingin mencoba skenario:

/images/* → TG1 (untuk static assets)
/work/* → TG2 (untuk aplikasi work)

aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-LB/abcd1234efgh5678/xyz9876 \
  --priority 10 \
  --conditions Field=path-pattern,Values='/images/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG1/aaaa1111bbbb2222

aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-LB/abcd1234efgh5678/xyz9876 \
  --priority 5 \
  --conditions Field=path-pattern,Values='/work/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG2/cccc3333dddd4444

Yang menarik, priority 5 akan dievaluasi sebelum priority 10. Saya sempat bingung dengan urutan ini, tapi ternyata AWS menggunakan sistem priority yang lebih rendah = lebih tinggi prioritasnya.

Verifikasi Target Health

Setelah semua setup, saya penasaran apakah instance saya benar-benar sehat dan siap menerima traffic. ALB punya health check mechanism yang otomatis.

aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG1/aaaa1111bbbb2222

aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG2/cccc3333dddd4444

Ketika saya melihat "state": "healthy", rasanya lega! Ini berarti instance saya benar-benar siap dan ALB akan mengirim traffic ke sana. Health check ini adalah fitur yang sangat penting untuk production environment.

Testing Load Balancer

Moment of truth! Saya buka DNS name dari load balancer (bisa ditemukan di output create-load-balancer command) dan mulai testing:

http://<LB-DNS>/images/ → seharusnya pergi ke TG1 backend
http://<LB-DNS>/work/ → seharusnya pergi ke TG2 backend

Dan ternyata… berhasil! Saya bisa melihat response yang berbeda dari kedua backend. Ini adalah momen yang cukup memuaskan setelah setup yang cukup panjang.

Yang menarik, ALB juga memberikan response header X-Amzn-Trace-Id yang bisa digunakan untuk tracing request flow.

Cleanup Resources

Setelah eksperimen selesai, saya harus cleanup semua resources agar tidak kena charge. Ini adalah bagian yang tidak kalah penting!

Hapus Rules:

aws elbv2 delete-rule \
  --rule-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener-rule/app/my-LB/abcd1234efgh5678/xyz9876/priority10

aws elbv2 delete-rule \
  --rule-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener-rule/app/my-LB/abcd1234efgh5678/xyz9876/priority5

Hapus Listener:

aws elbv2 delete-listener \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-LB/abcd1234efgh5678/xyz9876

Hapus Load Balancer:

aws elbv2 delete-load-balancer \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-LB/abcd1234efgh5678

Saya harus menunggu sampai load balancer benar-benar terhapus (ini memakan waktu 1-2 menit). AWS tidak mengizinkan penghapusan target group jika masih ada dependency.

Hapus Target Groups:

aws elbv2 delete-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG1/aaaa1111bbbb2222

aws elbv2 delete-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/TG2/cccc3333dddd4444

Environment ALB saya sekarang sudah bersih dan tidak akan kena charge lagi.

Refleksi dan Pembelajaran

Eksperimen ini memberikan beberapa insight menarik:

Modularity: AWS ALB menggunakan arsitektur yang sangat modular dengan komponen yang saling terpisah (Load Balancer → Listener → Rules → Target Groups → Instances)
ARN System: Setiap resource memiliki ARN yang unik, memungkinkan referensi yang konsisten di seluruh AWS ecosystem
Health Checks: ALB secara otomatis melakukan health check dan hanya mengirim traffic ke instance yang sehat
Path-based Routing: Fitur ini sangat powerful untuk microservices architecture
Cost Awareness: Cleanup yang proper sangat penting untuk menghindari unexpected charges

Yang paling mengejutkan adalah betapa kompleksnya setup yang terlihat sederhana di AWS Console. Melakukan setup via CLI memberikan pemahaman yang lebih dalam tentang bagaimana AWS mengelola infrastruktur di balik layar.

Eksperimen Rclone untuk Sinkronisasi Data antar Cloud Provider

2025-08-27T10:00:00+07:00

Sebagai bagian dari eksperimen pribadi untuk memahami berbagai tool sinkronisasi cloud storage, saya tertarik untuk mencoba kemampuan rclone dalam memindahkan data antara Google Cloud Storage (GCS) bucket dan Amazon S3 bucket. Meskipun tersedia managed service seperti AWS DataSync atau GCP Storage Transfer Service, eksperimen ini bertujuan untuk mengevaluasi rclone sebagai alternatif yang lebih cost-effective.

Rclone, sebagai sebuah command line tool yang cukup matang untuk sinkronisasi cloud storage, ternyata memberikan hasil yang cukup memuaskan dengan beberapa catatan penting yang perlu diperhatikan dalam eksperimen ini.

Konfigurasi Rclone

Untuk dapat melakukan sinkronisasi antar cloud provider, terlebih dahulu perlu dilakukan konfigurasi rclone untuk kedua layanan cloud storage. Alih-alih menggunakan mode interaktif, saya memilih pendekatan command line agar konfigurasi dapat direproduksi dengan mudah.

Konfigurasi Google Cloud Storage

rclone config create gcs "google cloud storage" \
  project_number "123456789"

Hal penting yang perlu diperhatikan adalah penggunaan project_number dan bukan project_id. Kesalahan umum yang sering terjadi adalah mencampurkan kedua parameter ini, yang dapat menyebabkan kegagalan otentikasi.

Konfigurasi AWS S3

rclone config create aws s3 \
  provider AWS \
  env_auth true \
  region ap-southeast-3 \
  endpoint https://s3.ap-southeast-3.amazonaws.com

Pada konfigurasi S3, saya menggunakan env_auth true yang memungkinkan rclone mengambil credentials dari environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, dll). Pendekatan ini lebih aman dibandingkan dengan menyimpan credentials secara langsung di file konfigurasi.

Region ap-southeast-3 adalah Jakarta region yang memiliki performa cukup baik untuk user di Indonesia.

Verifikasi Akses Bucket

Sebelum memulai proses sinkronisasi, langkah yang baik adalah memverifikasi terlebih dahulu bahwa rclone dapat mengakses kedua bucket:

rclone lsd gcs:gcp-bucket
rclone lsd aws:aws-bucket

Command lsd (list directories) berguna untuk memverifikasi akses dan melihat struktur folder di dalam bucket.

Proses Sinkronisasi Data

Berikut adalah command utama yang digunakan untuk melakukan sinkronisasi:

rclone sync gcs:gcp-bucket aws:aws-bucket  \
  --transfers=64 \
  --checkers=64 \
  --multi-thread-streams=16 \
  --multi-thread-cutoff=100M \
  --buffer-size=256M \
  --s3-chunk-size=64M \
  --s3-upload-concurrency=32 \
  --fast-list \
  --progress --stats=30s

Berikut penjelasan detail dari masing-masing parameter:

--transfers=64: Jumlah file transfer yang berjalan secara paralel
--checkers=64: Jumlah checker yang berjalan paralel untuk membandingkan source dan destination
--multi-thread-streams=16: Jumlah stream per file untuk file berukuran besar
--multi-thread-cutoff=100M: File yang lebih besar dari nilai ini akan dipecah menjadi multiple streams
--buffer-size=256M: Buffer size untuk operasi read
--s3-chunk-size=64M: Ukuran chunk untuk S3 multipart uploads
--s3-upload-concurrency=32: Jumlah concurrent S3 uploads
--fast-list: Menggunakan recursive listing (lebih cepat tapi menggunakan memori lebih banyak)
--progress --stats=30s: Menampilkan progress setiap 30 detik

Perlu diperhatikan bahwa pengaturan ini cukup agresif dan dapat membebani network atau mencapai API rate limits. Disarankan untuk memulai dengan nilai yang lebih rendah dan melakukan penyesuaian secara bertahap.

Verifikasi Hasil Sinkronisasi

Setelah proses sinkronisasi selesai, langkah penting selanjutnya adalah melakukan verifikasi:

rclone size aws:aws-bucket
rclone size gcs:gcp-bucket

Command ini akan menampilkan total ukuran dan jumlah objek di masing-masing bucket. Kedua nilai tersebut seharusnya sama jika proses sinkronisasi berhasil.

Perbandingan dengan Managed Solutions

AWS DataSync

Keunggulan DataSync:

Layanan yang sepenuhnya dikelola oleh AWS
Built-in data validation
Integrasi yang lebih baik dengan layanan AWS lainnya
Automatic retry mechanism
Bandwidth throttling
Integrasi dengan CloudWatch untuk monitoring

Kekurangan DataSync:

Biaya yang lebih mahal, terutama untuk dataset besar
Opsi konfigurasi yang lebih terbatas
Vendor lock-in dengan ekosistem AWS
Customization yang terbatas

GCP Storage Transfer Service

Keunggulan Storage Transfer Service:

Integrasi native dengan GCP
Scheduled transfers
Built-in monitoring dan logging
Tidak perlu mengelola infrastruktur
Automatic resumption untuk transfer yang gagal

Kekurangan Storage Transfer Service:

Terbatas pada kombinasi source/destination tertentu
Kontrol yang lebih sedikit terhadap parameter transfer
Dapat menjadi mahal untuk transfer yang sering
Terkadang lebih lambat dibandingkan rclone yang dioptimasi

Keunggulan Menggunakan Rclone

Cost Effective: Hanya perlu membayar compute instance tempat rclone berjalan, ditambah biaya data transfer
Highly Configurable: Banyak parameter yang dapat disesuaikan untuk optimasi performa
Multi-Cloud Native: Kompatibel dengan hampir semua cloud storage provider
Open Source: Gratis dan dapat dikembangkan lebih lanjut
Powerful Features: Enkripsi, kompresi, filtering, dan berbagai fitur lainnya
Local Control: Dapat dijalankan dari infrastruktur sendiri

Kekurangan dan Hal yang Perlu Diperhatikan

Complexity: Memerlukan pemahaman terhadap berbagai parameter dan implikasinya
No Built-in Monitoring: Perlu setup monitoring dan alerting secara manual
Network Dependency: Performa sangat bergantung pada koneksi network yang tersedia
Resource Usage: Dapat mengonsumsi CPU dan memory yang signifikan dengan pengaturan agresif
Error Handling: Memerlukan logic retry manual untuk production workloads
Rate Limiting: Mudah mencapai API rate limits dengan pengaturan yang terlalu agresif

Pembelajaran dari Eksperimen

Mulai dengan Pengaturan Konservatif: Mulai dengan transfer rate yang rendah dan tingkatkan secara bertahap
Monitor Resource Usage: Perhatikan penggunaan CPU, memory, dan network
Test dengan Dataset Kecil: Selalu validasi pendekatan dengan subset data terlebih dahulu
Backup adalah Prioritas: Pastikan memiliki backup sebelum melakukan migrasi besar
Network Matters: Bandwidth dan latency berdampak signifikan terhadap performa

Kesimpulan

Rclone terbukti merupakan tool yang powerful untuk sinkronisasi data antar cloud provider. Meskipun managed solutions menyediakan integrasi yang lebih baik dan operational overhead yang lebih rendah, rclone memberikan kontrol yang lebih besar dan dapat menjadi pilihan yang lebih ekonomis untuk dataset berukuran besar.

Kunci utamanya adalah memahami kebutuhan spesifik:

Untuk migrasi one-time dengan constraint biaya: rclone dapat menjadi pilihan ideal
Untuk production workloads yang berkelanjutan: managed solutions mungkin pilihan yang lebih baik
Untuk skenario multi-cloud yang kompleks: fleksibilitas rclone sangat bermanfaat

Seperti biasa, lakukan testing secara menyeluruh sebelum deployment production. Dan ingat, dengan power yang besar datang tanggung jawab yang besar pula - pengaturan rclone yang agresif dapat dengan mudah membebani sistem jika tidak dikonfigurasi dengan tepat.

Panduan Migrasi Cloud: Dari Perencanaan hingga Eksekusi

2025-05-01T09:00:00+07:00

Migrasi cloud bukanlah sekadar memindahkan server dari satu tempat ke tempat lain. Ini adalah proses kompleks yang memerlukan perencanaan matang, eksekusi yang tepat, dan monitoring berkelanjutan. Setelah mengalami berbagai skenario migrasi, dari startup hingga enterprise scale, artikel ini menyajikan panduan praktis berdasarkan pengalaman riil tanpa embel-embel marketing atau janji-janji muluk.

Realitas migrasi cloud: 70% project melebihi timeline, 60% melebihi budget, dan 40% mengalami performance issues post-migration. Bukan untuk menakut-nakuti, tapi untuk mempersiapkan ekspektasi yang realistis.

Engineering Challenges dan Pre-Migration Issues

Kondisi yang Sering Terjadi dan Harus Diperbaiki

Performance Issues yang Existing:

Jangan pernah migrate aplikasi yang sudah bermasalah performance. Cloud bukan magic bullet yang akan menyelesaikan fundamental performance issues. Sebaliknya, network latency dan shared resources di cloud bisa memperparah masalah yang sudah ada.

Database Performance Problems:

Slow queries yang akan menjadi bottleneck di cloud karena network latency tambahan
Missing indexes pada large tables yang akan memperlambat migration
Inefficient queries dengan high examination-to-sent ratio (N+1 query problems)
Unbounded result sets yang akan menghabiskan memory di cloud environment
Lock contention issues yang akan diperparah dengan distributed systems

Application Architecture Problems:

Synchronous database calls dalam loop operations (N+1 query anti-pattern)
Blocking I/O operations tanpa timeout handling yang akan menyebabkan timeout di cloud
Hardcoded connection strings dan network dependencies
Monolithic services yang tidak dapat di-scale independently
Lack of circuit breakers dan retry mechanisms untuk network resilience

Structural Problems yang Mempersulit Migration

1. Monolithic Architecture dengan Tight Coupling

Common Issues:

God classes dengan 50+ methods yang menghandle multiple responsibilities
Hardcoded dependencies dengan internal IP addresses dan local hostnames
Single deployment unit yang memerlukan restart entire application untuk changes
Shared databases dengan tight schema coupling antar modules
No clear service boundaries yang membuat decomposition sulit

Problems:

Tidak bisa di-scale secara individual
Single point of failure
Deployment risks tinggi
Resource requirements massive
Testing complexity extreme

Solution Strategy:

Decompose berdasarkan business capabilities dan data ownership
Implement dependency injection untuk loose coupling
Extract shared functionality ke separate services
Use event-driven architecture untuk service communication
Implement proper service discovery dan configuration management

2. Database Issues yang Critical

Massive Database Tables:

Tables dengan billions of records tanpa partitioning (contoh: audit logs dengan 50+ billion records)
Migration time bisa 6-8 weeks untuk single table saja
Tidak ada archiving strategy untuk historical data
Single-threaded backup/restore processes yang tidak efficient
Storage requirements yang massive tanpa compression

Solution Strategy:

Implement table partitioning berdasarkan date ranges sebelum migration
Create archiving strategy untuk old data ke cold storage
Use parallel migration tools dan techniques
Implement data compression untuk reduce storage requirements

Schema Design Problems:

EAV (Entity-Attribute-Value) patterns yang membuat queries complex dan slow
Lack of proper normalization menyebabkan data redundancy
No foreign key constraints yang menyebabkan data integrity issues
Over-normalized schemas dengan excessive joins
BLOB/TEXT fields dalam transactional tables

Solution Strategy:

Normalize EAV structures ke proper relational schema
Separate transactional data dari analytical data
Implement proper indexing strategies untuk cloud database
Move large objects ke object storage (S3, Blob Storage, Cloud Storage)

3. File System Dependencies

Common Issues:

Hardcoded file paths yang tidak portable (/var/www/uploads, /tmp/processing)
Local file processing yang tidak scalable
Single-server storage dengan no redundancy
Synchronous file operations yang blocking

Solution Strategy:

Migrate file storage ke object storage (S3, Azure Blob, GCS)
Implement async file processing dengan queue systems
Use CDN untuk file delivery dan caching
Implement proper error handling dan retry mechanisms untuk file operations

Legacy Technology Stack Issues

4. Outdated Dependencies dan Security Vulnerabilities

Common Issues:

End-of-life operating systems dan base images (Ubuntu 14.04, CentOS 6, RHEL 6)
Deprecated runtime versions (Python 2.7, Node.js 0.x, Java 8)
Libraries dengan known security vulnerabilities
Incompatible dependency versions yang conflict
No automated security scanning atau dependency updates

Impact pada Migration:

Cloud providers mungkin tidak support deprecated versions
Security compliance issues untuk cloud environments
Performance degradation dengan old libraries
Compatibility issues dengan cloud-native services
Increased attack surface

Solution Strategy:

Upgrade ke supported LTS versions sebelum migration
Implement automated security scanning dalam CI/CD pipeline
Use dependency management tools untuk version compatibility
Plan incremental upgrades dengan proper testing

5. Configuration Management Chaos

Common Issues:

Configuration files scattered across multiple locations
Hardcoded environment-specific values dalam source code
Sensitive credentials stored dalam plain text files
No centralized configuration management
Environment detection berdasarkan hostname atau file paths

Impact pada Migration:

Tidak bisa deploy same artifact ke multiple environments
Configuration drift antar environments
Security risks dengan exposed credentials
Difficult troubleshooting dan environment parity issues

Solution Strategy:

Externalize configuration menggunakan environment variables
Use cloud-native config services (Parameter Store, Key Vault, Secret Manager)
Implement configuration validation dan type safety
Separate sensitive data dari application configuration

Network Dependencies dan Infrastructure Coupling

6. Network Architecture yang Tidak Cloud-Ready

Common Issues:

Hardcoded IP addresses dan hostnames dalam application code
Assumptions tentang network topology dan latency
No timeout handling untuk network calls
Missing retry logic dan circuit breaker patterns
Dependencies pada local network resources (printers, legacy services)

Impact pada Migration:

Network calls yang reliable di LAN menjadi unreliable di cloud
Application timeouts dan hanging processes
Cascade failures ketika dependencies unavailable
No graceful degradation untuk network issues

Solution Strategy:

Implement service discovery mechanisms
Add timeout dan retry logic untuk all network calls
Use circuit breaker patterns untuk fault tolerance
Replace local dependencies dengan cloud-native alternatives

Performance Anti-Patterns

7. Memory dan Resource Management Issues

Common Issues:

Unbounded caches yang grow forever tanpa eviction policy
Loading large datasets ke memory tanpa pagination
Resource leaks (connections, file handles, threads)
No connection pooling atau resource management
Memory-intensive operations tanpa streaming approaches

Impact pada Migration:

Out of memory errors lebih frequent di cloud dengan resource limits
Higher costs karena over-provisioning memory
Application instability dan frequent restarts
Poor resource utilization dan inefficient scaling

Solution Strategy:

Implement bounded caches dengan TTL dan size limits
Use streaming dan pagination untuk large datasets
Proper resource management dengan try-with-resources patterns
Implement connection pooling dan resource monitoring

Pre-Migration Remediation Strategy

Assessment Framework:

Key Assessment Areas:

Performance bottlenecks dan slow queries analysis
Architecture patterns dan anti-patterns identification
Security vulnerabilities dan compliance gaps
Configuration management practices
Resource utilization dan memory management

Migration Readiness Scoring:

Critical issues: -20 points each
Warning issues: -5 points each
Base score: 100 points
Final score range: 0-100

Migration Go/No-Go Criteria:

Critical Blockers (Must Fix):

Performance degradation over 50% dari baseline
High-severity security vulnerabilities
Database tables over 100GB tanpa partitioning
Hardcoded network dependencies
Memory leaks dalam core services

Must Fix Before Migration:

Slow queries over 30 seconds execution time
Unbounded cache implementations
Synchronous blocking I/O operations
Missing health check endpoints
Configuration tidak externalized

Recommended Improvements:

Circuit breaker implementations
Structured logging
Graceful shutdown mechanisms
Metrics collection
Application containerization

Migration Decision Matrix:

Score 90-100: Ready untuk immediate migration
Score 70-89: Fix warnings first, then migrate
Score 50-69: Address critical issues sebelum migration
Score <50: Major refactoring required sebelum migration

Downtime Management Strategy

Kategori Downtime dan Mitigation

1. Zero-Downtime Migration

Aplikasi: Stateless applications dengan load balancer
Database: Read replicas dengan gradual traffic shifting
Strategy: Blue-green deployment, rolling updates
Timeline: Real-time cutover dalam hitungan menit
Risk: Low, tapi memerlukan preparation extensive

2. Minimal Downtime (< 4 jam)

Aplikasi: Applications dengan session state
Database: Medium-sized databases dengan replication
Strategy: Maintenance window dengan quick cutover
Timeline: 1-4 jam maintenance window
Risk: Medium, memerlukan thorough testing

3. Planned Downtime (4-24 jam)

Aplikasi: Legacy monoliths dengan complex dependencies
Database: Large databases tanpa real-time replication
Strategy: Weekend maintenance window
Timeline: Extended maintenance period
Risk: High, significant business impact

4. Extended Downtime (> 24 jam)

Aplikasi: Major architecture changes, data migration
Database: Massive databases, schema changes
Strategy: Phased migration dengan temporary solutions
Timeline: Days to weeks
Risk: Very high, business continuity threatened

Downtime Minimization Techniques

Database Migration Strategies:

Online Migration:

Master-slave replication dengan lag monitoring
Database triggers untuk bidirectional sync
Read traffic routing ke cloud database gradually
Write traffic cutover setelah full sync achieved

Application Migration Strategies:

Traffic Shifting:

DNS-based traffic routing dengan TTL management
Load balancer weight adjustments (10%, 25%, 50%, 100%)
Feature flags untuk gradual functionality migration
Circuit breakers untuk automatic fallback

Session Management:

Sticky session routing selama migration period
Session store migration ke shared storage (Redis/database)
Session drainage techniques untuk clean cutover
User notification dan graceful logout procedures

Communication Management

Pre-Migration Communication (2-4 weeks before):

Stakeholder notification dengan detailed timeline
User communication tentang planned maintenance
Service dependency mapping dan coordination
Rollback procedures dan decision criteria

During Migration Communication:

Real-time status updates via multiple channels
Escalation procedures untuk critical issues
Go/no-go decision points dengan clear criteria
Technical dan business stakeholder alignment

Post-Migration Communication:

Success confirmation dan performance validation
Issue resolution dan lessons learned
User feedback collection dan resolution
Documentation updates dan knowledge transfer

Business Continuity Planning

Critical Service Identification:

Revenue-generating applications (priority 1)
Customer-facing services (priority 2)
Internal operational tools (priority 3)
Reporting dan analytics (priority 4)

Failover Procedures:

Automatic failover mechanisms dengan health checks
Manual failover procedures dengan clear documentation
Data consistency validation post-failover
Service dependency startup sequences

Recovery Time Objectives:

RTO targets berdasarkan business criticality
Recovery procedures testing dan validation
Backup restoration procedures
Data integrity verification processes

Risk Mitigation

Pre-Migration Testing:

Full end-to-end testing dalam staging environment
Load testing dengan production-like traffic
Disaster recovery testing dengan rollback scenarios
User acceptance testing dengan business stakeholders

During Migration Monitoring:

Real-time performance monitoring dengan alerts
Business metrics tracking (transactions, revenue)
User experience monitoring dengan synthetic tests
Error rate monitoring dengan automatic rollback triggers

Rollback Criteria dan Procedures:

Performance degradation > 25% dari baseline
Error rate increase > 5% dari normal levels
Business metric impact > acceptable thresholds
Critical functionality unavailable > defined time limits

Stakeholder Management

Executive Communication:

High-level status updates dengan business impact
Risk assessment dan mitigation strategies
Budget impact dan resource requirements
Success metrics dan validation criteria

Technical Team Coordination:

Cross-team communication channels (Slack, Teams)
Shared dashboards untuk real-time visibility
Decision-making protocols dengan clear authority
Resource allocation dan on-call procedures

User Support:

Help desk preparation dengan FAQ updates
User training materials untuk new environment
Support ticket prioritization during migration
User feedback mechanisms dan issue tracking

Fase Perencanaan

1. Inventory dan Assessment

Tahap ini adalah foundation dari seluruh project. Tidak ada yang lebih berbahaya daripada surprises di tengah migration. Discovery process yang incomplete akan menjadi bumerang di kemudian hari.

Yang Harus Dilakukan Secara Detail:

Application Discovery:

Inventarisasi semua aplikasi beserta versi, dependencies, dan configuration
Identifikasi service accounts dan authentication mechanisms
Mapping data flows antar aplikasi
Dokumentasi batch jobs dan scheduled tasks
Cataloging third-party integrations dan APIs

Infrastructure Mapping:

Current server specifications (CPU, memory, storage, network)
Operating system versions dan patch levels
Database systems dan storage requirements
Network topology, firewall rules, dan load balancers
Backup systems dan disaster recovery procedures

Compliance dan Security Assessment:

Data classification (public, internal, confidential, restricted)
Regulatory requirements (GDPR, HIPAA, SOX, PCI-DSS)
Current security controls dan audit requirements
Encryption standards dan key management
Access control policies dan privileged accounts

Performance Baseline:

CPU utilization patterns (peak dan average)
Memory consumption trends
Storage IOPS dan throughput requirements
Network bandwidth utilization
Application response times dan throughput

Tools untuk Discovery (Multi-Cloud):

AWS:

# AWS Application Discovery Service
aws discovery start-data-collection-by-agent-ids \
  --agent-ids "agent-1" "agent-2"

# AWS Config untuk compliance scanning
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name required-tags

Azure:

# Azure Migrate assessment
New-AzMigrateProject -Name "Migration-Assessment" \
  -ResourceGroupName "Migration-RG" \
  -Location "East US"

# Azure Security Center assessment
Get-AzSecurityAssessment | Where-Object {$_.Status -eq "Unhealthy"}

Google Cloud:

# Cloud Asset Inventory
gcloud asset search-all-resources \
  --scope=projects/PROJECT_ID \
  --asset-types=compute.googleapis.com/Instance

# Security Command Center findings
gcloud scc findings list organizations/ORG_ID \
  --filter="state=\"ACTIVE\""

Output yang Harus Dihasilkan:

Application Portfolio Matrix: Business criticality vs Technical complexity
Dependency Diagram: Visual representation dari application dependencies
Resource Sizing Report: Current vs recommended cloud instance types
Compliance Gap Analysis: Delta antara current state dan cloud requirements
Cost Model: TCO comparison antara current state dan cloud options
Risk Assessment: Technical, business, dan security risks

2. Strategi Migrasi

Pemilihan strategi migrasi bukan hanya tentang technical feasibility, tapi juga business priority, budget constraint, dan risk tolerance. Setiap pendekatan memiliki trade-off yang harus dipahami secara mendalam.

6R Strategy Framework (Gartner):

1. Rehost (Lift and Shift)

Karakteristik: Move aplikasi tanpa perubahan significant
Timeline: 2-6 bulan untuk most applications
Cost Impact: 10-30% savings immediate, limited long-term optimization
Risk Level: Low to Medium
Effort Required: Minimal development work
Cocok untuk:
- Legacy applications dengan tight coupling
- Applications dengan vendor support constraints
- Quick wins untuk cost reduction
- Proof of concept migrations

Contoh Implementation:

# AWS: EC2 instance migration
aws ec2 run-instances --image-id ami-12345678 \
  --instance-type m5.large --key-name migration-key

# Azure: VM migration
az vm create --resource-group MigrationRG \
  --name AppServer01 --image UbuntuLTS

# GCP: Compute Engine migration
gcloud compute instances create app-server-01 \
  --machine-type=n1-standard-2 --image-family=ubuntu-1804-lts

2. Replatform (Lift, Tinker, and Shift)

Karakteristik: Minimal changes untuk leverage cloud capabilities
Timeline: 3-8 bulan
Cost Impact: 20-40% savings dengan better scalability
Risk Level: Medium
Effort Required: Configuration changes, minor code modifications
Contoh Changes:
- Database ke managed services (RDS, Cloud SQL, Azure Database)
- Load balancers ke cloud-native (ALB, Azure Load Balancer)
- File storage ke object storage (S3, Blob Storage, Cloud Storage)

Database Replatform Examples:

# AWS RDS migration
aws rds create-db-instance \
  --db-instance-identifier myapp-db \
  --db-instance-class db.t3.medium \
  --engine mysql \
  --allocated-storage 100

# Azure Database for MySQL
az mysql server create \
  --resource-group MigrationRG \
  --name myapp-mysql-server \
  --sku-name GP_Gen5_2

# Google Cloud SQL
gcloud sql instances create myapp-mysql \
  --database-version=MYSQL_8_0 \
  --tier=db-n1-standard-2

3. Repurchase (Drop and Shop)

Karakteristik: Move ke SaaS solution
Timeline: 6-12 bulan (including data migration dan training)
Cost Impact: Variable, often OpEx vs CapEx shift
Risk Level: Medium to High
Contoh: On-premise email ke Office 365, Custom CRM ke Salesforce

4. Refactor/Re-architect

Karakteristik: Redesign aplikasi untuk cloud-native
Timeline: 12-24 bulan
Cost Impact: 40-70% optimization potential
Risk Level: High
Effort Required: Significant development work
Technologies: Microservices, containers, serverless

Cloud-Native Architecture Examples:

# Kubernetes deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0
        ports:
        - containerPort: 8080

5. Retire

Karakteristik: Shutdown applications yang tidak longer needed
Timeline: 1-3 bulan
Cost Impact: 100% elimination
Risk Level: Low to Medium
Requirements: Thorough dependency analysis dan user notification

6. Retain

Karakteristik: Keep applications on-premise
Reasons: Compliance, latency, cost, complexity
Review Period: Annual assessment untuk future migration

Decision Matrix untuk Strategy Selection:

Criteria	Rehost	Replatform	Refactor	Repurchase	Retire
Speed	Fast	Medium	Slow	Medium	Fast
Cost Optimization	Low	Medium	High	Variable	Highest
Risk	Low	Medium	High	Medium	Low
Cloud Benefits	Minimal	Partial	Full	Full	N/A
Effort Required	Low	Medium	High	Medium	Low

3. Timeline dan Phasing

Migration yang sukses memerlukan pendekatan bertahap. Big bang migration adalah resep disaster. Phasing yang tepat memungkinkan learning dan course correction di setiap wave.

Detailed Wave Planning:

Wave 0: Foundation dan Pilot (Bulan 1-3)

Scope: Infrastructure setup, pilot application (1-2 non-critical apps)
Objectives:
- Validate tools dan processes
- Establish operational procedures
- Train team dengan cloud environment
- Test rollback procedures
Success Criteria:
- Pilot apps running dengan < 5% performance degradation
- All tools functioning properly
- Team confident dengan procedures
Example Applications: Development environments, internal tools, documentation sites

Wave 1: Low-Risk Applications (Bulan 4-6)

Scope: 10-20% of application portfolio
Characteristics:
- Minimal dependencies
- Non-customer facing
- Low compliance requirements
- Simple architecture
Risk Mitigation: Extensive testing, parallel running, quick rollback capability
Examples: Internal reporting systems, monitoring tools, HR applications

Wave 2: Supporting Systems (Bulan 7-12)

Scope: 30-40% of remaining applications
Characteristics:
- Some interdependencies
- Supporting business functions
- Medium complexity
Focus Areas: Dependency management, data consistency, performance validation
Examples: CRM systems, inventory management, analytics platforms

Wave 3: Core Business Applications (Bulan 13-18)

Scope: 30-35% of remaining applications
Characteristics:
- Customer-facing components
- Revenue-generating systems
- High availability requirements
- Complex integrations
Extra Precautions:
- Extended testing periods
- Blue-green deployments
- Real-time monitoring
- Immediate rollback plans

Wave 4: Mission-Critical Systems (Bulan 19-24)

Scope: 10-15% most critical applications
Characteristics:
- Core business functions
- Highest security requirements
- Maximum uptime demands
- Complex compliance needs
Special Considerations:
- Dedicated migration windows
- Multiple rehearsals
- Executive oversight
- Disaster recovery testing

Application Categorization Matrix:

High Business Impact + Low Technical Complexity = Wave 2-3
High Business Impact + High Technical Complexity = Wave 4
Low Business Impact + Low Technical Complexity = Wave 1
Low Business Impact + High Technical Complexity = Wave 1-2 (atau Retire)

Timeline Dependencies:

Critical Path Factors:

Compliance Approvals: 2-6 bulan untuk regulated industries
Vendor Negotiations: 1-3 bulan untuk licensing changes
Network Connectivity: 1-4 bulan untuk direct connections
Team Training: 2-3 bulan untuk comprehensive upskilling
Security Clearances: 3-6 bulan untuk government/defense contracts

Parallel Activities Timeline:

Month 1-2:  Infrastructure setup + Team training + Pilot planning
Month 3-4:  Pilot execution + Wave 1 planning + Tool refinement
Month 5-6:  Wave 1 execution + Wave 2 planning + Process optimization
Month 7-12: Wave 2 execution + Wave 3 planning + Continuous improvement
...

Struktur Tim dan Tanggung Jawab

Migration Team Structure

Core Migration Team:

Migration Lead / Solution Architect

Overall technical leadership dan strategic decisions
Cross-cloud architecture design
Stakeholder communication dan escalation management
Risk assessment dan mitigation planning

Infrastructure Engineers (2-4 orang)

Cloud environment setup dan configuration
Network connectivity dan security implementation
Monitoring dan observability setup
Infrastructure as Code development

Application Migration Engineers (3-6 orang)

Application assessment dan migration planning
Code modifications untuk cloud compatibility
Testing dan validation procedures
Performance optimization

Database Specialists (1-2 orang)

Database migration strategy dan execution
Data consistency dan integrity validation
Performance tuning dan optimization
Backup dan disaster recovery implementation

DevOps Engineers (2-3 orang)

CI/CD pipeline migration dan optimization
Container orchestration setup
Configuration management
Release management dan deployment automation

Security Engineer (1-2 orang)

Security controls implementation
Compliance validation
Identity dan access management
Security testing dan vulnerability assessment

Project Manager

Timeline coordination dan progress tracking
Resource allocation dan dependency management
Communication dengan business stakeholders
Risk monitoring dan issue escalation

Quality Assurance Engineers (2-3 orang)

Migration testing strategy development
Automated testing implementation
Performance dan load testing
User acceptance testing coordination

Business Analysts/SMEs (per application)

Business requirement validation
User story definition untuk cloud features
Training material development
Change management support

Resource Allocation Model:

Team Composition per Wave:

Wave 0-1: 2-3 engineers, 1 architect, 1 project manager, 1 QA
Wave 2-3: 4-6 engineers, 1-2 architects, 1 project manager, 2 QA, business SMEs
Wave 4: 6-8 engineers, 2 architects, 1 project manager, 3 QA, business SMEs, executive sponsor

Budget Distribution (Typical):

Preparation (20%): Tools, training, initial setup
Wave 1 (15%): Pilot dan low-risk applications
Wave 2 (25%): Supporting systems
Wave 3 (30%): Core business applications
Wave 4 (10%): Mission-critical systems

Risk Mitigation Strategies:

Dependency Management:

# Create dependency mapping
dependencies = {
  "app_a": ["database_1", "api_service"],
  "app_b": ["app_a", "storage_system"],
  "app_c": ["external_api", "message_queue"]
}

# Migration order berdasarkan dependencies
migration_order = topological_sort(dependencies)

Rollback Planning:

Wave 1: Same-day rollback capability
Wave 2: 24-hour rollback window
Wave 3: 48-hour rollback dengan business approval
Wave 4: 72-hour rollback dengan executive approval

Communication Schedule:

Daily: Engineering standup updates
Weekly: Stakeholder status reports
Bi-weekly: Executive summary dashboards
Monthly: Business review dan course corrections

Software Engineering Team Responsibilities

Backend Development Team:

Pre-Migration Code Audit:

# Code audit untuk cloud compatibility
def audit_application_dependencies():
    """Audit semua dependencies untuk cloud compatibility"""
    dependencies = [
        "database_connections",
        "file_system_access", 
        "network_dependencies",
        "third_party_integrations",
        "environment_specific_configs"
    ]
    
    compatibility_issues = []
    for dep in dependencies:
        if not is_cloud_compatible(dep):
            compatibility_issues.append({
                "dependency": dep,
                "issue": analyze_compatibility_issue(dep),
                "remediation": suggest_remediation(dep)
            })
    
    return compatibility_issues

# Configuration externalization
DATABASE_URL = os.getenv('DATABASE_URL', 'localhost:5432')
API_KEY = os.getenv('API_KEY', 'default_key')
REDIS_HOST = os.getenv('REDIS_HOST', 'localhost')

Health Check Implementation:

// Health check endpoints untuk cloud load balancers
@RestController
public class HealthController {
    
    @Autowired
    private DatabaseHealthIndicator dbHealth;
    
    @GetMapping("/health")
    public ResponseEntity<Map<String, String>> health() {
        Map<String, String> status = new HashMap<>();
        
        if (dbHealth.isHealthy()) {
            status.put("database", "UP");
        } else {
            status.put("database", "DOWN");
            return ResponseEntity.status(503).body(status);
        }
        
        status.put("status", "UP");
        return ResponseEntity.ok(status);
    }
    
    @GetMapping("/ready")
    public ResponseEntity<String> readiness() {
        if (applicationReadyForTraffic()) {
            return ResponseEntity.ok("READY");
        }
        return ResponseEntity.status(503).body("NOT_READY");
    }
}

Structured Logging:

import logging
import json
from datetime import datetime

class CloudLogger:
    def __init__(self, service_name, environment):
        self.service_name = service_name
        self.environment = environment
        
    def log_event(self, level, message, **kwargs):
        log_entry = {
            "timestamp": datetime.utcnow().isoformat(),
            "service": self.service_name,
            "environment": self.environment,
            "level": level,
            "message": message,
            "correlation_id": kwargs.get('correlation_id'),
            "additional_data": kwargs
        }
        
        logging.info(json.dumps(log_entry))

Frontend Development Team:

CDN Integration:

// Multi-cloud CDN configuration
const CloudAssetManager = {
    cdnConfig: {
        aws: 'https://cloudfront-domain.amazonaws.com',
        azure: 'https://azure-cdn-endpoint.azureedge.net',
        gcp: 'https://storage.googleapis.com/cdn-bucket'
    },
    
    getAssetUrl: function(assetPath, provider = 'aws') {
        const baseUrl = this.cdnConfig[provider];
        return `${baseUrl}/${assetPath}`;
    }
};

// Environment-specific configurations  
const CloudConfig = {
    development: {
        apiEndpoint: 'https://dev-api.company.com',
        enableDebug: true
    },
    production: {
        apiEndpoint: 'https://api.company.com',
        enableDebug: false
    }
};

Performance Monitoring:

class CloudPerformanceMonitor {
    trackPageLoad() {
        const perfData = performance.getEntriesByType('navigation')[0];
        const metrics = {
            timestamp: Date.now(),
            pageLoadTime: perfData.loadEventEnd - perfData.navigationStart,
            domContentLoaded: perfData.domContentLoadedEventEnd - perfData.navigationStart,
            environment: this.config.environment
        };
        
        this.sendMetrics(metrics);
    }
    
    sendMetrics(metrics) {
        fetch(`${this.config.metricsEndpoint}/performance`, {
            method: 'POST',
            headers: {'Content-Type': 'application/json'},
            body: JSON.stringify(metrics)
        });
    }
}

Database Team Responsibilities

Schema Compatibility Check:

-- Audit stored procedures untuk cloud database compatibility
SELECT 
    routine_name,
    routine_type,
    routine_definition
FROM information_schema.routines 
WHERE routine_schema = 'your_database'
AND routine_type = 'PROCEDURE';

-- Check triggers yang mungkin tidak supported
SELECT 
    trigger_name,
    event_manipulation,
    event_object_table,
    action_statement
FROM information_schema.triggers
WHERE trigger_schema = 'your_database';

Migration Execution:

#!/bin/bash
# Database migration dengan minimal downtime

echo "Pre-migration validation..."
mysql -h source-db -u migration_user -p -e "SELECT COUNT(*) FROM critical_table;" > pre_count.txt

echo "Schema migration..."
mysqldump -h source-db -u migration_user -p --no-data --routines your_database > schema.sql
mysql -h target-db -u admin_user -p your_database < schema.sql

echo "Data validation..."
python3 validate_migration.py --source source-db --target target-db

Message Queue Team Responsibilities

Kafka Migration:

from kafka import KafkaProducer, KafkaConsumer
from kafka.admin import KafkaAdminClient, NewTopic

class KafkaMigrator:
    def __init__(self, source_config, target_config):
        self.source_config = source_config
        self.target_config = target_config
        
    def migrate_topics(self, topic_list):
        # Create topics di target cluster
        admin_client = KafkaAdminClient(
            bootstrap_servers=self.target_config['bootstrap_servers']
        )
        
        new_topics = []
        for topic_name in topic_list:
            new_topic = NewTopic(
                name=topic_name,
                num_partitions=3,
                replication_factor=2
            )
            new_topics.append(new_topic)
        
        admin_client.create_topics(new_topics)
        
        # Migrate data
        for topic_name in topic_list:
            self.migrate_topic_data(topic_name)
    
    def migrate_topic_data(self, topic_name):
        consumer = KafkaConsumer(
            topic_name,
            bootstrap_servers=self.source_config['bootstrap_servers'],
            auto_offset_reset='earliest'
        )
        
        producer = KafkaProducer(
            bootstrap_servers=self.target_config['bootstrap_servers']
        )
        
        for message in consumer:
            producer.send(topic_name, value=message.value, key=message.key)
        
        producer.flush()
        producer.close()
        consumer.close()

Cloud-Managed Services:

# AWS MSK
aws kafka create-cluster \
  --cluster-name migration-kafka \
  --broker-node-group-info file://broker-info.json \
  --kafka-version "2.8.0"

# Azure Event Hubs  
az eventhubs namespace create \
  --resource-group Migration-RG \
  --name migration-eventhubs

# Google Pub/Sub
gcloud pubsub topics create migration-topic
gcloud pubsub subscriptions create migration-sub --topic=migration-topic

Persiapan Teknis

1. Cloud Environment Setup

Foundation yang solid adalah kunci sukses migration. Semua cloud provider memiliki pendekatan berbeda, tapi principles yang sama: security first, scalability by design, dan observability from day one.

Network Foundation (Multi-Cloud):

AWS VPC Setup:

# Create VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=Migration-VPC}]'

# Create subnets
aws ec2 create-subnet --vpc-id vpc-12345678 \
  --cidr-block 10.0.1.0/24 --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Private-Subnet-1}]'

aws ec2 create-subnet --vpc-id vpc-12345678 \
  --cidr-block 10.0.2.0/24 --availability-zone us-east-1b \
  --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Public-Subnet-1}]'

# Internet Gateway
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-12345678 --internet-gateway-id igw-87654321

# NAT Gateway untuk private subnet internet access
aws ec2 create-nat-gateway --subnet-id subnet-12345678 \
  --allocation-id eipalloc-87654321

Azure Virtual Network Setup:

# Create Resource Group
New-AzResourceGroup -Name "Migration-RG" -Location "East US"

# Create Virtual Network
$virtualNetwork = New-AzVirtualNetwork \
  -ResourceGroupName "Migration-RG" \
  -Location "East US" \
  -Name "Migration-VNet" \
  -AddressPrefix "10.0.0.0/16"

# Create subnets
$subnetConfig1 = Add-AzVirtualNetworkSubnetConfig \
  -Name "Private-Subnet" \
  -AddressPrefix "10.0.1.0/24" \
  -VirtualNetwork $virtualNetwork

$subnetConfig2 = Add-AzVirtualNetworkSubnetConfig \
  -Name "Public-Subnet" \
  -AddressPrefix "10.0.2.0/24" \
  -VirtualNetwork $virtualNetwork

# Apply configuration
$virtualNetwork | Set-AzVirtualNetwork

# Network Security Group
New-AzNetworkSecurityGroup \
  -ResourceGroupName "Migration-RG" \
  -Location "East US" \
  -Name "Migration-NSG"

Google Cloud VPC Setup:

# Create VPC
gcloud compute networks create migration-vpc \
  --project=PROJECT_ID \
  --subnet-mode=custom \
  --mtu=1460 \
  --bgp-routing-mode=regional

# Create subnets
gcloud compute networks subnets create private-subnet \
  --project=PROJECT_ID \
  --range=10.0.1.0/24 \
  --network=migration-vpc \
  --region=us-central1

gcloud compute networks subnets create public-subnet \
  --project=PROJECT_ID \
  --range=10.0.2.0/24 \
  --network=migration-vpc \
  --region=us-central1

# Firewall rules
gcloud compute firewall-rules create allow-internal \
  --project=PROJECT_ID \
  --network=migration-vpc \
  --allow=tcp,udp,icmp \
  --source-ranges=10.0.0.0/16

Security Baseline (Multi-Cloud):

Identity and Access Management:

AWS IAM Policy Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        }
      }
    }
  ]
}

Azure RBAC Assignment:

# Create custom role
$role = Get-AzRoleDefinition "Virtual Machine Contributor"
$role.Id = $null
$role.Name = "Migration VM Operator"
$role.Description = "Can manage VMs for migration project"
$role.Actions.RemoveRange(0,$role.Actions.Count)
$role.Actions.Add("Microsoft.Compute/virtualMachines/*")
$role.Actions.Add("Microsoft.Network/networkInterfaces/read")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/SUBSCRIPTION_ID")

New-AzRoleDefinition -Role $role

# Assign role
New-AzRoleAssignment -SignInName user@domain.com \
  -RoleDefinitionName "Migration VM Operator" \
  -Scope "/subscriptions/SUBSCRIPTION_ID"

Google Cloud IAM:

# Create custom role
gcloud iam roles create migrationVmOperator \
  --project=PROJECT_ID \
  --title="Migration VM Operator" \
  --description="Custom role for migration project" \
  --permissions="compute.instances.get,compute.instances.start,compute.instances.stop"

# Bind user to role
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:user@domain.com" \
  --role="projects/PROJECT_ID/roles/migrationVmOperator"

Encryption Configuration:

AWS Encryption:

# S3 bucket encryption
aws s3api create-bucket --bucket migration-data-bucket \
  --create-bucket-configuration LocationConstraint=us-west-2

aws s3api put-bucket-encryption \
  --bucket migration-data-bucket \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

# EBS encryption
aws ec2 modify-ebs-default-kms-key-id --kms-key-id alias/migration-key
aws ec2 enable-ebs-encryption-by-default

Azure Encryption:

# Storage account encryption
$storageAccount = New-AzStorageAccount \
  -ResourceGroupName "Migration-RG" \
  -Name "migrationstorageacct" \
  -Location "East US" \
  -SkuName "Standard_LRS" \
  -Kind "StorageV2" \
  -EnableHttpsTrafficOnly $true

# Enable encryption
Set-AzStorageAccount -ResourceGroupName "Migration-RG" \
  -AccountName "migrationstorageacct" \
  -EnableBlobEncryption $true \
  -EnableFileEncryption $true

Google Cloud Encryption:

# Create Cloud KMS key
gcloud kms keyrings create migration-keyring \
  --location=global

gcloud kms keys create migration-key \
  --location=global \
  --keyring=migration-keyring \
  --purpose=encryption

# Cloud Storage encryption
gsutil mb -p PROJECT_ID -c STANDARD -l US gs://migration-data-bucket
gsutil kms encryption -k projects/PROJECT_ID/locations/global/keyRings/migration-keyring/cryptoKeys/migration-key gs://migration-data-bucket

Connectivity Setup:

Hybrid Connectivity Options:

AWS Direct Connect:

# Create Virtual Interface
aws directconnect create-private-virtual-interface \
  --connection-id dxcon-123456789 \
  --new-private-virtual-interface \
  vlan=100,bgpAsn=65000,virtualInterfaceName=Migration-VIF,virtualGatewayId=vgw-12345678

Azure ExpressRoute:

# Create ExpressRoute circuit
New-AzExpressRouteCircuit \
  -Name "Migration-Circuit" \
  -ResourceGroupName "Migration-RG" \
  -Location "East US" \
  -SkuTier "Standard" \
  -SkuFamily "MeteredData" \
  -ServiceProviderName "Provider Name" \
  -PeeringLocation "Washington DC" \
  -BandwidthInMbps 1000

Google Cloud Interconnect:

# Create VLAN attachment
gcloud compute interconnects attachments create migration-attachment \
  --region=us-central1 \
  --router=migration-router \
  --interconnect=migration-interconnect \
  --vlan=100

DNS Strategy:

Multi-Cloud DNS Management:

# AWS Route53
aws route53 create-hosted-zone \
  --name migration.company.com \
  --caller-reference migration-$(date +%s)

# Azure DNS
az network dns zone create \
  --resource-group Migration-RG \
  --name migration.company.com

# Google Cloud DNS
gcloud dns managed-zones create migration-zone \
  --dns-name=migration.company.com. \
  --description="Migration project DNS zone"

2. Landing Zone Preparation

Landing zone adalah foundational setup yang akan menentukan scalability, security, dan manageability dari cloud environment. Ini bukan hanya tentang account structure, tapi entire governance framework.

Multi-Account/Subscription Strategy:

AWS Organizations Structure:

# Create organization
aws organizations create-organization --feature-set ALL

# Create accounts
aws organizations create-account \
  --email migration-prod@company.com \
  --account-name "Migration-Production"

aws organizations create-account \
  --email migration-dev@company.com \
  --account-name "Migration-Development"

aws organizations create-account \
  --email migration-security@company.com \
  --account-name "Migration-Security"

Azure Management Groups:

# Create management group
New-AzManagementGroup -GroupName "Migration-MG" \
  -DisplayName "Migration Management Group"

# Create subscriptions under management group
New-AzSubscription -Name "Migration-Production" \
  -ManagementGroupId "Migration-MG"

New-AzSubscription -Name "Migration-Development" \
  -ManagementGroupId "Migration-MG"

Google Cloud Organization:

# Set organization policy
gcloud organizations set-policy ORGANIZATION_ID \
  --policy-file=policy.yaml

# Create projects
gcloud projects create migration-prod-PROJECT_ID \
  --organization=ORGANIZATION_ID \
  --name="Migration Production"

gcloud projects create migration-dev-PROJECT_ID \
  --organization=ORGANIZATION_ID \
  --name="Migration Development"

Account/Subscription Purpose:

Core Accounts:

Production: Live production workloads
Staging: Pre-production testing dan UAT
Development: Development dan integration testing
Security: Central security services (logging, monitoring, compliance)
Shared Services: DNS, Active Directory, backup services
Network: Network connectivity hub (VPN, Direct Connect)

Governance Framework:

Tagging Strategy (Consistent across clouds):

Required_Tags:
  Environment: [Production, Staging, Development]
  Application: [App-Name]
  Owner: [Team-Name]
  CostCenter: [Cost-Center-Code]
  Project: [Migration-Project-Code]
  Backup: [Daily, Weekly, None]
  Compliance: [PCI, HIPAA, SOX, None]

Optional_Tags:
  Schedule: [Business-Hours, 24x7, Weekend-Off]
  DataClassification: [Public, Internal, Confidential, Restricted]
  MaintenanceWindow: [Weekend, Weeknight, Anytime]

AWS Tagging Enforcement:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "rds:CreateDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Environment": "true",
          "aws:RequestTag/Application": "true",
          "aws:RequestTag/Owner": "true"
        }
      }
    }
  ]
}

Azure Policy Definition:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "anyOf": [
        {
          "field": "tags['Environment']",
          "exists": "false"
        },
        {
          "field": "tags['Application']",
          "exists": "false"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Resource Naming Conventions:

Standard Pattern:

{company}-{environment}-{application}-{resource-type}-{region}-{instance}

Examples:
company-prod-webapp-vm-useast1-001
company-dev-api-db-uswest2-001
company-staging-cache-redis-euwest1-001

Multi-Cloud Implementation:

# AWS
aws ec2 run-instances --image-id ami-12345678 \
  --instance-type t3.medium \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=company-prod-webapp-vm-useast1-001}]'

# Azure
az vm create --resource-group Migration-RG \
  --name company-prod-webapp-vm-useast-001 \
  --image UbuntuLTS \
  --tags Environment=Production Application=WebApp

# GCP
gcloud compute instances create company-prod-webapp-vm-uscentral1-001 \
  --machine-type=n1-standard-2 \
  --labels=environment=production,application=webapp

Cost Management Setup:

Budget Alerts (Multi-Cloud):

AWS Budgets:

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "Migration-Monthly-Budget",
    "BudgetLimit": {
      "Amount": "10000",
      "Unit": "USD"
    },
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }'

Azure Budgets:

New-AzConsumptionBudget \
  -Name "Migration-Budget" \
  -Amount 10000 \
  -Category Cost \
  -TimeGrain Monthly \
  -StartDate "2025-01-01" \
  -EndDate "2025-12-31"

Google Cloud Budgets:

gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Migration Budget" \
  --budget-amount=10000USD

Backup Policies:

Cross-Cloud Backup Strategy:

Backup_Tiers:
  Tier_1_Critical:
    Frequency: "4 times daily"
    Retention: "30 days local, 365 days archive"
    RTO: "< 1 hour"
    RPO: "< 15 minutes"
    
  Tier_2_Important:
    Frequency: "Daily"
    Retention: "14 days local, 90 days archive"
    RTO: "< 4 hours"
    RPO: "< 1 hour"
    
  Tier_3_Standard:
    Frequency: "Weekly"
    Retention: "4 weeks local, 52 weeks archive"
    RTO: "< 24 hours"
    RPO: "< 24 hours"

Compliance Framework:

Multi-Cloud Compliance Monitoring:

AWS Config Rules:

aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "required-tags",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "REQUIRED_TAGS"
    },
    "InputParameters": "{\"tag1Key\":\"Environment\",\"tag1Value\":\"Production,Staging,Development\"}"
  }'

Azure Policy Assignment:

New-AzPolicyAssignment \
  -Name "Require-Tags-Policy" \
  -PolicyDefinition $policyDef \
  -Scope "/subscriptions/SUBSCRIPTION_ID"

Google Cloud Organization Policies:

constraint: constraints/compute.requireLabels
listPolicy:
  requiredValues:
    - "environment"
    - "application"
    - "owner"

3. Tools dan Automation

Automation adalah kunci untuk migration yang consistent, repeatable, dan scalable. Manual migration processes tidak sustainable untuk enterprise-scale projects.

Migration Tools (Multi-Cloud):

Database Migration Tools:

AWS Database Migration Service (DMS):

# Create replication instance
aws dms create-replication-instance \
  --replication-instance-identifier migration-instance \
  --replication-instance-class dms.t3.medium \
  --allocated-storage 100 \
  --vpc-security-group-ids sg-12345678

# Create source endpoint
aws dms create-endpoint \
  --endpoint-identifier source-mysql \
  --endpoint-type source \
  --engine-name mysql \
  --server-name source.mysql.com \
  --port 3306 \
  --username migration_user \
  --password migration_password

# Create target endpoint
aws dms create-endpoint \
  --endpoint-identifier target-rds \
  --endpoint-type target \
  --engine-name mysql \
  --server-name target.rds.amazonaws.com \
  --port 3306 \
  --username admin \
  --password admin_password

Azure Database Migration Service:

# Create migration service
New-AzDataMigrationService \
  -ResourceGroupName "Migration-RG" \
  -Name "MigrationService" \
  -Location "East US" \
  -Sku "Premium_4vCores"

# Create migration project
New-AzDataMigrationProject \
  -ResourceGroupName "Migration-RG" \
  -ServiceName "MigrationService" \
  -ProjectName "DatabaseMigration" \
  -Location "East US" \
  -SourcePlatform "SQL" \
  -TargetPlatform "SQLMI"

Google Cloud Database Migration Service:

# Create migration job
gcloud database migration migration-jobs create mysql-migration \
  --region=us-central1 \
  --destination-connection-profile=target-cloudsql \
  --source-connection-profile=source-mysql \
  --vm-instance-machine-type=n1-standard-2

Server Migration Tools:

AWS Application Migration Service (MGN):

# Install replication agent
wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-us-east-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

sudo python3 aws-replication-installer-init.py \
  --region us-east-1 \
  --aws-access-key-id AKIA... \
  --aws-secret-access-key ...

Azure Migrate:

# Download Azure Migrate appliance
Invoke-WebRequest -Uri "https://aka.ms/migrate/appliance/vmware" \
  -OutFile "AzureMigrateAppliance.ova"

# Register appliance
Register-AzMigrateProject \
  -ResourceGroupName "Migration-RG" \
  -ProjectName "AzureMigrateProject" \
  -Location "East US"

Google Cloud Migrate for Compute Engine:

# Create migration source
gcloud compute os-config guest-policies create migration-policy \
  --file=migration-policy.yaml

# Start migration wave
gcloud compute sole-tenancy node-groups create migration-nodes \
  --node-template=migration-template \
  --target-size=3 \
  --zone=us-central1-a

Infrastructure as Code (Multi-Cloud):

Terraform Multi-Cloud Example:

# Provider configurations
provider "aws" {
  region = "us-east-1"
}

provider "azurerm" {
  features {}
}

provider "google" {
  project = var.gcp_project_id
  region  = "us-central1"
}

# AWS VPC
resource "aws_vpc" "migration_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "Migration-VPC"
    Environment = "Production"
    Project     = "CloudMigration"
  }
}

# Azure Virtual Network
resource "azurerm_virtual_network" "migration_vnet" {
  name                = "migration-vnet"
  address_space       = ["10.1.0.0/16"]
  location            = azurerm_resource_group.migration.location
  resource_group_name = azurerm_resource_group.migration.name

  tags = {
    Environment = "Production"
    Project     = "CloudMigration"
  }
}

# Google Cloud VPC
resource "google_compute_network" "migration_vpc" {
  name                    = "migration-vpc"
  auto_create_subnetworks = false
  mtu                     = 1460
}

AWS CloudFormation Template:

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Migration infrastructure template'

Parameters:
  Environment:
    Type: String
    Default: Production
    AllowedValues: [Production, Staging, Development]

Resources:
  MigrationVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: true
      EnableDnsSupport: true
      Tags:
        - Key: Name
          Value: !Sub "${Environment}-Migration-VPC"
        - Key: Environment
          Value: !Ref Environment

  PrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MigrationVPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
      Tags:
        - Key: Name
          Value: !Sub "${Environment}-Private-Subnet"

Configuration Management:

Ansible Playbook for Multi-Cloud:

---
- name: Configure migrated servers
  hosts: all
  become: yes
  vars:
    environment: "{{ env | default('production') }}"
    
  tasks:
    - name: Update system packages
      package:
        name: "*"
        state: latest
      when: ansible_os_family == "RedHat"

    - name: Install monitoring agent
      script: install_monitoring_agent.sh
      args:
        creates: /opt/monitoring/agent

    - name: Configure application
      template:
        src: app.conf.j2
        dest: /etc/app/config.conf
        backup: yes
      notify: restart application

    - name: Configure cloud-specific settings
      include_tasks: "{{ ansible_cloud_provider }}_config.yml"
      when: ansible_cloud_provider is defined

  handlers:
    - name: restart application
      service:
        name: myapp
        state: restarted

CI/CD Pipeline for Migration:

GitLab CI Pipeline:

stages:
  - validate
  - plan
  - deploy
  - test
  - cleanup

variables:
  TF_ROOT: "${CI_PROJECT_DIR}/terraform"
  TF_STATE_NAME: "${CI_ENVIRONMENT_NAME}"

before_script:
  - cd ${TF_ROOT}
  - terraform init -backend-config="key=${TF_STATE_NAME}.tfstate"

validate:
  stage: validate
  script:
    - terraform validate
    - terraform fmt -check
  only:
    - merge_requests
    - main

plan:
  stage: plan
  script:
    - terraform plan -out=plan.cache
  artifacts:
    paths:
      - ${TF_ROOT}/plan.cache
    expire_in: 7 days
  only:
    - main

deploy:
  stage: deploy
  script:
    - terraform apply plan.cache
  dependencies:
    - plan
  when: manual
  only:
    - main

migration_test:
  stage: test
  script:
    - python3 migration_tests.py
    - ansible-playbook -i inventory/production test_connectivity.yml
  only:
    - main

cleanup:
  stage: cleanup
  script:
    - terraform destroy -auto-approve
  when: manual
  only:
    - main

Monitoring dan Observability Setup:

Multi-Cloud Monitoring Stack:

Prometheus Configuration:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "migration_rules.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

scrape_configs:
  - job_name: 'aws-instances'
    ec2_sd_configs:
      - region: us-east-1
        port: 9100
    relabel_configs:
      - source_labels: [__meta_ec2_tag_Environment]
        target_label: environment
      - source_labels: [__meta_ec2_tag_Application]
        target_label: application

  - job_name: 'azure-instances'
    azure_sd_configs:
      - subscription_id: "subscription-id"
        tenant_id: "tenant-id"
        client_id: "client-id"
        client_secret: "client-secret"
        port: 9100

  - job_name: 'gcp-instances'
    gce_sd_configs:
      - project: 'project-id'
        zone: 'us-central1-a'
        port: 9100

Migration-Specific Alerts:

groups:
  - name: migration_alerts
    rules:
      - alert: MigrationHighLatency
        expr: http_request_duration_seconds{quantile="0.95"} > 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High latency detected during migration"
          description: "Application {{ $labels.application }} has high latency"

      - alert: MigrationErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High error rate during migration"
          description: "Error rate is {{ $value }} for {{ $labels.application }}"

      - alert: DatabaseConnectionFailure
        expr: up{job="database"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Database connection failure"
          description: "Database {{ $labels.instance }} is unreachable"

Fase Eksekusi

1. Pilot Migration

Scope Terbatas:

Pilih 1-2 aplikasi non-critical
Test semua processes dan tools
Validate performance dan functionality
Measure timeline accuracy

Checklist Pilot:

2. Production Migration

Pre-Migration:

# Database backup
mysqldump -u root -p database_name > backup.sql

# Application state backup
tar -czf app_backup.tar.gz /path/to/application

# Configuration backup
cp -r /etc/app-config /backup/config

Migration Execution:

Maintenance window communication
Final data sync
Application cutover
DNS switchover
Functionality validation
Performance monitoring

Post-Migration:

Immediate functionality testing
Performance monitoring
Error log analysis
User acceptance testing
Documentation update

3. Data Migration Strategies

Database Migration:

For Large Databases:

# AWS DMS example
aws dms create-replication-instance \
  --replication-instance-identifier myrepinstance \
  --replication-instance-class dms.t2.micro

For Application Data:

Rsync untuk file systems
Storage gateway untuk gradual migration
Application-level replication

Monitoring dan Validasi

1. Key Metrics

Performance Metrics:

Response time
Throughput
Error rates
Resource utilization

Business Metrics:

User satisfaction
Availability
Transaction volume
Revenue impact

Cost Metrics:

Monthly spend
Resource efficiency
ROI tracking

2. Monitoring Setup

Infrastructure Monitoring:

# CloudWatch example
MetricFilters:
  - FilterName: ErrorCount
    FilterPattern: "[timestamp, request_id, level=\"ERROR\"]"
    MetricTransformations:
      - MetricNamespace: "Application/Logs"
        MetricName: "ErrorCount"

Application Monitoring:

APM tools (New Relic, Datadog, AppDynamics)
Custom metrics
Log aggregation
Distributed tracing

Skenario Khusus

Cloud-to-Cloud Migration

Tambahan Considerations:

Cross-cloud networking (peering, transit gateway)
Data transfer costs
Service mapping antar providers
Vendor lock-in assessment

Tools Khusus:

Rclone untuk storage migration
Cloud-native migration services
Third-party migration platforms

On-Premise to Cloud

Network Considerations:

Bandwidth requirements untuk data transfer
Hybrid connectivity planning
Latency impact assessment
Security compliance untuk data in transit

Legacy Application Challenges:

OS compatibility
License portability
Hardware dependency
Integration points

Common Pitfalls dan Mitigasi

1. Underestimating Complexity

Masalah:

Dependencies tidak teridentifikasi
Performance degradation
Security gaps

Mitigasi:

Thorough discovery process
Proof of concept untuk critical applications
Security assessment di setiap phase

2. Inadequate Testing

Masalah:

Functionality breaks di production
Performance issues
Data corruption

Mitigasi:

Comprehensive testing strategy
Load testing di cloud environment
Data validation procedures

3. Poor Change Management

Masalah:

User resistance
Process disruption
Knowledge gaps

Mitigasi:

Training programs
Clear communication
Phased rollout

Fokus Area Kritis

1. Security

Non-Negotiable:

Data encryption
Access controls
Network security
Compliance requirements

2. Performance

Monitoring Kontinyu:

Baseline comparison
Bottleneck identification
Capacity planning
Optimization opportunities

3. Cost Management

Ongoing Activities:

Resource right-sizing
Reserved instance planning
Cost allocation tracking
Waste identification

Metrics Keberhasilan

Technical Success Metrics

Availability: Target 99.9% atau sesuai SLA
Performance: Tidak lebih dari 10% degradation
Security: Zero security incidents
Data Integrity: 100% data consistency

Business Success Metrics

Timeline: Sesuai dengan project timeline
Budget: Dalam budget allocation
User Satisfaction: Minimal impact pada user experience
ROI: Positive return dalam 12-18 bulan

Post-Migration Activities

1. Optimization

Cost Optimization:

Right-sizing instances
Reserved capacity planning
Lifecycle policies
Resource scheduling

Performance Optimization:

Auto-scaling configuration
Caching strategies
Database optimization
Network optimization

2. Governance

Ongoing Processes:

Cost reviews
Security assessments
Performance reviews
Capacity planning

Kesimpulan

Migrasi cloud yang sukses memerlukan pendekatan sistematis dengan fokus pada perencanaan detail, eksekusi bertahap, dan monitoring berkelanjutan. Kunci utamanya adalah:

Assessment yang menyeluruh - Pahami sepenuhnya apa yang akan dimigrasikan
Planning yang realistis - Buat timeline dan budget yang reasonable
Testing yang comprehensive - Test everything, trust nothing
Execution yang bertahap - Migrate in waves, not big bang
Monitoring yang berkelanjutan - Keep watching everything

Ingat, migrasi cloud bukan project yang berakhir setelah go-live. Ini adalah beginning dari cloud journey yang memerlukan continuous improvement dan optimization. Yang terpenting, jangan terburu-buru dan selalu prepare untuk rollback scenario jika something goes wrong.

Troubleshooting Common Issues

Performance Degradation Post-Migration:

Root Cause: Incorrect instance sizing, network latency, storage IOPS limitations
Solution: Performance baseline comparison, right-sizing analysis, storage optimization
Prevention: Thorough performance testing in staging environment

Data Consistency Issues:

Root Cause: Replication lag, incomplete synchronization, application-level inconsistencies
Solution: Data validation scripts, checksum verification, transaction log analysis
Prevention: Zero-downtime migration strategies, database migration best practices

Network Connectivity Problems:

Root Cause: Security group misconfigurations, DNS resolution issues, routing problems
Solution: Network path analysis, security group audit, DNS propagation verification
Prevention: Network testing in isolated environments, gradual traffic shifting

Application Integration Failures:

Root Cause: API endpoint changes, authentication issues, dependency version conflicts
Solution: Integration testing suites, API compatibility checks, dependency mapping
Prevention: Comprehensive integration testing, API versioning strategies

Key Success Factors

Technical Excellence

Comprehensive Planning: 60% of migration success depends on upfront planning
Automation First: Manual processes don’t scale and introduce human errors
Testing Everything: If it’s not tested, it will fail in production
Monitoring from Day Zero: Observability must be built-in, not bolted-on

Organizational Readiness

Executive Sponsorship: Migration needs strong leadership support
Cross-functional Teams: Include business stakeholders, not just technical teams
Change Management: User training and communication are critical
Risk Management: Have contingency plans for every major component

Process Discipline

Wave-based Approach: Never attempt big-bang migrations
Documentation Standards: Every decision and configuration must be documented
Communication Cadence: Regular updates to all stakeholders
Continuous Improvement: Learn from each wave and improve the next

Final Reality Check

Migrasi cloud yang sukses memerlukan:

12-24 bulan untuk enterprise-scale migrations
20-30% budget buffer untuk unexpected issues
Dedicated team dengan cloud expertise
Executive patience untuk proper execution

Yang tidak boleh dikompromi:

Security dan compliance requirements
Data integrity dan business continuity
Performance benchmarks
Rollback capabilities

Yang bisa difleksibel:

Timeline (better safe than sorry)
Scope (prioritize based on business value)
Technology choices (use what works, not what’s trendy)

Ingat: Migration adalah marathon, bukan sprint. Success diukur tidak hanya dari technical metrics, tapi juga business outcomes dan user satisfaction. Plan carefully, execute methodically, monitor continuously.

Tidak ada silver bullet dalam migrasi cloud. Yang ada adalah hard work, proper planning, execution yang disciplined, dan team yang committed untuk success jangka panjang.

Cuti Panjang

2021-11-15T00:00:00+07:00

Bekerja super keras tanpa henti selama hampir 17 tahun membuat saya cukup lelah. Selain mental yang sudah tidak lagi sama, keinginan untuk maju yang seharusnya persisten sudah tidak berada pada level terbaik. Yang saya pahami selama ini, determinasi dalam bekerja seharusnya ada pada level terbaik.

Dalam kondisi lelah, duduk dan beristirahatlah.

Kredit Gambar : Jan Padila

Continuous Testing Kafka with Xinfra Monitor in Kubernetes

2021-10-06T00:00:00+07:00

Monitors kafka as part of continuously cheking how the cluster performs. The challenge with this is to create script to produce and consume with some ludicrous amount of works. Instead of creating stuff in house, a mate refering a fancy tool called Kafka Monitor.

Kafka monitor, or now known as Xinfra Monitor is an open source software created by folks in Linkedin. This tools provide the produce, consume and offset test and measurement.
The fun part here, is Jolokia. So, Xinfra Monitor (Kafka Monitor), expose mbeans through Jolokia, so it can be accessed easily by any monitoring tools like Prometheus (plus Jolokia Exporter) or paid one like Datadog.

Kafka Xinfra Monitor Deployment

In this case I would use kubernetes cluster to host the xinfra monitor, and also use strimzi as kafka and zookeeper operator. For the sake of simplicity, I will host everything on the kubernetes, minikube -in this example.

Prerequisites :

Minikube ref
Kafka and Zookeeper ref

Nice to have locally :

jq
curl

Base assumption :

kafka cluster endpoint : my-cluster-kafka-bootstrap, Port : 9092
zookeeper cluster endpoint : my-cluster-zookeeper-client, Port : 2181
Run xinfra monitor in single cluster monitoring mode

Deploy the Kafka Monitor / Xinfra Monitor

Initial steps :

Clone source code

git clone git@github.com:linkedin/kafka-monitor.git
Checkout to latest release tag. e.g

git checkout 2.5.10

Modify the Dockerfile

If you can see. There is Dockerfile here.

FROM anapsix/alpine-java

MAINTAINER coffeepac@gmail.com

WORKDIR /opt/kafka-monitor
ADD build/ build/
ADD bin/xinfra-monitor-start.sh bin/xinfra-monitor-start.sh
ADD bin/kmf-run-class.sh bin/kmf-run-class.sh
ADD config/xinfra-monitor.properties config/xinfra-monitor.properties
ADD config/log4j2.properties config/log4j2.properties
ADD docker/kafka-monitor-docker-entry.sh kafka-monitor-docker-entry.sh
ADD webapp/ webapp/

CMD ["/opt/kafka-monitor/kafka-monitor-docker-entry.sh"]

Side note : in the Dockerfile above, you will find out that the container will use the properties which can be configured in config/xinfra-monitor.properties. With this config, you can set the configuration in granular way, also possible for you to monitor multiple kafka cluster - which I don’t really need in this case. Much better way to do this approach, is to convert the config file to kubernetes configmap.

In my case, I will not use the default Dockerfile approach, since I only want to monitor a single Kafka Cluster. So I modified the Dockerfile to this :

FROM anapsix/alpine-java

WORKDIR /opt/kafka-monitor
ADD build/ build/
ADD bin/single-cluster-monitor.sh bin/single-cluster-monitor.sh
ADD bin/kmf-run-class.sh bin/kmf-run-class.sh
ADD config/log4j2.properties config/log4j2.properties

ENTRYPOINT ["/opt/kafka-monitor/bin/single-cluster-monitor.sh"]

Build Docker image

Build the docker image using existing makefile (yea you can use a vanilla docker build command too)
```
# Go to the docker folder - inside the kafka-monitor repo
cd docker
PREFIX=robeevanjava/kafka-monitor TAG=v2.5.10 make container
```
You can change the PREFIX environment variable with your docker hub username or even to quay.io. Change the tag to any version you want.

Push the docker image to docker registry

  docker push robeevanjava/kafka-monitor:v2.5.10

Deploying the Kubernetes Objects

I have create the kubernetes manifest here: xinfra-monitor-manifest.yaml

If you want to use exactly that manifest mentioned above, just do

kubectl apply -f https://git.io/JwLDr -n kafka-monitor

If you need to change the kafka and zookeeper cluster, please change the argument lines here :

      containers:
      - name: kafka-monitor
        image: robeevanjava/kafka-monitor:v2.5.10
        imagePullPolicy: Always
        env: []
        args:
        - --topic
        - kafkamonitor-topic-test
        - --broker-list
        - my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9092
        - --zookeeper
        - my-cluster-zookeeper-client.kafka.svc.cluster.local:2181

Change the topic, broker-list and zookeeper parameter accordingly.

In the manifest I only expose 1 port on the kubernetes service, and that is for Jolokia ref, a software that exposing mbeans to http. So it enable us to query the mbeans metric through http request, with json returning value.

To find the available metric, try to do these steps :

Do port-forwarding to jolokia service port

  kubectl port-forward svc/kafka-monitor 8778:8778 -n kafka-monitor

Make request to jolokia port

  # Get list of available metric
  curl "http://localhost:8778/jolokia/list"
  # Json pretty print 
   curl "http://localhost:8778/jolokia/list" | jq .
  # Read to a sample metric
  curl "http://localhost:8778/jolokia/read/kafka.consumer:client-id=kmf-consumer,type=consumer-metrics"

Now you have kafka monitor run on your kubernetes cluster.

Optional Steps

Some of the organization uses prometheus as “default” observability toolings. We can use jolokia-exporter

You can clone the repo and build your very own Jolokia docker image and push it to your favourite container registry, but I will use the prebuilt one :)

I have kubernetes manifest here

So to apply it, run

kubectl apply -f https://git.io/JwLim -n kafka-monitor

Then you can just do either ServiceMonitor or write a prometheus scrape config like explained in the example here

PS : If the git.io URL is broken, please refer to each linked gist file above :D

TIL : 2020-07-19

2021-07-19T04:41:13+07:00

Mencoba untuk pasang gitlab runner menggunakan helm chart seperti tutorialnya di sini : https://docs.gitlab.com/runner/install/kubernetes.html
Saya baru sadar jika kita butuh menambahkan role cluster-admin untuk service account default gitlab (jika kita tidak mendefinisikannya di values.yaml)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cluster-admin
  namespace: gitlab
subjects:
  - kind: ServiceAccount
    name: default
    namespace: gitlab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

Euro 2020, Inggris dan Downtime

2021-06-15T04:35:24+07:00

Bagi para pecinta sepakbola, selama beberapa pekan ke depan, kita semua akan dimanjakan dengan tontonan olahraga populer nan berkualitas dari dua kompetisi antar negara. Yang pertama Copa America 2021 - turnamen yang digelar oleh CONMEBOL dengan peserta negara - negara Amerika Selatan. Turnamen ini disiarkan secara daring oleh vidio.com dan sudah dibuka dengan kemenangan Brasil sebagai juara bertahan. Yang satu lagi, Euro 2020 - turnamen yang digelar oleh UEFA, diikuti oleh negara benua eropa termasuk Rusia. Sebagai episentrum liga - liga terbaik dunia, pagelaran ini ditunggu oleh masyarakat. Euro 2020 yang digelar di tahun 2021 ini, disiarkan oleh mola.tv, sebuah platform OTT daring yang masih cukup muda, dan didukung oleh pabrikan besar ternama, yaitu Polytron. Euro 2020 sudah dimulai terlebih dahulu dan dibuka dengan kemenangan Italia atas Turki, pada tanggal 12 Juni 2021 lalu.

Euro sebagai turnamen dengan sejarah panjang ini, belum genap berjalan sepekan, namun sudah banyak hal terjadi di beberapa hari kebelakang ini. Mulai dari kemenangan telak Italia, insiden terjatuhnya Christian Eriksen di lapangan (get well soon, Eriksen!), laga dramatis Belanda melawan Ukraina, selebrasi rasial dari Arnautovic sampai gol indah Patrick Schick. Yang paling epik dan dirasakan sangat mengesalkan (termasuk saya), adalah insiden pada saat laga perdana Inggris di kompetisi Euro 2020 ini. Laga tersebut sangat ditunggu dan diantisipasi warga pecinta bola, telaknya lagi, laga itu jatuh di akhir pekan. Bukan insiden di dalam lapangan, melainkan, terjadinya gangguan yang membuat para pelanggan Mola.tv tidak bisa menyaksikan pasukan Gareth Southgate. Saya berulang kali mencoba untuk masuk melalui web dan android app, namun hasilnya saya tetap mendapatkan gangguan yang sama.

Akhir pekan, Inggris dan waktu primer (prime time) adalah kombinasi cukup mematikan untuk platform streaming semacam Mola.tv . Seperti yang kita tahu, Inggris dan Liga Primer-nya adalah liga terpopuler di negara kita. Hal yang sama juga pernah terjadi ketika laga Malaysia melawan Indonesia, Persija melawan Persib di platform saingannya, vidio.com. Bedanya, vidio.com tidak mengalami insiden seburuk mola.tv. Sebagai orang di luar organisasi Mola, tentu saya tidak tahu penyebab utama dari insiden di hari itu. Yang bisa saya bayangkan, saat itu Mola sedang mengumpulkan tim teknis terkait dan berusaha “memadamkan” api yang sudah terlanjur menjalar.

Sebenarnya untuk pengguna yang sudah terlanjur membuka atau mungkin para pengakses awal halaman Ingriss melawan Kroasia saat itu, akan dapat menikmati tayangan tersebut, asalkan tidak dimuat ulang lamannya. Sehingga ada beberapa pengguna Mola yang merasa tidak ada insiden atau hambatan seperti pengguna kebanyakan. Sekali lagi, ini bukanlah penyebab sesungguhnya, atau bahkan bukan hipotesa, namun sering kali pada kejadian lumpuhnya halaman streaming yang disertai dengan melonjaknya trafik, jarang terjadi bottleneck pada “streaming” nya itu sendiri. Biasanya live streaming sudah ditangani oleh CDN sebagai komponen utama yang sanggup menangani trafik besar sekalipun.

Lonjakan trafik ini biasanya berakibat cukup fatal terhadap service backend seperti API endpoint yang menangani proses bisnis dan fitur lain. Misalkan endpoint untuk mengecek legitimasi user, paket user, menyediakan umpan balik sebuah URL live stream yang tepat, sampai pada fitur live chat. Pada kasus mola.tv, tidak terdapat fitur live chat seperti di youtube atau vidio.com. Jika pada saat kejadian, anda membuka mola lewat web dan membuka developer tools, maka dapat dilihat ada beberapa API endpoint yang mengembalikan respon dengan kode error.

Tanpa mengetahui apa detil yang terjadi di tim teknis mola.tv, penulis merasa bahwa pada setiap even besar, penting dilakukan beberapa persiapan, termasuk melibatkan tim bisnis dan produk. Biasanya tim tersebut mampu memprediksi seberapa besar trafik yang akan masuk dan menonton tayangan tersebut. Kemudian persiapan teknis apa yang bisa dilakukan tim infrastruktur bersama pemrogram?

Mempersiapkan War Room

Pada tim teknis, sebaiknya mempersiapkan tim untuk bersiap (on-call standby) pada saat waktu berlangsungnya even besar tersebut. Dalam kasus super ideal, organisasi mempunyai tim techops yang dapat mengumpulkan pihak - pihak terkait ke dalam sebuah war room. Sehingga ketika terjadi insiden, semua pihak yang berkompeten, dapat dipanggil di satu tempat saja. Ini juga dapat memperpendek MTTR (mean time to resolve) pada insiden.

Autoscaling Tak Bisa Diandalkan

Menurut pengalaman, kita tak lagi sanggup mengandalkan fitur autoscaling yang umumnya tersedia di platform - plaform orkestrasi atau cloud. Fitur autoscaling tak lagi handal untuk mengatasi gelombang kerusakan eksponensial akibat lonjakan trafik yang secara ekstrim sangat drastis.
Sebelum terjadinya even, hendaknya tim teknis mulai mempersiapkan peladen yang sudah hot standby untuk melayani jumlah trafik yang melonjak tinggi. Selain itu, penting pula untuk menggarisbawahi metrik - metrik yang penting untuk dipantau, termasuk oleh pemrogram.

Memprediksi Bottleneck pada Dependensi

Setelah mengetahui bahwa autoscaling tidak dapat diandalkan. Tim teknis juga harus dapat memprediksi limitasi dari sistem - sistem lain yang menjadi dependensi dari services yang akan diakses oleh pengguna. Entah itu database, atau sistem lain, bisa saja tidak mampu melayani trafik masuk sesuai ekspektasi, sehingga membutuhkan perubahan konfigurasi sebelum even besar dimulai. Biasanya tak mudah menambah kapasitas (scaling up) dependensi, terutama stateful dependency.

Beberapa hari setelah terjadi insiden tersebut, saya pribadi melihat Mola melakukan crisis management dengan sangat baik, yaitu memberikan layanan gratis (liga primer Inggris) sebagai kompensasi atas insiden Inggris vs Kroasia.

Dari persiapan di atas, mungkin ada yang kurang. Sila ditambahkan jika ada yang kurang dengan merespon laman ini ke kontak[at]robee.id

TIL : 2020-05-30

2021-05-29T17:09:55+07:00

Sebagai bekal untuk siniar baru berbahasa Jawa Timur nanti, yang mana saya yakin akan banyak pisuhan - pisuhan , penulis mempersiapkan cara untuk menyensor hal tersebut menggunakan kakas suara bernama Audacity.

nek pisuhan kabeh isine yok opo iki, rek!

Tentang Replikasi Eksternal dari dan ke MySQL Google CloudSQL

2021-05-29T16:33:11+07:00

Penulis ingin mengawali catatan kali ini dengan kisah jenaka, betapa lucunya peraturan negeri ini mengenai pusat data untuk industri finansial, tapi takut dan mungkin nirfaedah. Semoga seseorang yang bekerja di bidang yang sama, nanti, akan mampu menuliskan betapa jenakanya peraturan tersebut.

Ya, meski kita tahu di Google CloudSQL (baik postgresql maupun mysql) kita dapat membuat replika, namun oleh karena aturan bahwa sebuah perusahaan yang bergerak di bidang finansial, harus membuat pusat data untuk pemulihan bencana (Disaster Recovery Data Center), maka pada kasus ini, penulis dan tim infrastruktur, ditugaskan untuk mempersiapkan sebuah set komplit pada pusat data lain. Karena pusat data DR, maka harus selain Google Cloud Platform (sudah dipakai sebagai pusat data utama), bisa saja di sebuah VM di penyedia lain, seperti Alibaba Cloud, Biznet Gio/Neo atau merek lain. Pada aktivitas ini, komponen yang paling menjadi sorotan adalah klaster basis data, dalam hal ini MySQL Database Cluster.

Tulisan ini tidak akan menjelaskan langkah per langkah, namun hanya merekam hal penting yang mungkin nanti akan membantu penulis kembali, jika menemui hal yang sama ke depannya. Pada tulisan ini, versi MySQL yang penulis gunakan adalah versi 8.0. Untuk detail petunjuk, akan penulis lampirkan tautan referensi di akhir artikel. Pada aspek yang lebih detil, penulis berkonsultasi dengan rekan ahli lainnya, yaitu Hofid Mashudi dan Agus Syafaat (terima kasih teman temanku) * gestur saranghaeyo *.

Replikasi ke Replika Eksternal

Pada skenario ini, kita akan mempunyai MySQL primary instance di Google CloudSQL sedangkan untuk replica instances ada di CloudSQL sendiri dan sebuah VM (sebuah VM berisi MySQL yang dipasang dan dikonfigurasi sendiri tanpa managed service).

mysql vm replica ---- mysql cloudsql primary 
                         -- cloudsql replica

Selain membuat MySQL di Google CloudSQL dan VM, langkah - langkahnya secara garis besar adalah sebagai berikut :

Membuat 1 user untuk replikasi dengan permission REPLICATION SLAVE atau REPLICATION CLIENT pada primary instance di CloudSQL
Memastikan antara VM replica dan CloudSQL dapat berkomunikasi di port 3306
Ekpor data dari primary instance (CloudSQL) dengan mempertahankan GTID
Impor data dari hasil ekspor di atas ke replika di VM
Menyalin server certificate dari primary instance di CloudSQL ke VM replica.
Set master di VM replica dengan contoh CHANGE MASTER TO MASTER_HOST = '', MASTER_PORT = 3306, MASTER_USER = '', MASTER_PASSWORD = '<replica user's password>, MASTER_AUTO_POSITION = 1, MASTER_SSL = 1, MASTER_SSL_CA = '/path/to/server-ca.pem';
START REPLICA dijalankan di VM replica

Cukup simpel dan tidak berbelit. Namun ada beberapa hal yang perlu diperhatikan pula. Pada kasus ini, kita harus memastikan replication-ignore-db pada replika eksternal harus dapat diset dan dipasang mysql sebagai nilainya. replication-ignore-db = mysql. Sehingga, jika kita ingin melakukan replikasi misalkan antara mysql di cloudsql dan amazon RDS, kita harus pastikan dulu RDS support setup parameter ini atau tidak, jika tidak, maka replikasi tak dapat dilakukan. [1]

Hal lain, adalah memastikan parameter read_only di set ke ON , pada replika. Jika perlu, setelah setup selesai, kita set super_read_only untuk menghindari “errant transaction” [2]

Replikasi dari Eksternal (External Master/Primary)

Salah satu aspek penilaian auditor terhadap kesiapan sistem, pada produk - produk teknologi finansial (tekfin / fintech) salah satunya adalah data center swing atau secara sederhana, melakukan simulasi jika terjadi bencana, dan pusat data cadangan akan menjadi yang utama. Dari sisi database, maka hal ini sesederhana membalik skenario di atas dari cloudsql sebagai primary instance dan VM sebagai replika. Sehingga VM sekarang sebagai primary instance sedangkan mysql di CloudSQL menjadi replika. Prosedur lengkap ada di referensi bawah [3], namun secara ringkas dapat ditulis sebagai berikut :

Membuat 1 user untuk replikasi dengan permission REPLICATION SLAVE atau REPLICATION CLIENT pada VM mysql replika
Membuat “_ source representation _” pada Google CloudSQL [4]
Melakukan prosedur demote pada mysql instance di CloudSQL (yang tadinya adalah primary)
eksekusi STOP REPLICA dan RESET REPLICA ALL pada mysql di VM (yang saat ini jadi master)
set parameter read_only (dan super_read_only) menjadi OFF pada mysql di VM

Sesederhana itu. Pada aktivitas ini, yang paling harus diperhatikan adalah pada saat pembuatan source representation dan prosedur demotion , untuk :

memastikan memasukkan server certificate milik mysql di VM dengan tepat
memastikan mysql di CloudSQL tidak punya CLoudSQL replica lagi. [5]

Jika terdapat replika pada sisi CloudSQL, maka yang terjadi, akan ada return error seperti ini :

{
  "error": {
    "code": 400,
    "message": "The requested operation is not valid for an instance that has a replica.",
    "errors": [
      {
        "message": "The requested operation is not valid for an instance that has a replica.",
        "domain": "global",
        "reason": "badRequest"
      }
    ]
  }
}

Monitoring

Pada kedua aktivitas di atas, pastikan kondisi replikasi selalu dalam pantauan.

Tetap memantau Second Behind Source tetap 0 di hasil output dari perintah SHOW REPLICA STATUS\G
Cek kondisi replika dari sisi primary instance SHOW SLAVE HOSTS
Cek GTID di SHOW MASTER STATUS
Jika memungkinkan, pantau metrik ini pada kakas pemantauan (monitoring tools) seperti Grafana + Prometheus atau Stackdriver Monitoring atau AWS Cloudwatch atau Datadog dll.
Pastikan retensi binlog pada primary instance dihitung dengan benar disesuaikan kebutuhan replikasi dan kondisi network

Jika ada yang pertanyaan atau masukan, dengan senang hati dapat berdikusi di kontak[at]robee.id.

* nonton drakor lagi *

Referensi:

Post image by Kelly Sikkema on Unsplash

Hal Kontraproduktif Ketika Migrasi ke Cloud

2021-01-14T06:49:48+07:00

Pada medio 2020 lalu, Bukalapak Engineering telah berhasil menyelesaikan proyek yang sangat penting dalam pendewasaan tim, baik secara teknologi, maupun secara organisasi. Proyek penting itu adalah migrasi infrastruktur dari data center on-premise ke cloud provider bernama Google Cloud Platform (GCP). Sebenarnya sudah ada 3 artikel yang lebih dahulu membahas proyek yang secara internal dinamakan Gatotkaca ini, 1 artikel di linkedin yang membahas hal yang dipelajari oleh seorang TPM saat itu - Ichsan Rahardianto, 2 artikel lain di GCP Blog, yang pertama soal cloud migration 101 yang dijabarkan dengan sangat baik oleh Mohan Krishnan, dan terakhir soal pencapaian penting pada proyek Gatotkaca ini dari sudut pandang seorang Alabsi.

Karena sudah ada 3 artikel dan mungkin masih banyak artikel lain yang bersifat positif, maka artikel yang saya tulis kali ini hanya akan memuat hal yang perlu dihindari, pola pikir yang salah atau hal bersifat kontraproduktif lainnya.

Sumber Daya Cloud adalah Tidak Terbatas

Seperti kesabaran, sumber daya (resources) pada Cloud infrastructure dan provider, akan selalu terbatas. Meski kita melihatnya dalam bentuk virtual machines atau container, pada dasarnya semua berjalan di atas mesin fisik seperti pada on-premise. Karena kemudahan antar muka dan skala yang lebih besar saja, kita melihatnya seperti tak ada batasannya. Kealpaan pada perencanaan dapat membuat proses migrasi jadi terganggu, atau minimal cost efficiency jadi tidak tercapai.

Sebuah kesalahan besar ketika kita tidak melakukan inventory dan capacity sizing (pengukuran kapasitas) pada saat memindahkan infrastruktur kita ke cloud provider. Selain untuk dapat mengetahui apakah provider dapat menyerap kebutuhan kita, kesiapan kita dalam pengukuran kapasitas juga akan berguna untuk mendapatkan harga yang lebih terjangkau. Misalkan kita sudah tahu machine size yang kita butuhkan, kita dapat membeli reserved instance atau CUD pada provider. Intinya kita komitmen akan menggunakan dengan kapasitas tertentu, maka in-return, kita mendapatkan harga yang lebih baik.

Pakai Cloud Langsung Auto Hemat

Meskipun pada beberapa cloud provider seperti AWS dengan reserved instance dan GCP dengan CUD-nya, tidak berarti memindahkan infrastruktur ke cloud provider secara otomatis billing kita akan lebih murah daripada ongkos (baik capex maupun opex) di on-premise. Jika ada anggapan pada cloud kita cenderung akan melupakan capex, anggapan itu tidak sepenuhnya benar, karena kita tetap harus memperhitungkan kapasitas untuk mendapatkan biaya yang kita keluarkan untuk membeli CUD / reserved instances. Mendapatkan harga terbaik dengan cara seperti ini, adalah salah satu cara mendapatkan harga yang lebih baik dan menghemat pengeluaran juga.

Pada migrasi yang dilakukan secara lift and shift, tanpa ada optimasi dan efisiensi, atau melakukan hal yang esensial untuk membuat service lebih “cloud native”, juga tidak akan mereduksi tagihan di akhir bulan. Namun pendekatan migrasi adalah pilihan. Akan sulit untuk mendapatkan akselerasi dari segi waktu migrasi dengan cost efficiency dalam waktu bersamaan, namun kedua hal tersebut dapat dicapai secara berimbang dengan pengaturan prioritas, keep the joyful stuff ala Marie Kondo dan manajemen resiko yang baik.

Network di Cloud Akan Selalu Stabil

Hal ini adalah mitos yang setara dengan keberadaan kuda unicorn, virus corona itu tidak ada konspirasi elit global, atau nama asli Gajah Mada sebenarnya Gaj Ahmad a. Tidak ada penjelasan lebih jauh lagi soal ini. Walau bagaimanapun, ini adalah mitos yang tidak hanya terjadi di cloud namun juga di on-premise. Sebaiknya saat menyusun SLA service sendiri, hal yang paling penting diperhatikan adalah SLA dari dependency yang dimaintain / managed oleh cloud provider. Kemudian secara disiplin menerapkan pendekatan mitigasi network failure seperti circuit breaker, exponential backoff dan sebagainya.

Performa Aplikasi Otomatis Meningkat (atau Minimal Sama Seperti On-Premise)

Pada beberapa kasus, performa cloud resource seperti disk mempunyai constraint tertentu. Misalkan pada GCP, performa disk dibatasi oleh beberapa hal, misalkan jumlah vCPU, besaran disk sampai dibatasi oleh network throughput. Pada aplikasi atau service yang sangat sensitif terhadap latensi, maka hal - hal kecil seperti ini harus diperhatikan.

Naik atau turunnya performa sebuah service atau aplikasi tidak datang dengan tiba - tiba. Justru dengan migrasi ke cloud, akan ada beberapa hal yang berubah, misalkan constraint pada resource yang disebutkan di atas, latency antar service dan dependency serta faktor - faktor lainnya. Maka dari itu, sebelum melakukan cutover ke cloud, sebaiknya perlu dilakukan load testing pada environment non production (staging atau pre-production) untuk dapat dilihat apakah service yang dipasang di cloud dapat memenuhi target pada metrik - metrik sesuai dengan SLO. Jika terdapat bottleneck di suatu bagian pada service, ada baiknya diselesaikan terlebih dahulu masalahnya sebelum dipindahkan ke cloud.

Migrasi Wajib Menggunakan Certified Engineer

Tidak mengatakan bahwa pendekatan ini salah, namun sertifikasi memang bukan penentu utama sukses atau tidaknya sebuah proyek migrasi ke cloud. Walau bagaimanapun, cloud provider pada dasarnya menyuguhkan produk dan solusi, yang mana akan selalu dimutakhirkan sesuai dengan roadmap perusahaan, atau kebutuhan pelanggan. Kebolehan suatu organisasi mendapatkan engineer dengan pengetahuan spesifik ke cloud provider yang akan dipakai, jelas akan mengakselerasi kemajuan atau progres dari proyek migrasi. Produk dari cloud provider bukanlah hal yang rumit untuk dipelajari. Memberikan waktu untuk engineer yang sudah ada, untuk melakukan PoC atau eksperimen dengan resource dan biaya yang terkontrol adalah salah satu cara membantu tim untuk lebih familiar dengan teknologi dan produk cloud provider.

Data di Cloud Tidak Aman

Hal ini sering didengar dari seseorang yang entah awam, atau memang tidak punya pengalaman hidup yang bersinggungan dengan cloud provider. Mulai dari “Data di cloud itu kan seperti taruh data kita di tempat orang, jadi nanti mereka bisa baca data kita” sampai “Data di Cloud itu tidak aman, kan cloud itu publik, nanti bisa dilihat orang”. Jika dinalar ada sebagian pernyataan yang benar, misalkan data kita ada di infrastruktur pihak ke tiga, yang mana kita tidak punya kontrol. Hal ini dapat diselesaikan dengan perjanjian NDA atau penyesuaian layanan dengan peraturan (compliance) yang relevan dengan jenis bisnis. Secara umum, kita dapat bercakap dan berkonsultasi dengan Account Manager dari cloud provider.

Untuk pasal keamanan data, tentu saja sangat bergantung bagaimana kita mencegah hal tersebut terjadi terlepas dari bentuk infrastruktur, entah di on-premise atau di cloud. Pada sebagian kasus data breach, umumnya hal tersebut diakibatkan hal - hal yang tidak secara spesifik berkaitan dengan kapabilitas cloud secara khusus, atau kapabilitas infra secara umum, dan lebih sering berkaitan erat dengan prosedur internal penyimpanan data pengguna - seperti menggunakan dump database dan tidak memperhatikan storage tempat penyimpanan tersebut, hingga keteledoran manusia.

Selain hal tersebut di atas, masih banyak hal yang kontraproduktif lainnya, misalkan menghabiskan waktu untuk berdebat mengenai standarisasi atau konvensi tanpa mempunyai dasar data yang kuat, berpikir bahwa best practice itu overrated, dan berbagai hal picik lain soal cloud dan ihwal lainnya.

Gimana, udah siap pindah ke cloud?

Bird migration Photo by Julia Craice on Unsplash

Ideologi Ultra Konservatif pada Operasional Apache Cassandra

2020-04-17T07:56:02+07:00

konservatif/kon·ser·va·tif/ /konsérvatif/ a 1 kolot; 2 bersikap mempertahankan keadaan, kebiasaan, dan tradisi yang berlaku

Konservatif pada Token Range

Saat pertama kali saya dan tim menggunakan cassandra, saat itu versi paling lama yang kami pergunakan adalah 2.0.x , versi di mana sebenarnya cassandra sudah mengenal konsep vnodes. Sebuah konsep yang mengijinkan alokasi jumlah partisi dan pembagian letak partisi, secara otomatis diatur oleh cassandra itu sendiri. Namun, atas alasan yang cukup konservatif, saat itu, salah satu engineer di tim menolak gagasan penggunaan vnodes.

Meski kami sudah menguji gabungan multi DC cassandra dengan fixed token dan properti file snitch, dengan DC lain yang menggunakan vnodes. Alasannya sederhana, kita membutuhkan sebuah database cluster yang mudah untuk ditebak perilaku penyimpanannya. Hal ini masuk akal. Kami membutuhkan prediksi yang tepat, akan partisi dalam 1 token range atau gabungannya dengan replication factor, sehingga saat nanti kami harus melakukan rolling restart untuk keperluan patch atau update, kami tahu node mana yang harus kami maintain terlebih dahulu, dan mana node berikutnya.

Selain itu, tim akan terbantu ketika ingin melakukan repair data. Karena, tentu saja, kita tahu kemana kita akan mereferensi data. Kita juga akan dapat dengan mudah melakukan repair pada token range tertentu saja. Dengan pembagian yang jelas, ini memang akan mempermudah maintenance pada Cassandra.

Hal lain yaitu jaminan lebih baik pada keseimbangan data yang tersebar di antara nodes dalam 1 Data Center. Meski ini bergantung kembali kepada seberapa seimbang kita membagi sebuah token range utuh kepada jumlah nodes yang kita punya dalam 1 Data Center, namun hal ini setidaknya mengurangi resiko penumpukan token pada titik / node tertentu.

Konservatif pada cara Scaling

Pada 2 perusahaan yang berbeda, saya tetap terus menghindari penggunaan vnodes dan hal itu juga berimplikasi pada keputusan untuk melakukan scaling cluster. Metode scaling cluster cassandra yang saya lebih sukai adalah dengan cara membuat data center baru dengan jumlah node yang lebih banyak, untuk kemudian menggantikan data center existing atau lama yang lebih kecil.

Kemudian data center lama ini akan di decommision setelah service atau aplikasi sudah mengarahkan query request ke data center baru. Untuk dapat melakukan ini, kita harus mengimplementasikan consistency level pada service atau driver aplikasi yang bersifat local, entah itu local one, local quorum dan seterusnya. Selain consistency level, kita juga harus membatasi query hanya terisolasi pada 1 data center.

Implementasi isolasi ini dapat dilakukan dengan mengenable opsi semacam DCAware kemudian mengunci query pada localDc, yaitu data center yang lama - pada saat data center baru sedang disiapkan atau di-rebuild dan kemudian kepada data center baru, setelah data center baru siap. Hal ini sangat memudahkan scaling dan terminasi pada cluster.

Pada vnodes, scaling dapat dilakukan dengan menambah node dan mengubah token. Hal ini berimbas pada pergeseran data yang akan terjadi secara live, karena kepemilikan token berubah. Pada konsep static token juga sangat dihindari metode serupa, yaitu dengan cara menambah node dan menggeser atau mengatur ulang partisi. Jika cluster hanya mempunya 1 data center saja, maka 1 data center yang kemungkinan sedang dipakai oleh service di production, juga akan terbebani dengan operasi internal saat menggeser data di berbagai node ini.

Photo by lcs _vgt on Unsplash

Catatan Kafka : Replikasi

2020-04-06T09:39:27+07:00

Apache Kafka adalah salah satu sistem yang sering dipergunakan untuk membangun data pipeline dan / atau sistem streaming data. Saya sengaja mencatat beberapa bagian penting sebagai sarana untuk mempelajari dan mulai familiar dengan sistem ini.

Salah satu bagian penting dari Kafka adalah Sistem Replikasi. Sistem replikasi pada Kafka adalah bagian penting untuk menjamin durabilitas dan reliabilitas dari Kafka itu sendiri. Setiap topic dan partition pada Kafka direplikasi di 2 jenis replika : Leader Replica, Follower Replica. Kafka menggunakan Leader Replica untuk menjamin konsistensi pada setiap replica partitions karena leader replica (atau Leader saja), akan menerima request producer dan consumer serta memastikan para follower terus ter-update terhadap leader.

Pada skema produce, maka ada 2 macam request berkaitan dengan produce ini : Produce request dan Fetch Request. Produce request adalah request dari client berupa message untuk di “antri” kan ke kafka brokers, sedangkan fetch request, adalah request consume dan produce dari followers kepada leader.Dari sisi client, set konfigurasi acks untuk memastikan konsistensi. Ack bisa 1, -1 atau 0. 1, semua atau fire and forget. Pada beberapa blog berisikan benchmark, sering digunakan ack 0, yang mana pastinya akan menghasilkan grafik yang “indah” pula.

Bicara soal replikasi di kafka, ada istilah ISR atau In-Sync Replica, istilah untuk kafka brokers yang mempunyai data yang sama pada sebuah partisi topik tertentu. Misalkan pada sebuah topik ditetapkan replication factornya 3, maka akan ada 1 leader replica dan 2 follower replica yang mempunyai data yang sama per partisi pada topik tersebut.Jumlah minimal in-sync replica dapat dikonfigurasi untuk menentukan seberapa reliable cluster kafka tersebut. Secara default, min-insync-replica adalah 1, artinya dengan replication factor 3, kita masih dapat melakukan consume dan produce jika ada 2 node yang mati pada partisi tersebut. Hal ini diluar pembahasan konsistensi dan hubungannya dengan ack.

Replica dapat dikatakan dalam status “in-sync” jika memenuhi 3 hal ini :

tetap mempunyai sesi aktif ke zookeeper. broker tetap mengirimkan signal heartbeat ke zookeeper dalam waktu 6 detik (dapat dikonfigurasi pada zookeeper.session.timeout.ms )
melakukan fetch request yang berhasil ke leader dalam kurun waktu 10 detik ( tergantung konfigurasi replica.lag.time.max.ms)
menerima message terakhir dalam rentang 10 detik (poin nomor 2) dari leader.

Dalam skema ack all, maka sebuah request produce baru dikatakan sukses (committed), jika semua replica telah mengkonfirmasi telah menerima message. Untuk lebih jelasnya dapat dilihat pada thread ini di situs stackoverflow : https://stackoverflow.com/questions/50689177/kafka-ack-all-and-min-isr

Konfigurasi semacam replication factor, min insync replica akan menentukan seberapa reliable sebuah kafka cluster. Dengan replication factor yang semakin banyak, tentu meningkatkan availability dari kafka tersebut, semakin lengkap jika ack nya di set ke all, sehingga memastikan semua replika mendapatkan message tersebut. Namun konfigurasi ini juga akan berdampak pada kecepatan / latency request yang semakin meningkat. Berikut konfigurasi broker yang berimplikasi terhadap replikasi dan hubungannya dengan reliabilitas serta kecepatan :

Replication Factor

Pada kafka, sebuah topic dapat dibagi menjadi beberapa partition. dan replikasi terjadi di level partition bukan di topic nya. Jika partition di atur pada parameter num.partitions, maka untuk replication per partition dikenal dengan istilah replication factor, sebuah istilah yang kerap digunakan pada database yang mempunyai sistem replikasi misalkan Cassandra.Replication Factor menentukan seberapa banyak sebuah partition pada topic direplikasi. Misalkan pada topic bernama topic_a , mempunyai 3 partisi. Dan replication factor di set ke angka 3, itu artinya topic_a - partition 0 akan disimpan di 3 broker yang berbeda, begitu juga partition 1 dan seterusnya. Sebuah replication factor X, akan mengijinkan cluster kafka untuk kehilangan X-1 brokers dan tetap dapat menerima request produce dan consume (read / write). Selain memastika setiap replica partition ada di broker yang berbeda, sebaiknya juga pastikan partition tersebut disebar juga di broker yang berada di rak server yang berbeda. Hal ini dapat diterjemahkan juga menjadi multiple Availability Zone pada cloud platform.

Unclean Leader Election

Jika sebuah leader replica kemudian tidak dapat dikontak atau mati, salah satu dari ISR akan segera menggantikannya sebagai leader replica baru. Cara pemilihan (election) ini disebut “clean” election, karena menggaransi tidak ada data yang hilang. Tapi apa yang terjadi ketika tidak ada lagi ISR yang tersisa?Partition akan tetap offline sampai replica - replica tadi kembali hidup atau online. Jika kita mengijinkan replica yang out-of-sync untuk jadi leader, maka kita akan kehilangan beberapa message yang dikirim di interval waktu saat ISR tadi bertumbangan.Mengeset unclean.leader.election.enable menjadi true - di mana ini adalah default value-nya, akan mengijinkan out-of-sync replica menjadi leader (unclean election), namun beresiko pada kehilangan message seperti yang dipaparkan sebelumnya.Namun tanpa adanya konfigurasi ini (set ke false), maka availability jadi lebih rendah karena kita harus menunggu leader replica lama kembali online. Sebaliknya jika kita membahas kualitas data dan konsistensi, maka ada baiknya mengubah konfigurasi unclean leader election ini menjadi false.

Min In-Sync Replica

Pada contoh di atas, kita menetapkan RF (Replication Factor) menjadi 3, maka ada kemungkinan kita hanya mempunyai 1 ISR di cluster. Kita bisa saja menggunakan ack all namun tetap saja akan menunggu sisa ISR untuk kembali online sehingga produce yang kita kirimkan dapat di commit. Pada kasus ini, kita diminta untuk memilih consistency dan availability. Jika kita mengeset min.insync.replicas menjadi 2, maka kita hanya dapat menulis ke topic partition tersebut jika 2 dari 3 replica sedang online. Artinya jika ada 1 mesin mati, kita masih bisa menuliskan message. Namun jika 2 mesin mati / offline, maka yang terjadi client / producer tidak dapat mengirimkan produce request (mendapat error NotEnoughReplicasException ).

Right Application for Right Purpose

2020-01-02T03:39:13+07:00

Sebenarnya penulis ingin membuat tulisan yang membahas tahun lalu dan apa yang telah terjadi, dilanjutkan dengan cita - cita dan target di tahun ini, mengingat itu hal normal yang mungkin setiap penulis atau orang lain lakukan di awal tahun. Tapi mungkin ada baiknya saya menulis refleksi mendasar tentang teknologi yang tidak terlalu teknis, tapi tetap menarik untuk dibahas.

Mengawali tahun ini dengan berbagai target yang sudah ditentukan di dokumen OKR (Objectives and Key Results), pada organisasi masing - masing. Biasanya semua dibuat di akhir masa OKR sebelumnya, dalam hal ini Q4 2019. Di kantor saya yang sekarang ini, ada banyak misi yang harus diselesaikan oleh tim teknologi. Misi tersebut sudah dituangkan dan diperjelas dalam dokumen, presentasi dan berbagai bentuk pesan lain, dari pemimpin organisasi hingga pemimpin bagian masing - masing. Untuk mengejar target misi tersebut, kami bukan hanya berlari dengan mengerjakan tugas, namun membawa bertumpuk - tumpuk pengalaman yang sudah didapatkan di masa sebelumnya.

Salah satu pengalaman yang paling saya ingat adalah bagaimana, di masa lalu, organisasi dan bagian di dalamnya melakukan beberapa kesalahan yang fundamental, hingga pada akhirnya ada harga yang harus dibayar di kemudian hari. Kesalahan tersebut bisa berupa kesalahan metode, kesalahan prosedur hingga kesalahan arsitektural. Dan hal paling mendasar adalah kesalahan arsitektural.

Kesalahan arsitektural dalam membangun perangkat lunak yang melayani trafik yang sangat tinggi, memerlukan pendalaman masalah yang sangat intens. Karena banyak akibat yang harus dihadapi, termasuk akibat yang tidak diantisipasi dari awal. Dalam kesalahan arsitektural, sering kali ditemui kecerobohan dalam memilih aplikasi perangkat lunak tertentu untuk menyelesaikan masalah spesifik.

Misalkan saja memilih menggunakan aplikasi batch stream untuk penyimpanan semi permanen, atau bahkan permanen. Memilih menggunakan aplikasi penyimpanan pada memori volatile sebagai kakas basis data. Hal ini terjadi bahkan kerap terjadi karena berpikir segala macam permasalahan performa, dapat diatasi dengan mengoptimalkan aplikasi dari sisi penunjang atau dari sisi infrastruktur. Berpikir bahwa sumber daya tidak terbatas. Tentunya pemikiran ini tidak sepenuhnya benar, karena jika hal ini terjadi di ekosistem yang dibangun di cloud infrastructure, maka segalanya menjadi amat terbatas.

Pemilihan aplikasi penunjang seperti database system, caching system, queue system dan sebagainya, memerlukan pengetahuan akan kinerja aplikasi yang dibuat, cara kerja aplikasi penjunjang tersebut dan operasional dibalik aplikasi penjunjang itu semua. Hal ini juga tetap diperlukan bila aplikasi penjunjang tersebut disediakan oleh pihak lain atau yang kerap disebut managed service.

Kesalahan pemilihan tech stack ini selain setumpuk technical debt tapi juga permasalahan performa yang pada akhirnya dikonversi menjadi pemborosan biaya secara langsung. Bukan lagi biaya manusia lagi, tapi biaya sumber daya seperti ongkos server atau bahkan server dan bandwidth. Tidak selamanya kita dapat menambal kekurangan aplikasi dengan menambahkan CPU atau alokasi memori ke mesin. Seperti tidak selamanya uang akan menyelamatkan performa aplikasi.

Sebuah organisasi yang mencari profit dengan teknologi sebagai tulang punggung, tidak harus memiliki seorang dengan titel Arsitek, entah itu software architect, infrastructure architect dan lain sebagainya. Namun ada baiknya mempunyai tim ad-hoc yang dapat dibentuk jika dibutuhkan, untuk membahas arsitektur sebuah service baru atau merombak arsitektur service lama yang bermasalah. Seperti dalam sebuah pemerintahan, Presiden terkadang membentuk tim pencari fakta yang sifatnya tidak permanen. Tentunya tim tersebut harus berisikan insinyur - insinyur teknologi yang berkompeten serta jika memungkinkan, mempunyai pengalaman yang sangat bervariasi.

Setelah mengetahui bahwa kesalahan arsitektural adalah kesalahan yang sangat mendasar, semoga di tahun ini (2020) ke depan, tidak ada lagi yang menggunakan Redis sebagai database system (yang persistent dan dalam jumlah data yang besar) lagi.

…. Aamiin ….

Ekspansi Prometheus Storage dengan TimescaleDB

2019-08-29T07:07:55+07:00

Prometheus adalah monitoring tools yang hampir tidak pernah saya lihat, sampai suatu ketika saya harus bersinggungan dengan Kubernetes.

Prometheus, secara “mutlak” dipakai oleh Kubernetes dan lingkungannya, termasuk Istio yang masyhur itu, sebagai monitoring tools atau sederhananya pengepul angka dari metrics perkakas - perkakas kubernetes. Dalam konfigurasi yang ringkas, maka prometheus akan dipasang sebagai sidecar dari pod atau sebagai statefulset yang mengambil metrics dari pod, Istio atau metrics yang diekspose oleh exporter. Misalkan redis exporter.

Jika di zoom ke bagian monitoring saja, maka rute nya akan jadi begini :

Exporter / Istio Telemetry -> Prometheus -> (Optional) Stackdriver
                                         -> Grafana

Pada prakteknya, prometheus sering kewalahan dipakai sebagai database timeseries baik ingest dari metrics source maupun untuk diplot dalam bentuk grafik di kakas semacam Grafana. Prometheus akan menggunakan sumber daya, seperti beban memori yang terlalu besar. Dan penumpukan data pada file yang diambil dari persistent disk juga membuat Prometheus semakin hari semakin bloated, gemuk - tanpa nada atau niatan body shaming. Sifatnya yang cenderung stateful ini membuat Prometheus sulit untuk di-scale. Adapun solusi scaling up Prometheus adalah dengan dua solusi, yang pertama adalah mode federated. Yang artinya akan ada lebih dari 1 prometheus dengan konsep DC dan sebagainya, namun kelemahan mode ini adalah tingkat kerumitan dalam pengaturan distribusi node prometheus dan ketika di-query tetap menuju ke 1 node prometheus, maka kebuntuan penggunaan sumber daya memori tetap terjadi. Karena tetap saja tidak terdistribusi pembagian bebannya. Solusi ke-dua adalah dengan cara sharding, alias membagi job scrape ke dalam beberapa prometheus yang berdiri secara terpisah.

Dalam permasalahan tersebut, akhirnya muncul beberapa solusi untuk mengatasi kebuntuan sumber daya, misalkan yang paling populer saat tulisan ini dibuat adalah Thanos. Thanos menjanjikan pemetaan fungsi yang tadinya dibebankan semua pada prometheus menjadi lebih terbagi-bagi berdasarkan fungsinya. Thanos mempunyai thanos sidecar sebagai shipper, ada thanos query yang nanti akan menerima user request, ada thanos compactor untuk memelihara file yang dihantarkan shipper ke penyimpanan pihak ketiga (third party storage, seperti GCS, S3 atau Ceph backed storage). Dengan banyaknya komponen ini, Thanos mempunyai kelemahan yaitu tingkat kerumitan yang cukup tinggi. Belum tentu juga menjamin komponen Thanos Query ini tidak mengalami kebuntuan dari segi penggunaan memori.

Untuk itu saya berpikir sedikit lebih sederhana. Mengapa tidak menghantarkan data dari Prometheus ke penyimpanan secara remote (remote write dan remote read), kemudian Grafana tinggal melakukan query ke penyimpanan tersebut. Penyimpanan di sini diartikan sebagai basis data (database), yang didukung oleh Grafana sebagai datasource, misalkan InfluxDB atau PostgreSQL.

Pilihan percobaan jatuh kepada PostgreSQL gara - gara saya hanya menginginkan teknologi yang lebih familiar buat saya pribadi. Namun ternyata PostgreSQL tidak dapat berdiri sendiri, jika kita ingin menjadikannya sebagai timeseries database. PostgreSQL butuh plugin Timescale yang menjadikan kombinasi ini sebagai TimescaleDB.

Tulisan ini tidak akan menjelaskan langkah perlangkah untuk mengonfigurasi sebuah server atau banyak server menjadi tempat penyimpanan metrics dari Prometheus. Karena langkah tersebut dapat ditemukan di sini : “ Getting started with Prometheus and TimescaleDB” (https://docs.timescale.com/v0.10/tutorials/prometheus-adapter). Saya hanya akan membahasnya secara konseptual dan membagikan pengalaman saat mengimplementasikannya.

Dengan menggunakan TimescaleDB, maka rutenya menjadi seperti ini :

Exporter / Istio Telemetry -> Prometheus -> Prometheus PostgreSQL Adapter -> PostgreSQL server + Timescale + Pg_prometheus -> Grafana

Jika dibandingkan dengan Thanos, saya rasa solusi ini lebih sederhana dan masuk akal jika ditilik dari segi kesederhanaan. Hal ini sedikit berbeda dengan Thanos yang menyebutkan bahwa solusi mereka didesain dengan konsep KISS (Keep It Simple, Stupid), menurut saya sih Thanos tidak simple.

Pada solusi TimescaleDB sebagai “long term database for Prometheus” ini, maka kita perlu mempersiapkan (selain Prometheus dan Grafana):

PostgreSQL
PostgreSQL yang dipersiapkan bisa pakai versi stabil terakhir (saat ini 11) dengan tambahan library timescaledb dan Pg_prometheus.
Prometheus PostgreSQL adapter
Adapter yang akan berbicara di protokol http dan menerima ingest dari Prometheus

Kedua hal di atas dapat disatukan pada satu server atau dipisah. Sesederhana bumbu kacang pada sate, dipisah atau dicampur. Pada prometheus akan ditambahkan baris konfigurasi untuk melakukan remote write dan remote read ke Prometheus PostgreSQL Adapter.

Saya kira dengan diaktifkannya remote write, prometheus akan berhenti menulis ke penyimpanan permanennya, namun ternyata tidak. Prometheus tetap menulis file TSDB yang dipakainya sebagai simpanan lokal. Nah, berarti solusi ini tidak akan berdampak pada membeludaknya ukuran database di Prometheus. Namun setidaknya dapat mencapai tujuan untuk menyelamatkan data prometheus jika memang terjadi apa-apa terhadap Prometheus-nya.

Yang perlu diperhatikan juga adalah penggunaan query timeseries pada grafana yang pada praktiknya adalah query PostgreSQL dengan tambahan makro time series atau time bucket di sana. Query tidak sesederhana PromQL yang dengan mudahnya melakukan perhitungan aritmatika hanya dengan 1 line query. Bahkan sampai tulisan ini saya buat, saya belum dapat menemukan semua pengganti sepadan syntax PromQL misalkan irate. Namun hal ini dapat diatasi dengan riset pada metrics tertentu yang membutuhkan query yang (mungkin) kompleks. Dengan ‘kemudahan’ dan ‘popularitas’ SQL, seharusnya ini tidak menjadi masalah di kemudian hari.

Referensi :

Flash Lineage OS ke Oneplus 3 dengan Ubuntu 18.04 Desktop LTS

2019-04-22T17:21:03+07:00

[Do it with your own risk.] Berikut ini dokumentasi yang saya lakukan saat flashing Lineage OS ke Oneplus 3. Mungkin juga berlaku untuk Oneplus 3T. Hal ini worth untuk dilakukan mengingat Oneplus 3 sudah di ambang masa obsolete support nya untuk mendapatkan update Oxygen OS.

Yang perlu dipersiapkan :

Ubuntu 18.04 Desktop LTS
Lineage OS yang dapat diunduh di sini : https://download.lineageos.org/oneplus3
TWRP image dari sini : https://dl.twrp.me/oneplus3/twrp-3.3.0-1-oneplus3.img.html
GApps. kecuali seorang pemboikot Google :) dapat diperoleh dari sini : https://opengapps.org/

Persiapan

Sebelum semuanya dilakukan, backup data penting ke cloud. Skenario yang saya lakukan adalah dengan mem-format internal storage tanpa menyisakan data.

Pada Ubuntu 18.04 tersebut, pasang android tools yang nanti akan dibutuhkan

sudo apt update
sudo apt install android-tools-adb android-tools-fastboot

Unlock Bootloader

Pada Oneplus 3, buka Setting. Kemudian pada About Phone, tap di Build Number sampai keluar pesan semacam “You are now a Developer”.

Pada Developer menu, aktifkan hal berikut:

Enable USB Debugging
Enable OEM Unlock / Allow Bootloader Unlock
Enable Advance Reboot

Matikan Oneplus 3, lalu nyalakan kembali dengan menekan Volume Up + Power Button secara bersama. Setelah masuk mode fastboot, hubungkan Oneplus 3 dengan komputer dengan Ubuntu tadi.

Bukalah aplikasi Terminal atau Terminator, lalu gunakan perintah ini untuk mendeteksi apakah device sudah dikenali fastboot devices .

Untuk meng-unlock bootloader, gunakan perintah ini fastboot oem unlock pada step ini saja, data anda akan hilang.

Flash TWRP

Kemudian flash TWRP yang tadi didapatkan dari sini : https://dl.twrp.me/oneplus3/twrp-3.3.0-1-oneplus3.img.html

fastboot flash recovery <namafile_TWRP_disini>.img
fastboot boot <namafile_TWRP_disini>.img

Hapus ini Hapus itu

[Achtung! Data akan diformat!]

Jika TWRP menanyakan password untuk decrypt, lewati saja (tekan cancel). Kemudian pada menu Wipe - Format Data. Sebelum dilakukan, ada baiknya dibackup sendiri datanya. Ingat, saya memang berencana untuk menghapus partisi agar tidak diributkan dengan urusan decrypt partition nantinya. Hapus Cache juga jika perlu.

Flash ROM

Masih di TWRP, tap back dan masuk menu Advanced. Kemudian pilih ADB Sideload.

Dengan posisi Oneplus 3 terhubung ke Ubuntu, buka terminator, dan lakukan sideload 2 image file yaitu image Lineage OS yang diunduh dari sini https://download.lineageos.org/oneplus3 dan GApps dari sini https://opengapps.org/

adb sideload lineage-16.0-20190420-nightly-oneplus3-signed.zip
adb sideload open_gapps-arm64-9.0-stock-20190420.zip

setelah terpasang, jangan lupa untuk mengunci / lock boot loader dengan masuk kembali ke fastboot pada Oneplus 3 dan kirim perintah ini fastboot oem lock

Saya sendiri mengulang - ulang beberapa perintah di atas dan menemui permasalahan seperti ini :

Lineage terpasang, boot, tapi tidak dapat melakukan decrypt storage (maka saya format habis saja)
Lineage terpasang, tapi somehow stuck (maka akhirnya saya coba untuk lock kembali bootloader)

Saya pun baru tahu bahwa Android 9 punya masalah pada decrypt data yang kita encrypt di Android versi sebelumnya. https://forum.xda-developers.com/oneplus-3/oneplus-3–3t-cross-device-development/rom-lineageos-16-0-oneplus-3-3t-t3866517

Selamat datang Lineage!

[Update 6 April 2020]

Untuk upgrade perlu install firmware modem baru : https://www.androidexplained.com/oneplus-3-upgrade-modem/
Install firmware sebelum sideload lineageos

Django, Gunicorn and Nginx

2019-04-14T15:34:25+07:00

Sebenarnya postingan pertamax dengan judul “Silo atau Limbo” itu post yang sudah ada dari jaman domain vanjava.web.id. Harusnya ini postingan pertamax yang sesungguhnya. Pertamax pertamax mulu kek masih main Kaskus aja.

Postingan kali ini saya mau mendokumentasikan bagaimana konfigurasi Django Framework (yang pada saat tulisan ini dibuat, versi stable terakhir adalah 2.2) di sistem Operasi Linux Ubuntu versi 18.04 LTS dengan Gunicorn sebagai WSGI server dan Nginx sebagai garda terdepan.

Sebenarnya dokumentasi ini tidak hanya berlaku untuk Django Framework saja, tapi (mungkin) juga masih applicable untuk python based web framework lainnya seperti Flask, CherryPy dan lain sebagainya.

Instalasi Django

Untuk memasang django, dapat dimulai memasang beberapa dependensi

sudo apt update
sudo apt install python3 python3-venv

Kemudian buatlah python3 virtual environment. Mengapa harus virtual environment? Baca ini saja. Python Virtual environment.

python3 -m venv /path/to/virtualenv
# contoh
python3 -m venv /opt/robee-env/

Setelah virtual environment dibuat, aktifkan dan pasang django di dalam virtual environment

source /path/to/virtualenv/bin/activate
pip install django

Mengapa ditebalkan bagian “di dalam virtual environment”, sekali lagi baca url ini Python Virtual environment.

Masih di dalam virtual environment, pastikan django terpasang dengan baik

>>> import django
>>> print(django.get_version())
2.2

Dengan asumsi source code project django kita letakkan di /path/to/mydjangoproject/ maka :

cd /path/to
django-admin startproject mydjangoproject

maka nanti akan ada django project baru pada /path/to/mydjangoproject/ bersama dengan struktur django di dalamnya. Untuk menguji apakah django sudah dapat serve :

cd /path/to/mydjangoproject/
python manage.py runserver 0.0.0.0:8080

kemudian cobalah untuk mengakses http://localhost:8080 dan akan didapati lama seperti ini

Untuk membuat sebuah aplikasi django dan berbagai fungsi atau fitur lainnya, silakan dilanjutkan untuk mempelajarinya di sini : Django Framework

Gunicorn

Gunicorn sendiri merupakan sebuah WSGI HTTP Server yang dapat berfungsi meneruskan client request ke python. Laman resminya bisa dipantau di sini : https://gunicorn.org/

Mengapa harus WSGI Server?

Sebenarnya setiap python web frameworks punya built-in http server sendiri, misalkan Django dengan manage.py runserver atau Flask dengan flask run . Tapi secara general, built in http server tersebut hanya diperuntukkan pada level development saja. Sedangkan untuk production, WSGI server lebih diutamakan karena kemampuannya untuk spawn multi proses untuk kemudian diteruskan ke multi CPU, kemudian mempunyai fitur logging yang lebih baik (meski ini juga masih debatable), lebih dapat dioptimasi untuk performa yang lebih baik lagi. Khususnya untuk Gunicorn, WSGI HTTP Server ini juga mudah sekali dikonfigurasi.

Untuk memasang gunicorn, pastikan kita masih di python virtual environment yang tadi sudah kita buat.

source /path/to/virtualenv/bin/activate
pip install gunicorn

masih di virtualenv, kita juga bisa menjalankan django di atas gunicorn

cd /path/to/mydjangoproject/
gunicorn mydjangoproject.wsgi -b 0.0.0.0:8081

[2019-04-14 22:01:54 +0700] [18174] [INFO] Starting gunicorn 19.9.0
[2019-04-14 22:01:54 +0700] [18174] [INFO] Listening at: http://0.0.0.0:8081 (18174)
[2019-04-14 22:01:54 +0700] [18174] [INFO] Using worker: sync
[2019-04-14 22:01:54 +0700] [18177] [INFO] Booting worker with pid: 18177

kemudian kita dapat mengakses django yang dijalankan di atas gunicorn di http://localhost:8081

Nah untuk men-_daemonize_ gunicorn pada systemd Ubuntu, maka kita bisa melakukan ini

Tulis socket file baru di sini sudo vim /etc/systemd/system/gunicorn.socket

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

Kemudian buat file untuk service nya sudo vim /etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=namauser
Group=namavalidgroup
WorkingDirectory=/path/to/mydjangoproject
EnvironmentFile=/path/to/virtualenv
ExecStart=/path/to/virtualenv/bin/gunicorn \
          --access-logfile /path/to/logfile \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          mydjangoproject.wsgi:application

[Install]
WantedBy=multi-user.target

Untuk namauser, namavalidgroup dan path ke logfile dapat diubah sesuai dengan kondisi masing-masing.

Untuk menyalakan service gunicorn

sudo systemctl daemon-reload
# start gunicorn with mydjangoproject
sudo systemctl start gunicorn.service
# mematikan gunicorn
sudo systemctl stop gunicorn.service
# melihat status gunicorn
sudo systemctl status gunicorn.service
# merestart service gunicorn
sudo systemctl restart gunicorn.service

Nginx Reverse Proxy

Menggunakan Nginx (engine x, bukan nging) sebagai reverse proxy, bukan hanya untuk reverse proxy saja. Namun karena beberapa kebutuhan seperti terminasi SSL Certificate, menerapkan limit burst, melakukan load balancing jika memiliki lebih dari 1 backend gunicorn dan fitur nginx lainnya. Dalam skala yang lebih besar, tentu saja nginx saja tidak cukup. Jika diperlukan application load balancer seperti AWS ELB atau ALB atau HTTPS Proxy di GCP dan lain sebagainya, maka hal tersebut juga bisa jadi pilihan. Terutama jika membicarakan sistem microservice yang kompleks, maka solusinya bisa saja menggunakan Envoy proxy, Finagle, Proxygen atau Linkerd. Tapi kali ini mengesampingkan kompleksitas itu, penulis hanya ingin menggunakan nginx saja.

Pemasangan dan konfigurasi dasar nginx sudah banyak dibahas di lain tempat. Maka pada bagian ini penulis hanya berfokus pada vhost config yang menerapkan konsep reverse proxy dari nginx ke gunicorn. Maka buat file vhost baru sudo vim /etc/nginx/sites-available/mydjangoproject

server {
    listen 80;
    server_name namaserver;

    location = /favicon.ico { access_log off; log_not_found off; }
    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

Demi menghindari log favicon yang deras, biasanya saya pribadi membuang log akses favicon. Untuk namaserver dapat diganti dengan IP server kita atau nama domain yang diarahkan record-nya ke IP server kita.

Konfigurasi sudah selesai, dan django dapat bekerja di port 80 dan diserve oleh Nginx yang melakukan reverse proxy terhadap gunicorn. Pada kesempatan lain akan dibahas juga bagaimana pengelolaan file media upload, asset static pada Django Framework (baca: jika ada waktu).

Good bye now, be nice!

Silo atau Limbo

2019-04-06T17:54:31+07:00

Pada organisasi teknologi kontemporer, sangat lumrah jika ada sebuah tim yang dikhususkan untuk memelihara infrastruktur baik itu pada cloud platform atau yang berbentuk fisik di datacenter alias on-premise. Meskipun banyak organisasi, yang bertahap menuju mode no-ops, tapi setidaknya, ada satu atau sekelompok manusia yang berurusan dengan infrastruktur. Pengingkaran pada pekerjaan infrastruktur adalah halusinasi belaka.

Seiring organisasi berkembang, entah skala bisnis, karyawan maupun produk tim software engineering, maka biasanya semakin banyak hal yang mesti ditangani oleh tim infrastruktur. Bisa jadi pada bagian logging, tadinya cukup 1 log server, kini ada kebutuhan untuk mengembangkan sebuah perkakas untuk menganalisa log yang mempermudah pekerjaan berkaitan dengan penanganan insiden. Atau perkakas untuk continuous integration yang tadinya hanya dipakai untuk 10 jobs_sekarang dipakai ribuan _jobs. Dan masih banyak lagi.

Ada beberapa hal di ruang lingkup tanggung jawab tim infrastruktur yang ikut scale bersamaan dengan berkembangnya perusahaan. Beberapa di antaranya dapat diserahkan ke pihak ke-tiga, namun atas berbagai pertimbangan, organisasi dan manajemen memutuskan untuk dipelihara oleh tim itu sendiri. Berbagai hal tersebut bisa jadi menyangkut kompleksitas antara biaya dan kebutuhan spesifik, atau komplikasi antara aturan dan ketersediaan opsi di luar sana, atau bisa apa saja. Keputusan menangani pengembangan tanggung jawab di berbagai sisi tanggung jawab tim infrastruktur ini mengarahkan pemisahan bagian kerja atau spesialisasi kerja.

Normalnya manusia adalah keterbatasan. Entah terbatas akal – pikiran, waktu – ruang, atau uang – etos kerja. Sebuah tim yang tadinya fluid sekarang harus terpisah atau silo-ed on purpose. _Pada sebuah organisasi yang mengakulturasi istilah _DevOps tentunya ini seakan bertentangan dengan salah dua konsep di dalamnya yang mengagungkan sharing knowledge dan sharing responsibility. Berbagi pengetahuan dengan harapan dapat berbagi tanggung jawab bersama semua anggota tim (baik pengembang maupun infrastruktur). Jika DevOps adalah Kal-El, maka Silo adalah salah satu batu kripton yang dapat melemahkan konsep dan kultur ini.

Entah konsep berbagi tanggung jawab ini terlalu naif, atau sebenarnya Silo adalah keniscayaan, tapi sebenarnya segala keterbatasan tersebut menjadi peluang mengeruk pundi – pundi emas dengan menyediakan jasa untuk meringankan beban organisasi. Jika disadarkan, pilihannya apakah kembali mempertimbangkan pihak ke-tiga alias kapitalis masalah – dengan memaklumi dan menerima kekurangan, atau masih bersikeras pada bentuk organisasi infrastruktur yang tidak ideal – dengan memaklumi segregasi antar bagian. Pilihan yang seolah berputar dalam limbo pikiran.

Diskusi? Yuk lah!