Bir yıl önce, orta ölçekli bir üretim firmasının kritik ERP verilerini ve tüm uygulamasını buluttan kendi bare-metal sunucularımıza taşıdığımızda, ekibin yüzündeki o “acaba hata mı yapıyoruz” ifadesini hala net bir şekilde hatırlıyorum. Yıllarca bulutun esnekliğini, kolaylığını ve “sonsuz scalability” vaadini dinledikten sonra, bu kararın bana pişmanlık getirip getirmeyeceği o zamanlar büyük bir soru işaretiydi. Peki, bu iddialı geri dönüşten sonra bugün pişman mıyım? Kesinlikle hayır.
Bu kararı alırken temel motivasyonumuz maliyet kontrolü ve operasyonel bağımsızlık kazanmaktı. Bulutun faturaları tahmin edilemez bir şekilde şişmeye başladığında, sadece kaynak kullanımlarının değil, aynı zamanda network egress maliyetlerinin de ciddi bir yük oluşturduğunu gördüm.
Neden Buluttan On-Premise’e Geçme Kararı Aldık?
Bulutun ilk başta cazip gelen esnekliği ve hızlı deployment yeteneği, zamanla tahmin edilemez maliyetler ve vendor lock-in riskleriyle gölgelendi. Bir üretim ERP’sinde, özellikle AI ile üretim planlama ve operatör ekranları gibi gerçek zamanlı iş yüklerinde, network latency ve veritabanı I/O performansı kritik öneme sahipti. Bulutta bu tür iş yüklerinin maliyetini optimize etmek zorlaşmaya başlamıştı.
PostgreSQL instance’ları, Redis cache’ler ve FastAPI backend’leri için ödediğimiz faturalar, beklenenden çok daha hızlı bir şekilde artıyordu. Özellikle network egress ücretleri, veri aktarım hacmi arttıkça adeta bir kara delik gibi bütçemizi yutmaya başlamıştı. Ayrıca, yerel ağımızdaki diğer sistemlerle entegrasyon için VPN tünelleri üzerinden sürekli veri akışı, performans düşüşlerine yol açıyordu.
Bu durum, beni ve ekibimi “Gerçekten bu kadar esnekliğe ihtiyacımız var mı?” ve “Kendi altyapımızı kurarak ne kadar tasarruf edebiliriz?” sorularını sormaya itti. Yaptığımız detaylı maliyet analizi, orta vadede on-premise bir çözümün çok daha ekonomik olacağını açıkça gösterdi. Ayrıca, güvenlik politikalarımızı ve veri saklama standartlarımızı kendi kontrolümüzde tutma arzusu da bu kararı güçlendiren önemli bir faktördü.
Taşıma Süreci: Beklentiler ve Gerçekler
Verileri buluttan kendi sunucularımıza taşımak, düşündüğümden çok daha karmaşık bir süreçti. Özellikle 5TB’lık PostgreSQL veritabanının fiziksel replikasyonla aktarımı, network bant genişliğini sonuna kadar zorladı ve bu süreç beklediğimizden daha uzun sürdü. Downtime’ı minimumda tutmak için günler öncesinden detaylı bir planlama yapmış olsam da, canlıya geçiş anında DNS propagation süreleri ve çeşitli network segmentasyonu sorunları yüzünden yaklaşık 30 dakikalık ek bir kesinti yaşadık.
Yeni altyapıyı kurarken, mevcut bulut ortamındaki konfigürasyonları bare-metal sunuculara uyarlamak başlı başına bir mücadeleydi. PostgreSQL için WAL bloat sorunlarını önlemek adına checkpoint_timeout ve max_wal_size gibi parametreleri ince ayarlamamız gerekti. Redis için maxmemory-policy seçimleri, OOM evictions’ı en aza indirmek için kritikti ve volatile-lru ile allkeys-lfu arasında uzun süren performans testleri yaptık.
Kendi yan ürünümün backend’ini taşırken de benzer deneyimler yaşadım. Bir keresinde, yeni bir systemd unit’i tanımlarken memory.high yerine memory.max limitini yanlış ayarladığım için uygulamanın beklenmedik OOM-killed olmasına sebep oldum. Bu tür küçük, ama kritik hatalar, bulutun yönetilen servislerinin sağladığı “konfor alanından” çıktığımızda ne kadar çok detaya hakim olmamız gerektiğini bir kez daha gösterdi. Her ne kadar bu durumlar ilk başta sinir bozucu olsa da, her bir sorun, benim için yeni bir öğrenme fırsatı oldu.
On-Premise Hayatının Artıları ve Eksileri (Kendi Gözümden)
On-premise’e geçişin ardından elde ettiğimiz en büyük avantaj, maliyet kontrolü ve performans üzerindeki tam hakimiyet oldu. Artık aylık faturaların ne kadar geleceğini tahmin etmek çok daha kolaydı ve gereksiz kaynak harcamalarının önüne geçebiliyorduk. Kendi sunucularımızda PostgreSQL’i doğrudan diske yazma hızları, buluttaki IOPS limitlerine takılmadan çok daha yüksek performans sağlıyordu.
Örneğin, bir üretim firmasının ERP’sinde günlük 100 binin üzerinde işlem kaydını işleyen bir batch job, bulutta ortalama 45 dakika sürerken, on-premise altyapımızda bu süre 18 dakikaya kadar düştü. Bu, operasyonel verimlilik açısından muazzam bir kazançtı. Network segmentasyonunu VLAN’lar ve firewall kuralları ile tamamen kendi kontrolümüzde tutmak, güvenlik duruşumuzu da güçlendirdi. DHCP snooping ve Dynamic ARP Inspection (DAI) gibi switch hardening tekniklerini uygulayarak, içeriden gelebilecek tehditlere karşı daha dirençli bir yapı kurdum.
Ancak, on-premise’in bazı dezavantajları da göz ardı edilemez. Özellikle ilk yatırım maliyeti ve operasyonel yük, başlangıçta büyük bir bariyer oluşturabilir. Sunucu arızaları, network problemleri veya güç kesintileri gibi durumlarda tüm sorumluluk bize ait. Felaket kurtarma (disaster recovery) planlarını çok daha detaylı ve manuel olarak tasarlamak zorunda kaldık. Örneğin, bir yedekleme sunucusunun RAID kartı arızalandığında, buluttaki otomatik replikasyon konforunu mumla aradım.
Yine de, bu ek operasyonel yükün karşılığında elde ettiğim derinlemesine bilgi ve kontrol seviyesi, bu değişime değdi. Artık bir sorun çıktığında, sorunun kök nedenini bulmak için üçüncü parti bir sağlayıcının API’lerini veya destek ekibini beklemek zorunda kalmıyorum. SystemD unit’lerini, journald loglarını ve cgroup limitlerini doğrudan inceleyebiliyor, problem çözme sürecini hızlandırabiliyorum.
Peki, Pişman mıyım? Son Kararım.
Verilerimi buluttan kendi sunucularıma çekme kararımdan kesinlikle pişman değilim. Aksine, bu süreç bana hem teknik bilgi hem de operasyonel esneklik açısından çok şey kattı. Elbette, bu herkes için doğru bir yol değil. Küçük ölçekli projeler veya hızla değişen iş yükleri için bulut hala ideal bir çözüm olabilir. Ancak, belirli bir büyüklüğe ulaşmış, maliyetleri ve veri güvenliğini daha sıkı kontrol etmek isteyen ve operasyonel yükü kaldırabilecek ekipler için on-premise veya hibrit bir yaklaşım ciddi avantajlar sunuyor.
Benim deneyimimde, özellikle bir üretim ERP’si gibi uzun ömürlü ve kritik sistemler için, kendi altyapımıza yatırım yapmak, uzun vadede çok daha akıllıca bir strateji oldu. Maliyetler daha öngörülebilir hale geldi, performans beklentilerimizin üzerine çıktı ve güvenlik duruşumuzu önemli ölçüde güçlendirdik. Bu kararın ardında yatan riskleri ve zorlukları bilerek hareket ettik, ve sonuçlar bu çabaya değdiğini gösterdi.