Bulut tabanlı casino sistemleri, altyapının konumundan önce sorumluluk, kesinti ve veri erişimi açısından değerlendirilmelidir. “Buluta geçelim, sunucu derdi bitsin” yaklaşımı eksik bir başlangıçtır.
Bitmez.
Sadece sorumluluk değişir.
“Her şeyi yerelde tutalım, daha güvenli olsun.”
O da garanti değildir.
Bakımı yapılmayan yerel sistem, güçlü yönetilen buluttan daha riskli olabilir. Bağlantıya tamamen bağımlı bulut sistemi ise ağ kesildiğinde casino floor’unu durdurabilir.
Doğru karar ideolojiyle değil; gecikme, kesinti toleransı, veri konumu, entegrasyon, ekip yeteneği, ölçek ve toplam maliyetle verilir. İşlevlerin gereksinimleri farklıysa sonuç, açık sınırları olan hibrit mimari olabilir; bunun her casino için doğru tercih olduğu varsayılmamalıdır.
Bu makale genel değerlendirme çerçevesidir. Dağıtım modeli; lisans, veri koruma, teknik sertifikasyon, finansal kayıt ve hizmet sağlayıcı sözleşmeleriyle doğrulanmalıdır.
Bulut tabanlı casino sistemleri: modelleri tanımlayın
- On-premises: Uygulama ve altyapı tesis/kurum ortamında
- Private cloud: Tek kurumun kullanımına ayrılmış bulut altyapısı; kurum içinde veya dışarıda bulunabilir
- Public cloud: Genel kullanıma sunulan sağlayıcı bulut altyapısı; müşteri hesapları ve erişimleri mantıksal olarak ayrılır
- SaaS: Uygulamanın vendor tarafından hizmet olarak sunulması
- Hybrid: Kritik yerel işlev ile merkezi/bulut hizmetlerinin birleşimi
NIST’in bulut tanımı, hizmet modelleri ile dağıtım modellerini ayırır. Bir sanallaştırılmış sunucu tek başına private cloud sayılmaz. SaaS bir hizmet modelidir; on-premises ise yerleşimi anlatır. Bu nedenle listedeki kavramlar tamamen birbirini dışlayan seçenekler değildir. “Bulut” tek model değildir. SaaS’ta uygulama kontrolü, kendi bulut hesabınızdaki sistemden farklıdır.
Gecikme ve bağlantı
Yerel, düşük gecikmeli cihaz kontrolünde avantajlı olabilir. Bulut, merkezi analiz ve çoklu tesis görünümünde güçlü olabilir.
Her işlev için:
- Normal gecikme
- Azami kabul edilebilir gecikme
- Bağlantı kesilince davranış
- Yerel cache/buffer
- Geri bağlantıda uzlaştırma
- İkinci hat ve farklı taşıyıcı
test edilmelidir.
Bağlantı Kullanılabilirliği ≠ Uygulama Kullanılabilirliği
Hat açıkken kimlik servisi veya bulut bölgesi kesilebilir; uygulama kapalı olabilir.
Paylaşılan sorumluluk
Bulut sağlayıcı fiziksel altyapıyı korusa bile müşteri genellikle şunlardan sorumludur:
- Kullanıcı ve yetki
- Uygulama yapılandırması
- Veri sınıflandırması
- Anahtar/secret yönetimi
- Ağ kuralları
- Log ve alarm
- Yedekleme politikası
- Entegrasyon güvenliği
Yönetim hatası: “Vendor güvenli” ifadesini kendi yapılandırma ve erişim sorumluluğunun devri sanmak.
Veri konumu ve erişim
Sorulacaklar:
- Veri hangi ülke/bölgede tutuluyor?
- Yedek ve loglar nerede?
- Alt işleyenler kim?
- Destek ekibi hangi ülkeden erişebilir?
- Şifreleme anahtarı kimin kontrolünde?
- Silme ve saklama nasıl kanıtlanır?
- Hizmetten çıkışta veri nasıl alınır?
Verinin fiziksel konumu kadar mantıksal erişim ve destek zinciri de önemlidir.
Dayanıklılık
Yerel riskler
- Tek tesis yangın/enerji/soğutma
- Donanım tedarik süresi
- Sınırlı uzman ekip
- Yama ve kapasite gecikmesi
Bulut riskleri
- İnternet/telekom bağımlılığı
- Yanlış yapılandırmanın hızlı yayılması
- Sağlayıcı bölge veya kimlik servisi kesintisi
- Vendor lock-in
- Beklenmeyen tüketim maliyeti
Her iki modelde de bağımsız yedek, geri yükleme testi ve iş sürekliliği gerekir.
Toplam maliyet
TCO = Altyapı/Hizmet + Lisans + Ağ + İşletim + Güvenlik + Yedek/DR + Entegrasyon + İnsan + Kesinti + Çıkış
Bulutta yalnız aylık compute faturası, yerelde yalnız sunucu satın alma bedeli karşılaştırılamaz.
| Maliyet | Yerel | Bulut/SaaS |
|---|---|---|
| İlk yatırım | Genelde yüksek | Genelde daha düşük |
| Ölçekleme | Donanım süresine bağlı | Daha hızlı olabilir |
| Egress/veri çıkışı | Sınırlı | Önemli olabilir |
| İç işletim | Yüksek | Modeline göre azalır |
| Bağlantı | Kritik ama yerel iş sürebilir | Çok kritik olabilir |
| Çıkış/migrasyon | Teknik borca bağlı | Vendor ve veri formatına bağlı |
İşlev bazında yerleşim
Casino sistemleri entegrasyonu hangi verinin nerede kesinleştiğini göstermelidir. Cashless işlemlerde internet kesilse bile doğrulanmamış bakiyeyle işlem üretmemek temel tasarım sorusudur.
Örnek hibrit yaklaşım:
- Oyun cihazı kontrolü ve kesinti kritik işlem: yerel/edge
- Merkezi oyuncu görünümü: uygun merkezi platform
- BI, arşiv ve ağır analitik: bulut
- Kimlik ve politika: dayanıklı hibrit
- Finansal kapanış: kontrollü merkezi entegrasyon
- Yedekleme: ayrı hata alanı
Bu bir evrensel şablon değildir. Bağımlılık analiziyle doğrulanmalıdır.
Karar matrisi
| Boyut | Bulut lehine | Yerel lehine |
|---|---|---|
| Çoklu tesis ölçeği | Merkezi büyüme | Tek tesis/sabit yük |
| Floor gecikmesi | Edge ile mümkün | Doğrudan düşük gecikme |
| İnternet dayanıklılığı | Çift hat + offline tasarım | Zayıf bağlantıda daha güçlü |
| İç ekip | Sınırlı altyapı ekibi | Güçlü uzman işletim |
| Veri/sertifikasyon | Uygun bölge ve kontrol | Yerel zorunluluk |
| Özelleştirme | Standart süreç | Derin özel entegrasyon |
Çıkış planı
Sözleşmeden önce:
- Tam veri export formatı
- Konfigürasyon ve log erişimi
- Export süresi ve ücreti
- Geçiş desteği
- Paralel çalışma
- Veri silme kanıtı
- Donanım/anahtar sahipliği
belirlenmelidir.
Sözleşme SLA’sı ile işletmenin hedefi farklıdır
Sağlayıcının yüzde 99,9 kullanılabilirlik taahhüdü, tüm casino hizmetinin aynı seviyede çalışacağını garanti etmez. DNS, kimlik, yerel ağ, internet hattı ve entegrasyon bağımlılıkları aynı zincirdedir. Örneğin 30 günlük bir ayda yüzde 0,1 yaklaşık 43,2 dakikadır; sözleşmenin bakım istisnaları ve ölçüm noktası bu hesaptan farklı olabilir.
TCO karşılaştırması aynı üç veya beş yıllık dönem, kur varsayımı ve kapasite senaryosuyla yapılmalıdır. Veri çıkış ücreti, geçiş testi, çift işletim ve sözleşme sona erdiğinde destek maliyeti casino bütçesine eklenir. Güçlü veri export’u kadar geri yüklenebilirliği kanıtlanmış format da önemlidir.
Sonuç: yer değil, sorumluluk mimarisi
Bulut ve yerel sistem karşılaştırması “hangisi daha modern?” sorusu değildir.
Doğru model, kritik işlemi bağlantı ve sağlayıcı hatasına karşı sürdüren; verinin yerini ve sahibini açıklayan; gerçek TCO’yu ölçen ve gerektiğinde çıkış yolunu açık bırakan modeldir.