Bulutta bir kaynağı kullanmanın iki temel fiyat yolu vardır. Reserved, yani önceden taahhüt edilen kapasite modeli, belirli bir süre için belirli bir kapasiteyi sağlayıcıya bağlar. On-demand, yani kullandıkça ödeme modeli, kullandığınız süre kadar ödemenize izin verir. Karar tek başına birim fiyata bakılarak verilmez. İş yükünün ne kadar öngörülebilir olduğu, fiyatın kendisinden daha belirleyicidir.
Hızlı Özet
Reserved modeli sabit ve uzun süreli iş yüklerinde, on-demand modeli ise değişken, deneysel ve kısa ömürlü yüklerde daha uygun olma eğilimindedir. Taahhüt kararı iş yükünün kullanım geçmişine dayanmalıdır. Önce on-demand ile ölçüm yapılır, taahhüt yalnızca öngörülebilir kısma verilir. Sözleşmedeki değiştirme, iptal ve kapsam kuralları sağlayıcının resmi dokümantasyonuyla doğrulanır. Leon-X bulut altyapısının sahibi değildir. Bu kararı kullanım verileri ve sözleşme koşullarıyla birlikte hazırlar.
İçindekiler
- Model Farkı Nedir
- Taahhüt Ne Zaman Mantıklı
- Kullanım Verisi Nasıl Hazırlanır
- Kapsam ve Esneklik
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Wikimedia Commons, Racks Amravati Data Center. Fotoğraf PiDatacenters tarafından çekilmiş olup CC BY-SA 4.0 lisansıyla yayımlanmıştır. Görsel WebP biçimine çevrilip boyutlandırıldı.
Model Farkı Nedir
On-demand modelde kaynak çalıştığı sürece ücretlendirilir. Kaynağı kapattığınızda çalışma ücreti de durur. Bu esneklik deneme, geliştirme ve ani yük artışları için uygundur. Bedeli, birim fiyatın taahhütlü seçeneğe göre daha yüksek olabilmesidir. Bu modelin genel çerçevesi için FinOps nedir yazısına bakabilirsiniz.
Reserved modelde ise belirli bir süre ve kapasite için taahhüt verirsiniz. Kullanmasanız bile taahhüt edilen kapasitenin bedeli fatura döneminde yansır. Karşılığında daha düşük birim fiyat sunulabilir. Yani reserved modelinde kazanç, kullanımın öngörülebilir olmasından gelir.
Basit bir ayrım yapılabilir. Kullanım sabitse taahhüt, kullanım değişkense on-demand daha uygun olma eğilimindedir. Bu ayrım yapılmadan yapılan fiyat karşılaştırması yanıltıcı olabilir.
Taahhüt Ne Zaman Mantıklı
Taahhüt kararı için üç koşulun birlikte sağlanması beklenir. İlki, iş yükünün sürekli çalışmasıdır. Her gün devreye giren bir muhasebe uygulaması ya da arşiv sistemi bu koşula yakındır. İkincisi, kapasite ihtiyacının geçmiş verilerle uyumlu olmasıdır. Son üç aydaki kullanımı belirgin biçimde dalgalanan bir sistem henüz taahhüde hazır değildir. Üçüncüsü, mimarinin kısa vadede değişmeyecek olmasıdır. Sistem yakında başka bir yapıya taşınacaksa ya da kapatılacaksa taahhüdün bedeli karara yansır.
Bu koşullardan biri eksikse taahhüt fiyat avantajı yerine risk üretir.
Kullanım Verisi Nasıl Hazırlanır
Karar için en az bir fatura dönemini kapsayan kullanım verisi gerekir. Daha güvenilir bir karar için daha uzun bir dönem okunur. Veriler kaynak bazında toplanır ve üç soruya cevap verir. Kaynak hangi saatlerde çalışıyor? Yük hangi dönemlerde zirve yapıyor? Boşta kalan süre ne kadar?
Veriler tek bir ayın ortalamasıyla değil, en düşük ve en yüksek dönemleriyle birlikte okunmalıdır. Ortalama makul görünse bile ay sonu ya da kampanya dönemi kapasite ihtiyacını belirgin biçimde artırabilir. Taahhüt genellikle sürekli kalan en düşük yük seviyesine göre planlanır, zirve kullanım ise on-demand ile karşılanır.
Kaynakların hangi uygulamaya ait olduğu etiketlerle bağlanmadıysa bu veri bir karara dönüşmez. Konu için etiketleme stratejisi yazısına bakabilirsiniz.
Kapsam ve Esneklik
Taahhüdün kapsamı sağlayıcıya ve hizmete göre değişir. Bazı taahhütler belirli bir kaynak tipine bağlanır, bazıları daha geniş bir kullanım havuzuna. Kapsam dar seçilirse mimari değiştiğinde taahhüt boşa çıkabilir. Kapsam geniş seçilirse esneklik artar, ancak hangi kullanımın kapsama girdiğini ayrıca izlemek gerekir.
Azure tarafındaki taahhüt seçenekleri için Azure ve Microsoft 365 maliyet rehberine bakılabilir. Ancak o yazıdaki genel çerçeve, güncel sözleşmenin yerine geçmez.
Sözleşme tarafında üç nokta kontrol edilir. Taahhüt değiştirilebilir mi, iptal edilebilir mi ve ödeme hangi takvime göre yapılır? Bu kuralların ayrıntısı sağlayıcının resmi dokümantasyonu ve sözleşmesiyle doğrulanır.
Yaygın Hatalar
Tek bir raporla karar vermek ilk hatadır. Bir ay düşük kullanım gösteren sistem sonraki ay zirve yapabilir.
Değişim ihtimalini hesaba katmadan taahhüt vermek ikinci hatadır. Uygulama yeni bir sürüme geçtiğinde eski kapasite yeni yapıya uymayabilir.
Taahhüdü yalnızca bir maliyet kalemi saymak üçüncü hatadır. Taahhüt aynı zamanda kapasite planı ve sahiplik kararıdır. Kimin takip ettiği belli değilse faturada sürpriz çıkma ihtimali artar.
Son olarak, on-demand modelini her zaman pahalı saymak yanlıştır. Kısa süreli ve değişken iş yüklerinde on-demand, boşta kalan bir taahhütten daha düşük maliyetli olabilir. Değişken veri çıkış kalemleri de ayrıca izlenmelidir. Bu kalem için egress yazısına bakılabilir.
Kontrol Listesi
- İş yükü en az bir fatura dönemi boyunca ölçüldü mü
- Taahhüt adayları sürekli çalışan sistemlerle sınırlandı mı
- Zirve dönemler taahhüt dışında, on-demand tarafında bırakıldı mı
- Mimari değişiklik planı taahhüt süresiyle çakışıyor mu
- Değiştirme, iptal ve kapsam kuralları resmi dokümantasyonla doğrulandı mı
- Her taahhüdün bir sahibi ve gözden geçirme tarihi var mı
Leon-X ile Sonraki Adım
Leon-X mevcut kullanım verilerinizi ve sözleşme koşullarınızı birlikte inceler. Hangi kaynakların taahhüde uygun olduğunu, hangilerinin on-demand kalması gerektiğini ve kararın hangi tarihte yeniden gözden geçirileceğini listeler. Sağlayıcıya ait fiyat ve kapsam bilgileri resmi kaynaktan doğrulanır. Ayrıntılar bulut maliyet yönetimi ve FinOps danışmanlığı sayfasında yer alır. Keşif için iletişime geçin.
Sık Sorulan Sorular
Reserved ile on-demand aynı anda kullanılabilir mi?
Evet. Taban kapasite taahhütle, zirve kullanım on-demand ile karşılanabilir. Belirsizliğin yüksek olduğu ortamlarda bu düzen daha güvenli bir başlangıç olabilir.
Taahhüt edilen fiyat sabit kalır mı?
Fiyat koşulları sözleşmede yazılı çerçeveden okunur. Hangi kalemlerin kapsama girdiği ve koşulların zaman içinde nasıl işlediği sağlayıcının dokümantasyonunda kontrol edilmelidir.
Taahhüt kararı ne sıklıkla gözden geçirilmeli?
Her taahhüt için bir gözden geçirme tarihi belirlenir. Sıklık, iş yükünün değişme hızına göre ayarlanır ve mimari değişiklik planlarından önce yapılır.
Sonuç
Reserved ve on-demand seçimi tek bir fiyat karşılaştırmasıyla yapılmaz. Kullanım sabitliği, değişim planı ve sözleşme esnekliği birlikte değerlendirilir. Öngörülebilir kısım taahhüde verildiğinde maliyet avantajı elde edilebilir. Değişken kısım on-demand'de kaldığında esneklik korunur. Kararı dönemsel olarak yeniden gözden geçirmek, faturayı ve ekibin kapasite beklentisini aynı sayfaya getirir. Kapsam için Leon-X ile iletişime geçebilirsiniz.
Kaynaklar
- FinOps Foundation, FinOps Framework (finops.org)
- Bulut sağlayıcıların resmi taahhüt ve fiyatlandırma dokümantasyonu
