Cloud Exit: Yapay Zeka Altyapı Kararını Sizin Yerinize Veriyor mu?

Cloud Exit: Yapay Zeka Altyapı Kararını Sizin Yerinize Veriyor mu? 30 Ekim 2026
Cloud Exit: Yapay Zeka Altyapı Kararını Sizin Yerinize Veriyor mu?
İçindekiler

    Yapay zekaya “bana bir CRM yaz” dediğinizde, farkında olmadan bir altyapı kararı da vermiş olursunuz. Müşteri kartları, teklif ekranı, kullanıcı girişi istersiniz. Karşınıza, bu yazıda örnek aldığım kombinasyona benzer bir yapı çıkabilir: React arayüzü, Node.js API, kullanıcı ve veri için hazır bir backend servisi, yayın için de bir uygulama yayın platformu. Bunlar bilinen servisler, ama adlarını yazıda vermiyorum; rakamlar, örnek aldığım servislerin herkese açık fiyat sayfalarından alındı.

    Proje açılır, giriş çalışır, veriler kaydolur. O noktada “altyapıyı sonra düşünürüz” demek çok doğal. Bana göre sorun tam burada başlıyor, çünkü altyapıyı siz seçmediniz ama fatura sizin adınıza kesilecek.

    Bir arkadaşım Node.js ve hazır bir backend servisiyle bir proje geliştiriyordu. Canlıya çıkmadan önce yedekleme ihtiyacı doğdu ve bana danıştı: ne yapalım? Ben de önce tüm maliyetleri karşılaştıralım, sonra karar verelim dedim. Hesabı yapınca veritabanını sunucunun içinde barındırmak bize makul geldi ve yapıyı değiştirip MySQL’e döndük. Bu yalnızca bir bağlantı ayarı değildi: kullanıcı girişi dahil veriyle ilgili her şey MySQL’e göre baştan yazıldı. Yedekleri harici bir servise aldıran bir otomasyon da hazırladık. Bunu o servis kötü olduğu için anlatmıyorum; mesele, ihtiyaç ortaya çıktığında kararın çoktan verilmiş olması. Proje henüz canlıda olmadığı için en azından taşıyacak kullanıcı verimiz yoktu. Aynı yeniden yazım gerçek kullanıcılar varken yapılsaydı çok daha zor olurdu.

    Bu yazıda yönetilen servisleri kötülemeyeceğim. Başlıktaki soruya cevap vereceğim ve aynı CRM’in iki farklı yerde çalıştırılmasının ne kadar tuttuğunu dolar bazında göstereceğim.

    Yapay zeka karar vermiyor, demo kuruyor

    Kısa cevap: bilerek vermiyor, ama siz söylemediğiniz için varsayılanı seçiyor. Yaptığı şey, bildiği, örneği bol ve kurulumu hızlı olan servisleri bir araya getirmek. Hedef kullanıcı sayınızı, ekibinizi, verinin iki yıl sonraki boyutunu ve bütçenizi prompt’a yazmadıysanız bilemez. Yani yapay zeka maliyeti kendi başına artırmıyor; maliyetin ne zaman ortaya çıkacağını görünmez kılıyor.

    Bu yüzden proje en ucuz katmanlarda çalışan bir demo olarak gelir ve ilk gün size ayda en fazla $5’a mal olur. Zıplama, ilk gerçek kullanıcıyla gelir. Örnek aldığım backend servisinin ücretsiz projeleri bir hafta hareketsiz kalınca duraklatılıyor. Yayın platformunun en ucuz uygulama planı ($5) ise 30 dakika web trafiği almazsa uykuya geçiyor. Müşteri kaydı açmak isteyen birini böyle bir sistemle karşılayamazsınız; ücretli plana geçersiniz. Aşağıdaki tabloda bunun ayda $32’ye çıkması var.

    Demo ortamı sorun değil. Sorun, demonun sessizce production’a dönüşmesi ve o noktada hiç kimsenin “bunu neden burada çalıştırıyoruz?” diye sormamış olması.

    Hazır backend servisleri neden seçiliyor?

    Yapay zeka bu tür servisleri rastgele önermiyor, geliştiriciler de onları boşuna seçmiyor. Örnek aldığım serviste her proje tam bir Postgres veritabanı. Kullanıcı girişi e-posta, telefon, sosyal hesap ve MFA seçeneklerini destekliyor; SQL editörü de aynı panelde duruyor.

    Hazır backend servisi kartı: veritabanı, kullanıcı girişi, dosya depolama ve anlık veri akışı; solda CRM uygulaması penceresi

    Bir CRM’de bunların her biri ayrı bir iş. Parola sıfırlama, oturum yönetimi, dosya yükleme ve yetkilendirmeyi sıfırdan yazmak hem zaman alır hem de her biri güvenlik açısından dikkat ister. Hazır servis bunları tek bir faturanın içinde, hazır bir temel olarak veriyor. Hazır Postgres ile hazır kullanıcı girişi bir arada geldiğinde, ben de bunu hafife almam.

    Fikri hızlı doğrulamak istiyorsanız, sunucuyla uğraşacak kimse yoksa veya giriş ile veri saklamayı kısa sürede güvenilir bir temele oturtmanız gerekiyorsa bu servisler tam olarak işinize yarar. Henüz kullanıcı bulup bulmayacağınızı bilmediğiniz aşamada bu zaman, ödediğiniz aylık ücretten daha değerli.

    Soru, bu servislerin iyi olup olmadığı değil. Ürün düzenli kullanıcı almaya başladığında, veri ve iş akışı oturduğunda ve fatura kalemleri görünür hâle geldiğinde, aynı seçimin hâlâ en uygun olup olmadığına bakmak gerekiyor.

    Aynı CRM, iki fatura

    Sunucu satan bir şirkette çalışıyorum, bu yüzden bu bölüme mesafeli bakabilirsiniz. Rakamları bu yüzden kendi fiyatlarımızdan değil, başka sağlayıcıların herkese açık fiyat sayfalarından aldım. Fiyatlar 30 Ekim 2026 itibarıyla liste fiyatıdır; vergi, kur ve kampanya hesaba katılmadı.

    Örnek proje: küçük bir ekibin kullandığı, günlük işlemi sınırlı bir CRM. Müşteri kartları, teklifler, notlar, kullanıcı girişi ve dosya eki var.

    Yönetilen servislerle (React + Node.js + hazır backend servisi + yayın platformu)

    KalemAylık
    Hazır backend servisi, ücretli plan (kullanıcı girişi, veritabanı; en küçük hesaplama paketi dahil)$25
    Yayın platformu, giriş seviyesi uygulama planı (Node.js uygulaması)$7
    Toplam$32

    Aynı yapıyı bir üst uygulama planıyla ($25) çalıştırırsanız toplam $50 olur.

    Yayın platformunun en ucuz planı ($5) ve backend servisinin ücretsiz katmanı bu hesabın dışında; neden olduğunu yukarıda anlattım.

    Tek VDS ile (Nginx + Node.js + MySQL)

    Küçük bir sanal sunucu bu yığın için yeterli. Karşılaştırma tarafsız kalsın diye kendi ürünümüzü değil, bilinen sağlayıcılardan birini seçtim. Fiyatları tabloda şeffaf ve anlaşılır göründüğü için işime geldi. Başka sağlayıcıların fiyatları farklıdır; bu tablo tek bir örnektir:

    SunucuAylık
    1 vCPU, 1 GiB RAM, 25 GiB SSD$6
    1 vCPU, 2 GiB RAM, 50 GiB SSD$12

    Node.js ile MySQL aynı makinede çalışacaksa ben 2 GiB’den başlardım. Yani gerçekçi rakam $12.

    Karşılaştırma

    SenaryoAylıkYıllık
    Backend servisi + giriş seviyesi uygulama planı$32$384
    Backend servisi + bir üst uygulama planı$50$600
    Tek VDS (2 GiB)$12$144

    Bu tabloya bakıp “demek ki VDS çok daha ucuz” demek kolay, ama yarım doğru. Küçük bir CRM için fark aylık $20 ile $40 arasında. Bir kişinin bir saatlik sunucu işi bile bu farkı eritebilir.

    Tabloda görünmeyen üç şey var:

    – Kullanıcı girişi. Hazır servisin sunduğu kimlik doğrulamayı VDS’te kendiniz kurmanız gerekir. Yapay zeka bunu yazabilir, ama güvenliğini ve bakımını yine siz üstlenirsiniz.

    – Yedekleme ve güncelleme. İşletim sistemi güncellemeleri, veritabanı yedekleri ve geri yükleme testi artık sizde. Bunların bir fiyat etiketi yok, ama zaman alıyor.

    – Büyüme eğrisi. Backend servisinde disk, trafik ve kullanıcı sayısı kotayı aşınca ek ücret işliyor. VDS’te ücret sabit, sınırı sunucunun kapasitesi belirliyor. Bunun rakamlarını bir sonraki bölümde hesapladım.

    Yani dolar farkı tek başına taşınma sebebi olmaz. Ama kullanım büyüdükçe birinin faturası kullanıma göre artar, diğerinin ise kapasiteye bağlı kalır. Bunu baştan bilmek gerekir.

    Ya uygulamanız gerçekten büyürse?

    Küçük CRM’de fark ayda $20–40’tı. Asıl soru, uygulama büyüyünce bu farkın ne olacağı. Kabaca bir hesap yapalım. Varsayımlarım şunlar: 50.000 aylık aktif kullanıcı, 40 GB veritabanı, 60 GB dosya, ayda 1 TB çıkış trafiği. Trafiğin tamamını önbelleksiz saydım; örnek aldığım serviste önbellekli trafik daha ucuz fiyatlanıyor, yani gerçek uygulamada bu kalem biraz düşebilir. Veritabanı için 4 GB RAM yeterli, Node.js uygulaması için iki uygulama örneği kullanılıyor. Bu rakamlar benim varsayımım; kendi uygulamanızda değişir.

    Backend servisi + yayın platformu

    KalemHesapAylık
    Backend servisi, ücretli plan$25
    4 GB RAM’li hesaplama paketi$60, $10 kredi düşülür$50
    Veritabanı diski40 GB, 8 GB dahil: 32 GB × $0,125$4
    Çıkış trafiği1.000 GB, 250 GB dahil: 750 GB × $0,09$67,50
    Dosya depolama60 GB, 100 GB dahil$0
    Yayın platformu, 2 × 1 GB RAM’li uygulama planı2 × $50$100
    Toplam$246,50

    Örnek aldığım backend servisinde harcama sınırı varsayılan olarak açık geliyor. Kotayı aşmak için bu sınırı kapatmanız gerekiyor; yani fatura, kapattığınız anda kullanıma bağlı hâle geliyor.

    Aynı uygulama VDS üzerinde

    SeçenekHesapAylık
    Tek VDS (4 vCPU, 8 GiB RAM, 160 GiB SSD)5.000 GiB trafik dahil$48
    Günlük yedeksunucu ücretinin %30’u$14,40
    Toplam$62,40

    Uygulama ile veritabanını ayırırsanız, aynı sağlayıcının fiyatlarıyla: uygulama için $24 (2 vCPU, 4 GiB), veritabanı için $48, günlük yedek $21,60; toplam $93,60.

    Farkın büyük kısmı iki kalemden geliyor: çıkış trafiği ($67,50) ve iki uygulama örneği ($100). Trafik 250 GB’ın altında kalsaydı backend servisi tarafı $79’a, toplam $179’a inerdi. VDS’in $62,40’ı ise yine altında kalırdı.

    Bu karşılaştırmayı birebir eşdeğer saymıyorum. Örnek aldığım backend servisi günlük yedekleri 7 gün saklıyor ve kullanıcı girişini hazır veriyor. VDS’te yedeği kendiniz yönetiyorsunuz, giriş, güvenlik ve güncellemeler de sizde. Saniyesine kadar geri dönüş isterseniz, o serviste Point in Time Recovery $100/ay’dan başlıyor.

    Yıllık fark yaklaşık $2.200. Bu noktada soru “VDS daha mı ucuz?” olmaktan çıkıyor: bu farkla sunucuyu yönetecek zamanı karşılayabiliyor musunuz?

    Tek VDS’te CRM nasıl çalışır?

    Başlangıçta her şey tek sunucuda durabilir; yük artınca yapı ikiye ayrılır:

    Başlangıçta tek VDS'te çalışan uygulama ve veritabanı, büyürken iki VDS'e ayrılmış hâli

    Uygulama, veritabanı ve arka plan işleri aynı kaynakları paylaşır. İzlenecek tek sunucu vardır. Küçük ve orta ölçekli bir CRM için bu çoğu zaman yeterli.

    Veritabanı uygulamadan farklı kaynak istemeye başladığında ikinci bir VDS’e alınabilir: birincisinde Nginx, Node.js ve worker, ikincisinde MySQL veya PostgreSQL. İki sunucu kesintisiz çalışma garantisi vermez; veritabanı sunucusu çökerse uygulama yine etkilenir. Replikasyon, yedek sistem ve düzenli geri yükleme testi ayrı bir iştir.

    Cloud exit bir taşınma günü değil

    Cloud exit denince akla bir gecede her şeyi başka yere taşımak gelir. Bence sağlıklı yaklaşım, uygulamayı baştan taşınamaz hâle getirmemek. Arkadaşımın projesinde bunu yapabildik, çünkü kararı canlıya çıkmadan verdik.

    Pratikte bu, bugünden bir envanter tutmak demek. Taşıma günü geldiğinde şunlar tek planın içinde olacak:

    Taşıma envanteri: kullanıcılar, veritabanı, dosyalar, ortam değişkenleri, e-posta ayarları, zamanlanan görevler ve domain/DNS

    Hepsini kod gibi dışarı alabiliyorsanız taşınma bir iş olur. Alamıyorsanız bir bağımlılık olur.

    Örnek aldığım backend servisinde veri tarafı görece kolay. Veritabanı standart Postgres olduğu için verinizi başka bir Postgres’e alabilirsiniz. Motoru değiştirirseniz ya da servisin kullanıcı girişinden ayrılırsanız iş değişir; arkadaşımın projesinde olduğu gibi o kısmı yeniden yazmanız gerekir. Üstelik servisi bırakmak zorunda da değilsiniz: kendi sunucunuzda Docker ile çalıştırabileceğiniz bir sürümü var. Bunun karşılığında topluluk desteğiyle yetinirsiniz; yedekleme, güvenlik ve yüksek erişilebilirlik sizde kalır. Yönetilen platformdaki otomatik yedekler ve Point in Time Recovery ise kendi sunucunuzda çalıştırdığınız sürümde yok.

    Veridyen Bulut Sunucu

    Veridyen Bulut Sunucu, uygulama ve veritabanı altyapısını kendi kontrolünde çalıştırmak isteyen ekipler için seçeneklerden biri. VMware ESXi sanallaştırma üzerinde AMD EPYC ile Intel Xeon Gold ve Platinum işlemci seçenekleri, kurumsal NVMe disklerle sunuluyor; Linux veya Windows ortamında kurulabiliyor ve ihtiyaç değiştiğinde yükseltilebiliyor.

    Paket seçmeden önce CRM’in kaç kullanıcıyla çalışacağını, veritabanının ne kadar büyüyeceğini ve sunucuyu kimin yöneteceğini netleştirin. Bu cevaplar belli olduğunda Bulut Sunucu seçeneklerine bakmak daha anlamlı olur.

    Yapay zeka ile hazırlamış olduğunuz veya geliştirdiğiniz projelerinizde, size uygun altyapı çözümlerini belirlememiz için destek almak ve maliyetlerinizi değerlendirmek isterseniz Veridyen teknik ekibiyle görüşebilirsiniz. Bize [email protected] adresinden veya +90 850 885 2222 numaralı telefondan ulaşabilir, altyapı seçeneklerine de Bulut Sunucu sayfamızdan bakabilirsiniz.

    Veridyen Destek

    Hizmetleriniz için 7/24 destek sunuyoruz.

    Veridyen Müşteri Hizmetleri