Membangun Azure yang Tahan Kondisi Dunia Nyata — bersama Mike Martin [MVP]

Arsitektur Azure terlihat mudah ketika semuanya berjalan dengan baik. Ujian sebenarnya dimulai ketika dependensi gagal, region menjadi tidak tersedia, lonjakan trafik terjadi, asumsi ternyata salah, persyaratan berubah, dan pada akhirnya seseorang mengajukan pertanyaan yang tidak nyaman: mengapa kita mendesainnya seperti ini sejak awal?Dalam episode ini dari M365.FM, Mirko Peters berbincang dengan Mike Martin [MVP] tentang seperti apa arsitektur Azure ketika harus bertahan dalam kondisi produksi yang nyata, bukan sekadar terlihat bagus di sebuah diagram.Mike memiliki pengalaman puluhan tahun di bidang pengembangan, infrastruktur, arsitektur, kepemimpinan, coaching, pelatihan, dan Microsoft Azure. Salah satu pengamatan terkuatnya adalah bahwa banyak masalah yang dihadapi arsitek saat ini sebenarnya bukan hal baru. DNS tetap bisa bermasalah, dependensi IP tetap penting, biaya tetap menjadi persoalan, integrasi tetap bisa gagal, dan dependensi tetap bisa menghilang pada saat yang paling buruk.Yang telah berubah adalah tingkat kompleksitas yang kita bangun di sekitar masalah-masalah tersebut.

DARI VISUAL BASIC HINGGA ARSITEKTUR AZURE MODERN
Mike menengok ke belakang pada hampir tiga dekade karirnya di bidang TI, dimulai sebagai pengembang Visual Basic pada 1990-an dan bergerak melalui sistem terdistribusi, jaringan, perangkat lunak perusahaan, infrastruktur, hingga akhirnya Azure.Pengamatan utamanya sederhana: industri terus memecahkan banyak masalah mendasar yang sama, tetapi arsitektur di sekitarnya menjadi jauh lebih kompleks.Sistem modern telah bergerak dari aplikasi client-server ke arsitektur terdistribusi, platform cloud, container, microservices, Kubernetes, lingkungan hibrida, dan kini pengembangan berbantuan AI.Hal itu menciptakan peluang yang sangat besar, tetapi juga menimbulkan risiko baru: rekayasa berlebihan (overengineering).Mike berpendapat bahwa banyak tim saat ini membuat masalah sederhana menjadi tidak perlu rumit. Arsitektur yang baik sering kali bukan tentang menambahkan lebih banyak teknologi, melainkan tentang mengetahui apa yang tidak perlu ditambahkan.

APA SEBENARNYA YANG DILAKUKAN ARSITEK AZURE?
Bagi Mike, arsitektur bukan tentang memilih layanan Azure dalam jumlah terbanyak atau menghasilkan diagram yang mengesankan.Arsitektur adalah tentang memahami komponen mana yang harus saling berkaitan, mana yang sebaiknya dihindari, mana yang diperlukan, dan bagaimana membangun sesuatu yang tetap mudah dipelihara, skalabel, aman, dan tangguh.Arsitektur mencakup jauh lebih banyak daripada komputasi.

• Identitas
• Jaringan
• Alur data
• Keamanan
• Pemantauan
• Integrasi
• Dependensi
• Skalabilitas
• Operasi
• Pemulihan
• Penerapan (deployment)
• Biaya

Mike juga menantang anggapan bahwa cloud-native otomatis berarti Kubernetes atau container. Azure menyediakan banyak layanan terkelola dan native yang dapat menyelesaikan masalah tanpa memperkenalkan beban operasional yang tidak perlu.Peran arsitek adalah memahami solusi secara utuh dan memilih arsitektur paling sederhana yang tetap memenuhi kebutuhan nyata.

MULAI DARI KEBUTUHAN BISNIS, BUKAN LAYANAN AZURE
Salah satu pelajaran terpenting dalam episode ini sederhana: jangan mulai dari teknologi.Sebelum memutuskan antara Azure Kubernetes Service, App Service, Azure Functions, container, Service Bus, atau platform lainnya, tim harus terlebih dahulu memahami apa yang sebenarnya harus dilakukan solusi tersebut.Pertanyaan yang perlu diajukan:

• Apakah untuk internal atau untuk pelanggan?
• Berapa banyak pengguna yang akan bergantung padanya?
• Apakah perlu diskalakan secara global?
• Berapa lama sistem boleh tidak tersedia?
• Berapa banyak data yang mampu dan tidak mampu dikehilangkan oleh bisnis?
• Persyaratan kepatuhan apa yang berlaku?
• Apa yang terjadi jika aplikasi menghilang selama beberapa jam?
• Siapa yang terdampak?
• Tingkat dukungan operasional seperti apa yang dibutuhkan?

Pertanyaan-pertanyaan ini mengarah langsung ke konsep seperti SLA, SLO, RTO, dan RPO.Pertanyaan tersebut juga menentukan apakah arsitektur sebaiknya berbasis satu region, multi-region, active-active, active-passive, atau sesuatu yang jauh lebih sederhana.

RTO DAN RPO TANPA ISTILAH BERLEBIHAN
RTO dan RPO sering dibahas sebagai akronim teknis, tetapi makna sebenarnya berorientasi pada bisnis.

• RTO — Recovery Time Objective: Seberapa cepat sistem harus kembali setelah terjadi kegagalan?
• RPO — Recovery Point Objective: Seberapa besar kehilangan data yang masih dapat diterima?

Sistem yang digunakan untuk pemantauan non-kritis mungkin dapat mentolerir beberapa jam downtime atau kehilangan data.Sementara sistem yang mendukung petugas tanggap darurat, operasi keuangan, perdagangan, atau infrastruktur kritis mungkin memerlukan pemulihan dalam hitungan menit.Poin pentingnya adalah angka-angka ini tidak boleh dikarang oleh arsitek.Angka tersebut harus berasal dari dampak bisnis yang nyata akibat kegagalan.Setelah persyaratan tersebut dipahami, barulah dapat diterjemahkan menjadi keputusan desain teknis.

KETANGGUHAN BUKAN SAMA DENGAN KETERSEDIAAN TINGGI
Mike menggunakan analogi sederhana untuk menjelaskan perbedaan antara ketersediaan dan ketangguhan (resilience).Sistem yang sangat tersedia mungkin memiliki komponen lain yang siap mengambil alih ketika komponen utama gagal.Sistem yang tangguh dirancang untuk menyerap masalah, tetap berfungsi, pulih dengan baik, dan kembali normal tanpa runtuh sepenuhnya.Perbedaan ini penting.Sebuah aplikasi secara teknis bisa tersedia tetapi tetap memberikan pengalaman yang buruk.Aplikasi tersebut mungkin:

• Lambat
• Dibatasi (throttled)
• Sebagian tidak tersedia
• Bergantung pada backend yang gagal
• Terdampak masalah integrasi
• Berada di bawah tekanan regional

Ketangguhan yang sesungguhnya oleh karena itu tidak hanya membutuhkan uptime.Diperlukan arsitektur yang mampu menghadapi beban, kesalahan aplikasi, kegagalan parsial, masalah regional, dependensi yang rusak, insiden operasional, dan pemulihan setelah insiden berlalu.

AZURE TIDAK MEMBUAT APLIKASI ANDA TANGGUH SECARA OTOMATIS
Salah satu asumsi berbahaya adalah bahwa karena Azure sendiri sangat tersedia, setiap aplikasi yang berjalan di Azure otomatis mewarisi ketangguhan tersebut.Hal itu tidak benar.Microsoft menyediakan layanan dan kemampuan yang memungkinkan arsitektur tangguh dibangun.Pelanggan tetap harus merancang ketangguhan tersebut.Di sinilah pola arsitektur menjadi penting:

• Circuit breaker
• Loose coupling
• Pemrosesan asinkron
• Penskalaan independen
• Beberapa availability zone
• Beberapa region
• Mekanisme failover
• Pemantauan
• Infrastructure as Code
• Prosedur pemulihan yang telah diuji

Microsoft menyediakan blok bangunannya. Arsitekturlah yang menentukan apakah blok-blok tersebut benar-benar menciptakan sistem yang tangguh.

MENGAPA DESAIN ASINKRON PENTING
Salah satu contoh terkuat dalam episode ini berasal dari sistem yang mengalami lonjakan trafik yang dapat diprediksi, seperti portal pajak pemerintah.Masalah desain yang umum terjadi ketika setiap tindakan bergantung pada operasi backend yang bersifat sinkron.Pengguna mengklik sebuah tombol. Frontend menunggu backend. Backend menunggu layanan lain. Dependensi lain melambat. Pada akhirnya seluruh pengalaman pengguna terdampak.Mike menjelaskan mengapa sistem yang loosely coupled sering kali lebih tangguh.Alih-alih memaksa frontend menunggu setiap operasi backend, aplikasi dapat menempatkan pekerjaan ke dalam antrean atau sistem berbasis event dan membiarkan komponen memprosesnya secara independen.Hal ini menghadirkan beberapa keuntungan:

• Komponen yang berbeda dapat diskalakan secara independen
• Satu layanan dapat gagal tanpa menjatuhkan seluruh platform
• Backend dapat memproses pekerjaan secara asinkron
• Lonjakan trafik menjadi lebih mudah diserap
• Komponen yang berhadapan dengan pengguna menjadi kurang bergantung pada waktu respons backend
• Kegagalan menjadi lebih mudah diisolasi

MITOS UPTIME 100 PERSEN
Topik utama lain dalam diskusi ini adalah obsesi terhadap ketersediaan 100 persen.Mike sangat jelas: uptime 100 persen bukanlah target arsitektur yang realistis.Sebuah solusi umumnya terdiri dari banyak layanan.Setiap layanan memiliki SLA-nya sendiri.Ketika beberapa dependensi digabungkan, ...