Sanallaştırma ve Hibrit Bulut: Kıbrıs ve Türkiye'deki İşletmeler İçin Gerçekçi Altyapı Seçenekleri
Yerinde sunucu, sanallaştırma, konteynerler ve bulut arasında seçim yaparken bağlantı kalitesi, veri yerleşimi, maliyet ve işletim yükü nasıl değerlendirilir? / Choosing between on-premises servers, virtualisation, containers and cloud with connectivity, data residency, cost and operational load in mind.
"Buluta mı geçelim, kendi sunucumuzu mu kuralım?" sorusu, çoğu işletme için yanlış sorudur; doğru soru "hangi iş yükü nerede çalışmalı" sorusudur. Özellikle Kıbrıs ve Türkiye'de faaliyet gösteren işletmeler için bağlantı kalitesi, veri yerleşimi beklentileri ve işletim kapasitesi bu kararı şekillendirir. Bu yazıda seçenekleri abartısız biçimde karşılaştırıyoruz.
Seçenekler kısaca
- Yerinde fiziksel sunucu: Tam kontrol, tek noktadan arıza riski, donanım ve bakım yükü sizde.
- Yerinde sanallaştırma: Bir veya birkaç fiziksel sunucu üzerinde sanal makineler (Proxmox VE, VMware vSphere, Microsoft Hyper-V gibi platformlarla). Donanımı verimli kullanır, yedekleme ve taşıma kolaylaşır.
- Konteynerler: Docker ve Docker Compose ile uygulamaların izole, taşınabilir paketler hâlinde çalışması. Sanal makinelerin içinde veya bulutta çalışabilir.
- VPS / bulut sunucu: Bir sağlayıcıdan kiralanan sanal sunucu; donanım yükü yok, işletim yükü hâlâ sizde.
- Yönetilen bulut servisleri: Veritabanı, depolama, kimlik gibi bileşenlerin sağlayıcı tarafından işletilmesi. En düşük işletim yükü, en yüksek bağımlılık.
Bağlantı kalitesi: Kıbrıs özelinde bir not
Bulut yaklaşımı güvenilir ve hızlı internet varsayar. Kuzey Kıbrıs'ta işletmelerin bir kısmı için uluslararası bağlantı gecikmesi ve kesinti riski, tamamen buluta taşınan bir ERP'nin günlük operasyonu durdurabileceği anlamına gelir. Bu durumda hibrit model öne çıkar: operasyonel sistem (puantaj, satış, iş emirleri) yerinde çalışır; yedekler, raporlama kopyası ve dışa açık web uygulamaları bulutta tutulur. Bağlantı kesildiğinde saha çalışmaya devam eder, bağlantı geldiğinde senkronizasyon tamamlanır.
Veri yerleşimi ve mevzuat
Kişisel verinin hangi ülkede işlendiği, Türkiye'de KVKK ve AB bağlantılı işlemlerde GDPR açısından hukuki sonuçlar doğurabilir. Bulut sağlayıcı seçerken veri merkezinin konumu, alt işleyiciler ve sözleşme şartları teknik değil hukuki bir karardır; kararı hukuk danışmanıyla birlikte verin. Yerinde veya ülke içindeki veri merkezinde barındırma, bu değerlendirmeyi sadeleştirebilir.
Maliyet: toplamı üç yıl üzerinden hesaplayın
Yerinde altyapıda donanım, lisans, elektrik, soğutma, yedek parça ve insan zamanı; bulutta ise aylık kullanım, veri çıkış ücretleri ve büyüdükçe artan faturalar vardır. Kıyaslamayı aynı dönem üzerinden ve kesinti maliyetini de içerecek şekilde yapın. Burada genel bir "bulut ucuzdur" ya da "yerinde ucuzdur" iddiası doğru değildir; iş yükünün karakterine bağlıdır.
Altyapı kararında en pahalı hata, "her şey tek yerde" ısrarıdır. Hibrit yaklaşım daha karmaşık görünür ama çoğu işletmenin gerçek risk profiline daha iyi uyar.
Önerdiğimiz hibrit referans mimarisi (örnek)
[Yerinde sanallaştırma: Proxmox VE veya benzeri]
├─ VM: uygulama sunucusu (Docker Compose: Nginx + uygulama + PostgreSQL)
├─ VM: yedekleme ve izleme
└─ Ayrı VLAN: IoT / IPTV / misafir ağı
[Bulut / VPS]
├─ Dışa açık web sitesi ve portal (TLS, WAF)
├─ Şifreli uzak yedek (nesne depolama, silmeye karşı korumalı)
└─ Raporlama için salt okunur veritabanı kopyası (isteğe bağlı)
[Bağlantı]
└─ Site-to-site VPN veya uygulama bazlı erişim; segmentler arası en az yetki
Sanallaştırma mı, konteyner mi?
İkisi rakip değildir. Sanal makine, işletim sistemi düzeyinde izolasyon ve kolay anlık görüntü (snapshot) sağlar; konteyner, uygulama düzeyinde taşınabilirlik ve hızlı dağıtım sağlar. Küçük ve orta ölçekte en pratik kombinasyon, birkaç sanal makine içinde Docker Compose ile yönetilen uygulamalardır. Kubernetes gibi orkestrasyon sistemleri, ancak gerçekten çok sayıda servis ve ekip varsa anlamlıdır; aksi hâlde işletim yükü faydasını aşar.
İşletim yükü: dürüst olun
Yerinde altyapının görünmeyen maliyeti, onu izleyecek ve güncelleyecek kişidir. Yama yönetimi, yedek doğrulama, sertifika yenileme ve kapasite takibi için sorumlu yoksa, yerinde altyapı zamanla riskli hâle gelir. Bu durumda ya yönetilen hizmet alınmalı ya da işletim bir uzman ekibe devredilmelidir.
Karar için kısa kontrol listesi
- Bağlantı kesildiğinde hangi süreçler durursa işletme zarar görür? Onlar yerinde kalsın.
- Hangi veriler mevzuat gereği belirli konumda olmalı?
- Üç yıllık toplam maliyet, kesinti maliyeti dahil ne?
- Altyapıyı kim izleyecek?
- Yedek nerede, kim geri yükleyebilir?
Yerinde sanallaştırma: pratik başlangıç
Küçük ve orta ölçekli bir işletme için iki fiziksel sunucu üzerinde sanallaştırma, hem yedeklilik hem de esneklik sağlar: bir sunucu arızalandığında sanal makineler diğerinde başlatılabilir. Proxmox VE gibi açık kaynak platformlar lisans maliyeti olmadan sanal makine, konteyner ve yedekleme yönetimi sunar; ticari platformlar daha geniş ekosistem ve destek sağlar. Seçim, mevcut ekibin bilgisine ve destek beklentisine göre yapılmalıdır. Depolama tarafında, sanal makine disklerinin düzenli anlık görüntüsü (snapshot) ile uygulama düzeyinde yedek (PostgreSQL yedeği) birbirini tamamlar.
Elektrik ve fiziksel koşullar
Yerinde altyapının en çok ihmal edilen yanı fiziksel ortamdır: kesintisiz güç kaynağı (UPS) ve düzgün kapanma entegrasyonu, soğutma, toz ve fiziksel erişim kontrolü. Kıbrıs'ta yaz sıcaklıkları ve elektrik dalgalanmaları, sunucu odası planlamasını bulut kararında olduğundan daha kritik hâle getirir. Bir UPS'in pil ömrü ve kapasitesi düzenli test edilmelidir; test edilmeyen UPS, ilk kesintide sürpriz yapar.
Bulut sağlayıcı seçerken sorulacaklar
- Veri merkezi hangi ülkede; alt işleyiciler kimler?
- Veri çıkış (egress) ücreti nedir; büyük yedekleri geri indirmek ne kadar tutar?
- Taşınabilirlik: sağlayıcıdan ayrılmak istersek veriyi ve sanal makineleri hangi formatta alabiliriz?
- Erişilebilirlik taahhüdü ve bakım pencereleri nasıl bildiriliyor?
- Kimlik ve erişim yönetimi MFA ve rol ayrımı destekliyor mu?
Hibrit modelde senkronizasyon
Yerinde çalışan operasyonel sistem ile buluttaki bileşenler arasında veri akışı tasarlanmalıdır. Raporlama kopyası için PostgreSQL mantıksal replikasyonu veya zamanlanmış dışa aktarım kullanılabilir; dışa açık portal için ise yerinde sistemle API üzerinden kuyruk tabanlı iletişim tercih edilir. Bağlantı koptuğunda her iki taraf da çalışmaya devam etmeli, bağlantı geldiğinde kuyruk boşalmalıdır. Bu tasarım, "çevrimdışı kuyruk" ilkesinin altyapı düzeyindeki karşılığıdır.
Örnek senaryo (kurgusal)
Bir üretim işletmesi, atölyede iş emri ve stok sistemini yerinde sanal makinede çalıştırır; satış ekibinin kullandığı B2B portal bulutta barındırılır. Portaldan gelen siparişler kuyruğa yazılır ve yerinde sistem bağlantı olduğunda çeker; stok bilgisi ise saatlik olarak buluttaki salt okunur kopyaya aktarılır. Yedekler gece şifreli olarak buluta gider. İnternet kesildiğinde atölye çalışmaya devam eder; portal siparişleri kuyrukta bekler ve müşteri "siparişiniz alındı" mesajını alır. Bu senaryo, iki dünyanın en iyi yanlarını birleştirir ve işletmenin gerçek risk profiline uyar.
Geçiş: büyük patlama yerine kademeli
Mevcut fiziksel sunuculardan sanallaştırmaya veya hibrit modele geçiş, hafta sonu "her şeyi taşıma" ile değil, sistem sistem yapılmalıdır: önce en az kritik uygulama, sonra test, sonra bir sonraki. Her taşımanın geri dönüş planı olmalı; eski sunucu, yeni sistem bir süre sorunsuz çalışana kadar kapatılmamalıdır.
Cy Logic'in sunucu ve bulut altyapısı hizmeti; Linux, Docker, Nginx, PostgreSQL ve self-hosted Supabase ile yerinde, bulutta veya hibrit kurulumları tasarlar ve işletir.