Condividi tramite


Azure App Service vs Web Hosting

Catatan: versi asli dari artikel ini bisa dilihat di blog penulis di https://www.irving.web.id/2017/07/05/azure-app-service-vs-web-hosting/. Artikel di MSDN Indonesia ini telah melalui penyuntingan minimal agar relevan.

Setelah membaca post saya sebelumnya mengenai cara membuat blog WordPress di Azure, ada banyak pembaca yang bertanya apa sebenarnya kelebihan Azure dibandingkan web hosting biasa yang banyak ditawarkan baik dari luar negeri maupun dari Indonesia. Saya jadi tertarik untuk mengulas sedikit mengenai hal ini.

Kalau membatasi pembahasan hanya pada blog WordPress rasanya terlalu sempit. Jadi saya akan membahas secara umum, apa kelebihan menempatkan web apps (web application, misalnya website, web-based service, e-commerce, dll) di Microsoft Azure App Service dibandingkan dengan di web hosting. Lagipula, memang sebenarnyanya menempatkan blog WordPress pribadi (dengan traffic rendah) di Azure agak overkill, sama seperti mau membunuh lalat dengan tank :-)

Secara umum, ada 4 (empat) hal yang disediakan oleh Azure App Service yang tidak disediakan oleh web hosting: auto-scale, geo-redundancy/geo-scale, deployment slot, dan continuous deployment.

Auto Scale

Bayangkan jika anda memiliki website, yang tadinya dikunjungi oleh 1000 orang per hari, tiba-tiba membludak menjadi 1 juta orang per hari. Apakah kira-kira website anda sanggup untuk menangani traffic seperti itu?

Dalam solusi konvensional, ada 2 (dua) pilihan yang bisa dilakukan: memperbesar kapasitas server (Scale Up) atau memperbanyak jumlah server (Scale Out). Dengan web hosting biasa, baik Scale Up maupun Scale Out harus dilakukan secara manual. Jadi, anda harus memonitor traffic website anda, dan ketika dibutuhkan, melakukan proses Scale Up ataupun Scale Out ini sendiri.

Kemudian apa yang terjadi jika traffic kembali turun menjadi 1000 o rang per hari? Ya anda kembali harus melakukan proses manual untuk mengubah kapasitas atau mengurangi jumlah server. Kalau tidak, nanti anda akan ditagih biaya yang cukup besar yang sebenarnya tidak anda pakai :-)

Azure memberikan solusi Auto Scale Out: jumlah instance web app anda dapat berubah secara otomatis mengikuti kondisi yang bisa anda tentukan.

image[5]

Dalam contoh di atas, kita membuat konfigurasi Auto Scale dengan minimum 1 instance dan maksimum 10 instance. Rule penambahan dan pengurangan instance ini kita buat dengan mengklik “Add a rule”.

image[11]

Dalam settingan Criteria ini, kita bisa menentukan operator dan threshold yang akan kita gunakan. Dalam contoh di atas, ketika CPU usage lebih dari 70% selama 10 menit, maka jumlah instance akan ditambah 1. Kita juga perlu membuat Criteria terpisah untuk menurunkan jumlahi instance, misalnya ketika CPU usage sudah di bawah 30%, maka jumlah instance bisa dikurangi.

Metric yang digunakan bisa beragam, bukan hanya CPU Percentage:

image[17]

Dengan Auto Scale ini, anda bisa tidur nyenyak tanpa perlu terus menerus memonitor traffic web app anda. Azure yang akan menangani semuanya :-)

Untuk lebih lengkapnya mengenai Auto Scale ini, bisa dibaca di artikel berikut: Scale instance count manually or automatically.

Geo-redundancy dan Geo-scale

Apa yang terjadi jika ada masalah dengan data center yang digunakan oleh web hosting anda? Apakah artinya web app anda akan ikut down? Kebanyakan web hosting tidak menyediakan fasilitas Disaster Recovery Center (DRC), sehingga ketika data center mereka bermasalah, maka otomatis web app anda juga ikut down.

Azure menyedia fasilitas geo-redundancy: anda mendeploy web app anda di beberapa region, dan ketika salah satu region sedang offline, maka otomatis region lain yang akan menangani. Fasilitas dari Azure ini disebut Azure Traffic Manager.

image[23]
Note: image dari https://blogs.msdn.microsoft.com/windowsazurej/2014/11/13/azure-traffic-manager/

Azure Traffic Manager secara otomatis akan mengarahkan traffic menuju ke region terdekat. Jadi, dalam kasus di atas, ketika ada traffic datang dari Asia Tenggara, maka akan diarahkan ke region AsiaSouthEast. Dengan model ini, maka web app anda juga melakukan geo-scale, karena bisa menjangkau user dari seluruh belahan dunia dan mereka akan selalu mendapatkan layanan terdekat dari lokasi mereka.

Ketika salah satu region offline, maka Azure Traffic Manager akan otomatis mengarahkan traffic ke region terdekat yang online. Dengan demikian, web app anda tidak akan pernah offline, selalu bisa menangani traffic kapan pun :-)

Untuk lebih lengkapnya mengenai Azure Traffic Manager ini, bisa dilihat di website Azure Traffic Manager.

Continuous Deployment

Untuk web app berskala besar, biasanya tim development akan menggunakan source control seperti GitHub atasu Visual Studio Team Services. Azure mendukung Continuous Deployment, yaitu melakukan app deployment langsung dari GitHub/VSTS ke Azure. Dengan demikian, tim development cukup check-in code terakhir ke GitHub/VSTS, dan otomatis app tersebut akan di-deploy ke Azure. Hal ini mengurangi proses manual yang harus dilakukan oleh tim development.

image[29]
Note: image dari https://docs.microsoft.com/en-us/azure/app-service-web/app-service-continuous-deployment

Untuk lebih lengkapnya mengenai Continuous Deployment di Azure, bisa dilihat di artikel Continuous Deployment to Azure App Service.

Deployment Slot

Melanjutkan topik Continuous Deployment di atas, tentunya tim development tidak mau langsung “menimpa” web app yang sedang berjalan, yang sedang digunakan oleh user. Bagaimana kalau ternyata masih ada bug di fitur yang baru? Bagaimana kalau ternyata konfigurasi di mesin production (di Azure) berbeda dengan di development (yang digunakan tim developer) dan masih ada yang harus dites dengan konfigurasi production tersebut?

Di dunia software development, dikenal istilah Staging Server. Staging ini adalah server yang menggunakan konfigurasi yang sama dengan production, dan digunakan untuk melakukan tes terakhir terhadap aplikasi sebelum dimasukkan ke server production.

Azure App Service mengenal istilah Deployment Slot. Dengan fasilitas Deployment Slot ini, kita bisa membuat beberapa deployment slot berbeda, yang kemudian bisa digunakan untuk memisahkan Production dan Staging. Deployment slot ini kemudian kita gabungkan dengan fasilitas Continuous Deployment, sehingga code dari GitHub/VSTS akan otomatis dideploy ke slot yang tepat.

image[38]
Note: image dari https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing

Untuk lebih lengkapnya mengenai Deployment Slot ini bisa dilihat di artikel Set up staging environments in Azure App Service.

 

Kalau ada pertanyaan mengenai hal-hal di atas, mari kita bahas di Comment ya. Atau kalau ada usulan tambahan kelebihan Azure App Service lain dibandingkan web hosting, silahkan dimasukkan juga di Comment.