4_DevOps_Best_Practices

Embrace Modular Architecture

Microservices

• Memecah aplikasi menjadi layanan-layanan yang lebih kecil dan independen.
• Manfaat: scalability, flexibility, dan maintenance yang lebih mudah.
• Best Practices:
  • Definisikan batas layanan (service boundaries) yang jelas.
  • Gunakan API gateway.
  • Pastikan layanan loosely coupled.
• Pitfalls: layanan yang terlalu granular (terlalu kecil-kecil) bisa menambah kompleksitas; pastikan ada orkestrasi layanan yang tepat.

Monolithic vs Microservice

Aspek	Monolithic Architecture	Microservices Architecture
Struktur	Satu kesatuan: User Interface → Business Layer → Data Interface → 1 Database	Kumpulan microservice independen (Microservice UI, Microservice, dst), masing-masing bisa punya database sendiri
Coupling	Tight coupling antar layer	Loosely coupled antar service
Skalabilitas	Sulit diskalakan sebagian	Tiap service bisa diskalakan independen

Security by Design

Prinsip

• Shift security left — integrasikan keamanan ke proses development sejak awal, bukan di akhir.
• Lakukan threat modeling.
• Terapkan least privilege access.
• Pastikan keamanan menjadi bagian dari CI/CD pipeline.

Pitfalls: mengabaikan keamanan di tahap awal bisa menimbulkan kerentanan (vulnerabilities).

Best Practices

• Gunakan secure coding practices.
• Regularly update dependencies.
• Lakukan security audits secara berkala.
• Gunakan automated security testing tools.
• Terapkan access control (RBAC — Role-Based Access Control).
• Encrypt sensitive data.

Implement Infrastructure as Code (IaC)

• Best practices: simpan kode infrastruktur di version control, gunakan modular templates, dan otomasi testing terhadap perubahan infrastruktur.
• Manfaat: konsistensi, version control, dan otomasi.
• Tools: Terraform, AWS CloudFormation, atau Ansible.
• Pitfalls: perubahan manual bisa menyebabkan drift (ketidaksesuaian state infrastruktur dengan kode); hindari hardcoding value.

Automate with CI/CD Pipelines

• Automation: otomasi proses build, test, dan deployment.
• Manfaat: rilis lebih cepat, error berkurang, kolaborasi meningkat.
• Best Practices:
  • Gunakan feature flags.
  • Terapkan automated rollback.
  • Pastikan fast feedback loops.
• Pitfalls: test yang berjalan lama (long-running tests) bisa memperlambat pipeline; pastikan test efisien dan relevan.

Prioritize Monitoring and Logging

• Terapkan monitoring dan logging yang komprehensif demi observability.
• Best practices:
  • 3 pilar observability: trace, metrics, dan log.
  • Centralized logging.
  • Structured logs.
  • Actionable alerts.
  • Menyiapkan key metrics.
  • Menerapkan anomaly detection.
• Tools: Prometheus, Grafana, dan ELK Stack.
• Pitfalls: terlalu banyak alert bisa menyebabkan alert fatigue; pastikan alert bersifat actionable.

Design for Reliability

• Terapkan redundancy untuk menangani kegagalan secara graceful.
• Gunakan load balancing, failover strategies, dan latihan chaos engineering secara berkala.
• Pastikan sistem dirancang untuk degrade gracefully (menurun performanya secara terkendali, bukan langsung crash total).

Incident Management

Prinsip

• Prepare for incidents — siapkan diri sebelum insiden terjadi.
• Manage incidents effectively — kelola insiden secara efektif saat terjadi.

Best Practices

• Kembangkan incident response plan.
• Lakukan postmortem.
• Gunakan blameless incident reviews — review insiden tanpa saling menyalahkan, fokus pada perbaikan sistem/proses.

Foster a Collaborative Culture

• Dorong komunikasi terbuka antar tim.
• Best Practices: gunakan collaborative tools, lakukan retrospective secara rutin, promosikan budaya blameless, pastikan ada tim cross-functional.
• Pitfalls: silo bisa menghambat kolaborasi; pastikan tim bersifat cross-functional.

Pitfall Umum Lain dalam Desain DevOps

• Over-Engineering — hindari kompleksitas arsitektur yang tidak perlu.
• Neglecting Documentation — pastikan semua proses dan konfigurasi terdokumentasi dengan baik.
• Ignoring Feedback — terus kumpulkan dan tindak lanjuti feedback dari monitoring dan laporan pengguna.
• Resistance to Change — bangun budaya yang menerima perubahan dan continuous improvement.

DevOps & Operasi: Pembagian Tanggung Jawab Dev vs Ops

Aspek	Pembagian Tanggung Jawab
Hardware provisioning	Hardware virtual bisa dialokasikan oleh tim development atau aplikasi dengan otomasi lebih besar.
Software provisioning	Software yang dikembangkan secara internal di-deploy oleh Dev; software lain disediakan oleh Ops.
IT function provision	Sejauh Dev bertanggung jawab atas incident management dan deployment tools, Dev harus punya orang dengan keahlian untuk itu.
Specification and monitoring of SLA	Untuk SLA yang spesifik ke suatu aplikasi, Dev bertanggung jawab memonitor, mengevaluasi, dan merespons insiden.
Capacity planning	Dev bertanggung jawab atas capacity planning aplikasi individual; Ops bertanggung jawab atas capacity planning keseluruhan.
Business continuity	Dev bertanggung jawab pada aspek yang melibatkan arsitektur aplikasi; Ops bertanggung jawab pada sisanya dan menyediakan layanan/kebijakan yang dipakai Dev.
Information security	Dev bertanggung jawab pada aspek yang melibatkan aplikasi tertentu; Ops bertanggung jawab pada sisanya.

DevOps & Arsitektur

Penerapan DevOps dapat memicu perubahan arsitektur sistem:

• Treat Ops as first-class citizens dari sudut pandang requirement — menambahkan requirement dari Ops ke sistem mungkin memerlukan modifikasi arsitektur.
• Make Dev more responsible for relevant incident handling — begitu Dev sadar akan requirement penanganan insiden, bisa muncul modifikasi arsitektur.
• Enforce deployment process yang dipakai semua pihak (Dev & Ops) — berpotensi mengubah struktur sistem.
• Use continuous deployment — mungkin memerlukan perubahan arsitektur.
• Develop infrastructure code — bisa mempengaruhi arsitektur dari kode infrastrukturnya sendiri.

Amazon’s Rules for Team (Prinsip Service Interface ala Bezos)

• Semua tim wajib mengekspos data dan fungsionalitasnya melalui service interface.
• Tim harus saling berkomunikasi hanya melalui interface tersebut.
• Tidak ada bentuk komunikasi lain yang diizinkan antar service/tim: tidak boleh direct linking, tidak boleh membaca langsung datastore tim lain, tidak boleh shared-memory model, tidak boleh ada backdoor apa pun. Satu-satunya komunikasi yang diizinkan adalah lewat service interface call melalui network.
• Tidak masalah teknologi apa yang dipakai tim/service lain.
• Semua service interface, tanpa terkecuali, harus didesain dari awal agar bisa di-externalize — tim harus merencanakan dan mendesain agar interface tersebut bisa diekspos ke developer di luar organisasi.

Prinsip Arsitektur Microservice

• Concern operasional dipertimbangkan sejak requirements specification.
• Struktur sistem secara keseluruhan seharusnya berupa kumpulan layanan kecil dan independen.
• Setiap layanan harus distrustful (tidak sepenuhnya percaya) baik terhadap client maupun layanan lain yang dibutuhkannya.
• Peran tim sudah didefinisikan dan dipahami.
• Layanan wajib teregistrasi dengan local registry/load balancer, dan harus memperbarui registrasinya secara periodik.
• Layanan harus menyediakan SLA bagi kliennya.
• Layanan sebaiknya stateless dan diperlakukan sebagai transient.
• Jika layanan harus menyimpan state, state tersebut harus disimpan di external persistent storage.
• Layanan harus punya alternatif jika layanan yang menjadi dependensinya gagal.
• Layanan punya defensive checks untuk mencegat input keliru dari client maupun output keliru dari layanan lain.
• Penggunaan layanan eksternal, informasi environment, dan software/library pihak ketiga harus dilokalisasi (harus melewati modul khusus untuk layanan/environment/library eksternal tersebut).

Kesimpulan

Mengintegrasikan prinsip DevOps ke dalam desain aplikasi menghasilkan peningkatan delivery, reliability, dan scalability. Kuncinya:

• Merangkul modular architecture.
• Mengotomasi proses.
• Memprioritaskan security dan monitoring.
• Membina budaya kolaboratif.

Flashcard

flashcards Apa perbedaan struktural utama antara Monolithic Architecture dan Microservices Architecture? :: Monolithic: satu kesatuan (UI-Business Layer-Data Interface) yang berbagi satu database, tight coupling. Microservices: kumpulan service kecil independen yang loosely coupled, masing-masing bisa punya database sendiri. Apa maksud prinsip “Shift security left” dalam Security by Design? :: Mengintegrasikan pertimbangan keamanan ke dalam proses development sejak tahap paling awal, bukan ditambal di akhir setelah aplikasi selesai dibangun. Sebutkan 3 tools populer untuk Infrastructure as Code (IaC). :: Terraform, AWS CloudFormation, dan Ansible. Apa itu “drift” dalam konteks IaC dan bagaimana mencegahnya? :: Drift adalah ketidaksesuaian antara kode infrastruktur dan kondisi aktual infrastruktur akibat perubahan manual; dicegah dengan menyimpan semua kode infrastruktur di version control dan mengotomasi testing perubahan infrastruktur, menghindari hardcoded values. Sebutkan 3 pilar observability. :: Trace, metrics, dan log. Apa itu blameless incident review dan mengapa penting? :: Review insiden yang berfokus pada perbaikan sistem/proses tanpa menyalahkan individu, penting agar tim mau terbuka melaporkan masalah dan belajar dari insiden tanpa rasa takut. Menurut pembagian tanggung jawab DevOps & Operation, siapa yang bertanggung jawab atas capacity planning aplikasi individual vs keseluruhan? :: Dev bertanggung jawab atas capacity planning untuk aplikasi individual, sedangkan Ops bertanggung jawab atas capacity planning keseluruhan (overall). Sebutkan inti dari “Amazon’s Rules for Team” terkait komunikasi antar tim/service. :: Semua tim wajib mengekspos data/fungsionalitas lewat service interface dan hanya boleh berkomunikasi lewat interface tersebut (via network) — tidak boleh direct linking, direct read datastore tim lain, shared-memory, atau backdoor apa pun; semua interface harus didesain agar bisa di-externalize. Sebutkan 4 pitfall umum lain dalam desain DevOps selain yang sudah dibahas per topik. :: Over-engineering, neglecting documentation, ignoring feedback, dan resistance to change.