Startup İçin Hosting Nasıl Seçilir? Bütçe ve Ölçeklenme Rehberi

Startup için hosting nedir ve neden ayrı bir karar gerektirir?

Startup için hosting, bir girişimin web sitesini ve ürününü çalıştıran altyapıyı şirketin o anki aşamasına, bütçesine ve büyüme hızına göre seçme ve zamanla değiştirme kararıdır. Tek seferlik bir satın alma değildir; prototipten büyümeye kadar birkaç kez gözden geçirdiğiniz, maliyet ve risk dengesini koruyan bir yol haritasıdır.

Biz Talha Aslan ve ekibi olarak dijital pazarlama ve web tarafında çalışıyoruz; hosting firması değiliz. Bu yüzden bu rehberde belirli bir sağlayıcıyı övmüyor ya da yermiyoruz. Bunun yerine bulut bilişimin standart tanımlarına, uygulama mimarisindeki yaygın kabul gören ilkelere ve mevzuatın resmi metnine dayanarak bir karar çerçevesi sunuyoruz.

Genel hosting seçim kriterlerini ayrı yazımızda anlattık: web sitesi için hosting nasıl seçilir. Burada o kriterleri tekrar etmiyoruz. Odak noktamız, belirsizlik içinde hızlı büyümeye çalışan bir girişimin altyapı kararlarını hangi sırayla vermesi gerektiği.

Startup için hosting kararında aşamalar neden bu kadar önemli?

Bir girişimin ihtiyacı birkaç ay içinde kökten değişebilir. Bugün on deneme kullanıcınız varken üç ay sonra ödeme yapan yüzlerce müşteriniz olabilir. Bu nedenle ilk günden en büyük altyapıyı kurmak parayı ve zamanı boşa harcar; en küçüğünde ısrar etmek ise büyüme anında kesintiye yol açar.

Biz bu kararı üç aşamada düşünmeyi öneriyoruz:

• Prototip: Fikri doğruluyorsunuz; hız ve düşük maliyet her şeyden önemli.
• İlk kullanıcılar: Gerçek veri ve gerçek müşteri var; güvenilirlik ve yedek öne çıkar.
• Büyüme: Trafik ve ekip büyür; ölçeklenme, izleme ve otomasyon belirleyici olur.

Her aşamanın sorusu farklıdır. Prototipte "ne kadar hızlı yayına alırım?" diye sorarsınız. İlk kullanıcılarda "veri kaybolursa ne olur?" sorusu öne geçer. Büyümede ise "yük iki katına çıkarsa sistem dayanır mı ve fatura nereye gider?" sorusunu cevaplamanız gerekir. Kısacası startup için hosting kararı tek bir doğru cevaptan çok, doğru zamanda doğru geçişi yapmakla ilgilidir.

Prototip aşamasında hangi hosting yeterli olur?

Prototip aşamasında amaç, fikri en az maliyetle gerçek kullanıcıların önüne koymaktır. Bu dönemde birçok bulut ve platform sağlayıcısının sunduğu ücretsiz ya da düşük maliyetli katmanlar, statik site barındırma hizmetleri veya iyi bir paylaşımlı hosting paketi çoğu zaman yeterlidir.

Örneğin tanıtım sayfası ve bekleme listesi formundan oluşan bir ürün için güçlü bir sunucuya ihtiyacınız yoktur. Öte yandan basit bir veritabanı kullanan bir web uygulaması da küçük bir paket üzerinde rahatça çalışabilir. Önemli olan, bu aşamada altyapıya değil ürüne zaman ayırmanızdır.

Yine de birkaç alışkanlığı ilk günden edinmenizi öneriyoruz. Kodu bir sürüm kontrol sisteminde tutun. Yapılandırma bilgilerini koda gömmeyin, ortam değişkenlerinde saklayın. Alan adınızı kendi hesabınıza kaydedin ve DNS yönetimini kontrolünüzde tutun. Bu üç alışkanlık, ileride sağlayıcı değiştirdiğinizde işinizi ciddi biçimde kolaylaştırır.

Ücretsiz katmanların bir sınırı da vardır: kaynak kotaları, uyku moduna geçen uygulamalar ya da destek eksikliği gibi kısıtlar çıkabilir. Bu yüzden prototipi "kalıcı ev" olarak değil, geçici bir deneme alanı olarak görün.

Sunucu konumunu da baştan düşünün. Kullanıcılarınızın çoğu Türkiye'deyse onlara yakın bir bölge gecikmeyi azaltır. Ayrıca KVKK açısından verinin hangi ülkede durduğu önem taşır. Bu iki konu, ileride taşınma maliyetini doğrudan etkileyen kararlar arasında yer alır.

İlk kullanıcılar geldiğinde VPS mi yönetilen platform mu seçmelisiniz?

İlk ödeme yapan müşteriler geldiğinde öncelik değişir. Artık kesinti, veri kaybı ve güvenlik açığı doğrudan gelir ve itibar kaybı demektir. Bu aşamada iki yaygın yol vardır: kendi yönettiğiniz bir VPS ya da altyapıyı sizin yerinize işleten yönetilen bir uygulama platformu (PaaS).

VPS size tam kontrol verir ve maliyeti öngörülebilir kılar. Ancak işletim sistemi güncellemeleri, güvenlik duvarı, sertifika yenileme ve yedekleme sizin sorumluluğunuzdadır. Yönetilen platform ise bu işlerin büyük kısmını üstlenir; siz kodu gönderirsiniz, gerisini platform halleder. Karşılığında daha az esneklik ve çoğu zaman daha yüksek birim maliyet kabul edersiniz.

Seçimi ekibinizin yetkinliği belirlemeli. Ekipte Linux sunucu yönetimini bilen ve buna düzenli zaman ayırabilen biri yoksa yönetilen platform daha güvenli bir başlangıçtır. Böylece kurucu ekip zamanını ürüne ve müşteriye harcar. VPS, VDS ve bulut sunucu farklarını ayrıntılı olarak VPS, VDS ve bulut sunucu farkı yazımızda karşılaştırdık.

Büyüme aşamasında bulut ve otomatik ölçekleme ne zaman mantıklı?

Büyüme aşamasında trafik dalgalı hale gelir: kampanya günleri, basında çıkan bir haber ya da yeni bir pazar açılışı ani yük getirir. Bulut altyapısının asıl gücü burada ortaya çıkar. NIST'in bulut bilişim tanımında (SP 800-145) öne çıkan özellikler arasında talep üzerine self servis, hızlı esneklik ve ölçülen hizmet bulunur; yani kaynağı ihtiyaç anında artırıp azaltabilir, kullandığınız kadar ölçülürsünüz.

Ancak otomatik ölçekleme her girişim için gerekli değildir. Trafiğiniz düzenli ve tahmin edilebilir ise iyi boyutlandırılmış birkaç sunucu, karmaşık bir ölçekleme kurulumundan daha ucuz ve daha anlaşılır olabilir. Otomatik ölçekleme, uygulamanızın birden çok kopya halinde sorunsuz çalışabildiği, oturum bilgisini sunucunun belleğinde değil ortak bir depoda tuttuğu durumda anlam kazanır.

Konteyner orkestrasyonu da benzer bir karardır. Ekipte bu sistemleri işletecek bilgi yoksa erken geçiş, çözmekten çok sorun üretir. Konteyner ve orkestrasyon farkı için Docker nedir yazımıza göz atabilirsiniz.

Aşamalara göre startup için hosting seçenekleri nasıl karşılaştırılır?

Aşağıdaki tablo, üç aşamayı ve her aşamada sık görülen hosting yaklaşımlarını özetliyor. Bu bir sıralama değil, bir karar çerçevesidir; sizin ürününüzün ihtiyacı farklı bir kombinasyon gerektirebilir.

Tabloyu okurken şuna dikkat edin: bir aşamadan diğerine geçiş, takvime göre değil sinyallere göre olmalıdır. Hangi sinyallere bakacağınızı aşağıda ayrı bir başlıkta anlatıyoruz. Ayrıca sunucu maliyetini belirleyen kalemleri sunucu kiralama maliyeti neye göre değişir yazımızda inceledik.

Kullandığın kadar öde mi, sabit ücret mi daha güvenli?

Bu sorunun cevabı nakit akışınıza ve trafiğinizin ne kadar tahmin edilebilir olduğuna bağlıdır. Sabit ücretli bir VPS ya da hosting paketi, ay sonunda ne ödeyeceğinizi bilmenizi sağlar. Kullandığın kadar öde modeli ise düşük kullanımda çok ucuz, ani büyümede ise beklenmedik derecede pahalı olabilir.

Biz girişimlere genellikle şu mantığı öneriyoruz:

• Trafik düşük ve düzensizse kullanıma dayalı model mantıklıdır; boşta kalan kapasiteye para ödemezsiniz.
• Trafik düzenli ve tahmin edilebilir hale geldiyse sabit kapasite çoğu zaman daha öngörülebilir bir maliyet sunar.
• Karma bir yapı da mümkündür: temel yükü sabit sunucuda, ani zirveleri esnek kaynaklarda karşılarsınız.

Öte yandan kullanıma dayalı modelde fatura yalnızca işlemci ve bellekten oluşmaz. Depolama, veritabanı işlemleri, dışarı giden veri trafiği (egress), kayıt (log) saklama ve yönetilen servis ücretleri ayrı ayrı faturalanabilir. Bu kalemleri bilmeden yapılan bütçe planı gerçeği yansıtmaz. Bu yüzden sağlayıcının fiyatlandırma sayfasını tek tek okuyun ve kendi kullanım senaryonuz için bir örnek hesap çıkarın.

Beklenmedik bulut faturalarını nasıl önlersiniz?

Girişimlerin sık yaşadığı sorunlardan biri, bir ayın sonunda beklenenin çok üzerinde gelen faturadır. Çoğu zaman sebep basittir: unutulan bir test sunucusu, sınırsız büyüyen kayıt dosyaları, hatalı bir döngünün ürettiği istekler ya da büyük dosyaların dışarıya tekrar tekrar aktarılması.

Bu riski azaltmak için şu adımları uygulamanızı öneriyoruz:

1. Hesap açtığınız gün bütçe uyarılarını kurun ve uyarıyı birden fazla kişiye gönderin.
2. Her kaynağa proje ve ortam etiketi verin; böylece faturada hangi kalemin nereden geldiğini görürsünüz.
3. Test ve geliştirme ortamlarını kullanılmadığında kapatın ya da otomatik kapanacak şekilde ayarlayın.
4. Kayıt saklama süresini sınırlayın; gereksiz ayrıntılı logları üretimde kapatın.
5. Büyük statik dosyaları önbellek ve içerik dağıtım ağı üzerinden sunun; çıkış trafiğini izleyin.
6. Ayda bir kez faturayı kalem kalem okuyun ve beklenmedik artışın sebebini bulun.

Ayrıca API anahtarlarını ve bulut hesabı erişimlerini sıkı tutun. Sızan bir erişim anahtarı yalnızca güvenlik sorunu değil, aynı zamanda ciddi bir fatura riskidir. Bu nedenle ana hesaba iki adımlı doğrulama ekleyin ve günlük işleri sınırlı yetkili kullanıcılarla yapın.

Ücretsiz katmanlar ve startup programlarından nasıl yararlanırsınız?

Birçok bulut ve platform sağlayıcısı ücretsiz kullanım katmanları sunar. Ayrıca bazı sağlayıcıların girişimlere yönelik kredi ya da destek programları da var. Bu programlar ilk dönemde altyapı maliyetini ciddi biçimde azaltabilir; ancak koşulları sağlayıcıdan sağlayıcıya ve zaman içinde değişir.

Biz bu konuda belirli bir firma önermiyoruz, çünkü sağlayıcılar program kapsamlarını sık sık değiştiriyor. Bunun yerine şu soruları sorarak değerlendirmenizi öneriyoruz:

• Kredi ne kadar süre geçerli ve süre dolunca hangi fiyatlandırmaya geçiliyor?
• Hangi hizmetler kapsamda, hangileri kapsam dışında?
• Başvuru için bir hızlandırıcı, yatırım ya da şirket kuruluş şartı var mı?
• Kredi bittiğinde altyapıyı başka bir yere taşımak ne kadar zor olur?

Son soru özellikle önemlidir. Ücretsiz kredi, sizi yalnızca o sağlayıcıya özgü servislere bağlıyorsa kredi bittiğinde yüksek bir faturayla ya da zor bir taşımayla karşılaşabilirsiniz. Dolayısıyla kredileri kullanın, ama mimariyi taşınabilir tutun. Koşulları her zaman sağlayıcının resmi sayfasından doğrulayın; üçüncü taraf listelerdeki bilgiler güncelliğini yitirmiş olabilir.

Neden monolit bir uygulamayla başlamalısınız?

Monolit, uygulamanın tek bir kod tabanı ve tek bir dağıtım birimi olarak çalıştığı yapıdır. Mikroservis mimarisi ise uygulamayı ayrı ayrı dağıtılan küçük servislere böler. Büyük şirketlerin mikroservis kullandığını görmek, girişimleri erken bir bölünmeye yöneltebilir.

Ancak erken aşamada mikroservis genellikle gereksiz bir yük getirir. Her servis için ayrı dağıtım, ayrı izleme, servisler arası iletişim ve hata yönetimi gerekir. Küçük bir ekip için bu, ürün geliştirmeye ayrılacak zamanın altyapıya kayması demektir. Üstelik ürünün hangi parçalarının bağımsız ölçeklenmesi gerektiğini erken aşamada henüz bilmezsiniz.

Bu yüzden biz modüllere net ayrılmış bir monolitle başlamayı öneriyoruz. Kodu modüllere ayırın, modüller arasındaki sınırları net tutun. İleride gerçekten bağımsız ölçeklenmesi gereken bir parça ortaya çıkarsa, o modülü ayrı bir servise dönüştürmek çok daha kolay olur. Kısacası mimariyi bugünkü ihtiyaca göre kurun, yarının ihtiyacına kapı açık bırakın.

Uygulamanızı özel yazılım olarak sıfırdan kurmayı planlıyorsanız özel yazılım geliştirme sayfamızda mimari yaklaşımımızı anlatıyoruz.

Veritabanını uygulamadan ayırmak ne kazandırır?

Erken aşamada uygulama ve veritabanını aynı sunucuda çalıştırmak cazip görünür, çünkü hem kolay hem ucuzdur. Prototip için bu yaklaşım kabul edilebilir. Ancak gerçek müşteri verisi oluşmaya başladığında veritabanını ayrı bir katman olarak düşünmeniz gerekir.

Uygulama mimarisinde yaygın başvuru kaynağı olan The Twelve-Factor App ilkeleri de veritabanı gibi destek servislerini uygulamaya "bağlanan kaynaklar" olarak ele almayı ve yapılandırmayı ortam değişkenlerinde tutmayı önerir. Böylece veritabanının adresini değiştirmek için kodu değil yalnızca yapılandırmayı güncellersiniz.

Ayrı veritabanının pratik faydaları şunlardır: uygulama sunucusunu yeniden kurduğunuzda veri etkilenmez; uygulamayı birden çok kopyaya çoğaltabilirsiniz; yedekleme ve geri yükleme işlemleri bağımsız hale gelir. Yönetilen veritabanı hizmetleri ise yedek, güncelleme ve yük devretme gibi işleri sağlayıcıya bırakmanızı sağlar. Ekipte veritabanı yönetimi bilgisi sınırlıysa bu, çoğu zaman en mantıklı ilk yönetilen hizmettir.

Basit bir ortam değişkeni dosyası örneği şöyle görünebilir:

APP_ENV=production
APP_URL=https://app.example.com
DATABASE_HOST=db.internal.example.com
DATABASE_NAME=uygulama

Bu dosyayı sürüm kontrolüne eklemeyin; parolaları ve anahtarları ayrıca güvenli bir yerde saklayın.

Yedekleme stratejisini ilk günden nasıl kurarsınız?

Yedek, ancak geri yükleyebildiğinizde değerlidir. Girişimlerde en sık rastlanan hata, sağlayıcının otomatik yedeğine güvenip hiç geri yükleme denemesi yapmamaktır. Oysa sorun anında yedeğin eksik, bozuk ya da erişilemez olduğunu fark etmek çok geç olur.

Biz şu temel yaklaşımı öneriyoruz:

• Veritabanını ve kullanıcı yüklemelerini düzenli olarak otomatik yedekleyin.
• En az bir kopyayı ana sağlayıcınızdan farklı bir konumda tutun.
• Yedekleri şifreleyin ve erişimi sınırlayın; yedek de kişisel veri içerir.
• Belirli aralıklarla test ortamına geri yükleme yapın ve süreyi not edin.

Böylece hem ne kadar veri kaybını göze alabileceğinizi hem de sistemi ne kadar sürede ayağa kaldırabileceğinizi gerçekçi biçimde bilirsiniz. Yedekleme stratejisinin ayrıntılarını web sitesi yedekleme stratejisi yazımızda, veritabanı yedeklerini ise veritabanı yedekleme ve geri yükleme rehberimizde anlattık.

CI/CD ve staging ortamı küçük bir ekip için gerekli mi?

Evet, hem de çoğu zaman sanıldığından daha erken. CI/CD, kodun otomatik olarak test edilip derlenmesi ve canlıya alınması sürecidir. Staging ise canlı ortamın bir kopyası gibi davranan, değişiklikleri müşteriye ulaşmadan önce denediğiniz ara ortamdır.

Küçük bir ekipte elle yapılan dağıtım hızlı görünür; ancak her elle adım bir hata fırsatıdır. Yanlış dosya, unutulan bir veritabanı değişikliği ya da eksik bir ortam değişkeni canlı sistemi durdurabilir. Otomatik bir hat, bu adımları her seferinde aynı şekilde uygular.

Twelve-Factor ilkeleri de derleme, sürüm ve çalıştırma aşamalarını birbirinden ayırmayı ve geliştirme, staging ve üretim ortamlarını mümkün olduğunca benzer tutmayı önerir. Pratikte bu şu anlama gelir:

1. Her değişiklik bir sürüm kontrol dalında başlar ve otomatik testlerden geçer.
2. Testi geçen sürüm önce staging ortamına gider.
3. Staging üzerinde kısa bir kontrol yaparsınız, ardından aynı sürümü üretime alırsınız.
4. Sorun çıkarsa önceki sürüme hızlıca dönebileceğiniz bir geri alma yolu hazır olur.

Başlangıç için karmaşık bir hat kurmanız gerekmez. Kod deposu hizmetlerinin çoğu yerleşik otomasyon özellikleri sunar; ilk adımda testleri çalıştırıp staging ortamına otomatik dağıtım yapmanız yeterlidir. Ardından ihtiyaç doğdukça güvenlik taraması ve veritabanı değişikliği kontrolleri eklersiniz.

Staging ortamının gerçek müşteri verisi içermemesine dikkat edin. Test için sahte veri ya da kimlik bilgilerini temizlediğiniz bir kopya kullanın.

Ölçeklenme sinyalleri: altyapıyı büyütme zamanını nasıl anlarsınız?

Altyapı kararlarını takvime göre değil, ölçülen sinyallere göre vermelisiniz. Sürekli yüksek seyreden işlemci ya da bellek kullanımı, yavaşlayan sayfa yanıt süreleri, veritabanı sorgularının uzaması ve yoğun saatlerde artan hata oranları en belirgin sinyallerdir.

Bu sinyalleri görebilmek için temel izlemeyi erken kurun: sunucu kaynak kullanımı, uygulama hata kayıtları ve basit bir erişilebilirlik kontrolü yeterli bir başlangıçtır. Böylece "site yavaşladı" şikâyetini müşteriden duymadan önce siz fark edersiniz.

Sinyal geldiğinde ilk adım çoğu zaman mevcut paketi büyütmektir; bunu kesintisiz yapmanın yolunu hosting paketi yükseltme yazımızda anlattık. Mevcut sağlayıcı ihtiyacı karşılayamıyorsa taşınma gündeme gelir; bu durumda hosting değiştirme kontrol listesi işinizi kolaylaştırır. Taşıma sırasında DNS kayıtlarını DNS sorgulama aracı ile kontrol edebilirsiniz.

Unutmayın: performans sorunlarının bir kısmı altyapıdan değil koddan kaynaklanır. Önce yavaş sorguları, eksik önbelleği ve gereksiz dış istekleri inceleyin; sunucuyu büyütmek her zaman doğru çözüm değildir.

Vendor lock-in riski nedir, taşınabilirliği nasıl korursunuz?

Vendor lock-in, yani sağlayıcıya kilitlenme, altyapınızın tek bir sağlayıcının özel servislerine o kadar bağlı hale gelmesidir ki başka bir yere taşınmak çok pahalı ya da çok zor olur. Girişimler için bu risk özellikle önemlidir, çünkü ilk dönemde seçtiğiniz sağlayıcı büyüme aşamasında ihtiyacınıza uymayabilir.

Kilitlenmeyi tamamen önlemek gerçekçi değildir; her yönetilen hizmet bir miktar bağımlılık getirir. Asıl hedef, bağımlılığı bilinçli seçmek ve çıkış yolunu açık tutmaktır. Bunun için şu yöntemleri öneriyoruz:

• Uygulamayı konteyner olarak paketleyin; Docker'ın resmi dokümanına göre konteynerler geliştirici bilgisayarında, veri merkezinde ya da farklı bulut sağlayıcılarında aynı şekilde çalışabilir.
• Veritabanı olarak yaygın, açık kaynaklı motorları tercih edin.
• Altyapı ayarlarını belgeleyin ya da kod olarak saklayın.
• Alan adı, DNS ve yedekler gibi kritik varlıkları kendi kontrolünüzde tutun.

Örneğin sağlayıcıya özgü bir kuyruk ya da kimlik servisi kullanmak hızlı olabilir; yine de bu kararın çıkış maliyetini önceden not edin. Bu sayede ileride taşınma gerektiğinde nereden başlayacağınızı bilirsiniz.

Kendi PaaS'ınızı kurmak bir girişim için mantıklı mı?

Yönetilen platformların kullanım kolaylığını kendi sunucunuzda elde etmek mümkündür. Coolify gibi açık kaynaklı, kendi sunucunuza kurduğunuz PaaS araçları, kodu depodan çekip konteyner olarak çalıştırma, sertifika alma ve birden çok uygulamayı tek panelden yönetme imkânı sunar.

Bu yaklaşım, sabit maliyetli bir VPS üzerinde yönetilen platform deneyimine yakın bir çalışma düzeni isteyen ekipler için cazip olabilir. Ancak bir bedeli vardır: sunucunun kendisi, işletim sistemi güncellemeleri, güvenlik ve yedek hâlâ sizin sorumluluğunuzdadır. Platform aracı da güncellenmesi gereken bir yazılımdır.

Biz şu durumda bu yolu mantıklı buluyoruz: ekipte Linux ve Docker bilgisi olan biri var, birden fazla küçük uygulama aynı sunucuda çalışacak ve maliyet öngörülebilirliği önemli. Buna karşılık ekipte bu bilgi yoksa ya da tek bir kritik uygulama çalıştırıyorsanız yönetilen platform daha az risklidir. Coolify'ı adım adım kurmak için Coolify nedir ve nasıl kurulur rehberimize bakabilirsiniz.

Güvenliği ve KVKK'yı neden ilk günden planlamalısınız?

Girişimler genellikle güvenliği "büyüyünce hallederiz" diye erteler. Oysa sonradan eklenen güvenlik, baştan tasarlanandan hem daha pahalı hem daha zayıftır. Üstelik ilk müşteri verisini topladığınız andan itibaren yasal yükümlülükleriniz başlar.

Türkiye'de kişisel verileri işleyen bir girişim, 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamında veri sorumlusu olabilir. Kanunun resmi metnine göre 12. madde, veri sorumlusunun uygun güvenlik düzeyini sağlamak için gerekli teknik ve idari tedbirleri almasını öngörür; 9. madde ise kişisel verilerin yurt dışına aktarımını düzenler. Bu nedenle sunucunuzun ve yedeklerinizin hangi ülkede bulunduğu, hosting kararının bir parçasıdır. Bu bilgi hukuki danışmanlık değildir; kendi durumunuz için bir hukukçuya danışın.

Teknik tarafta temel adımlar şunlardır: her yerde HTTPS kullanın, yönetim panellerine iki adımlı doğrulama ekleyin, en az yetki ilkesiyle erişim verin ve yazılımları güncel tutun. Uygulama katmanındaki yaygın açıkları ve önlemlerini OWASP Top 10 web güvenlik açıkları yazımızda topladık. Uyumlu site yapısı için KVKK ve GDPR uyumlu web sitesi yazımız yol gösterir.

SaaS girişimlerinde çok kiracılı mimari hosting kararını nasıl etkiler?

SaaS ürünlerinde birden çok müşteri, yani kiracı, aynı uygulamayı kullanır. Çok kiracılı (multi tenant) mimaride müşterilerin verisini nasıl ayırdığınız, hosting kararını doğrudan etkiler. Yaygın üç yaklaşım vardır: her müşteriye ayrı veritabanı, tek veritabanında ayrı şemalar ya da tek şemada müşteri kimliğiyle ayrılmış kayıtlar.

Ayrı veritabanı güçlü izolasyon sağlar; ancak müşteri sayısı arttıkça yönetim ve yedekleme yükü büyür. Tek şemalı yapı ise başlangıçta basittir; buna karşılık her sorguda müşteri ayrımını doğru yapmak zorundasınız, aksi halde bir müşterinin verisi diğerine görünebilir.

Biz erken aşamadaki çoğu SaaS girişimi için tek veritabanı ve sıkı uygulanan müşteri kimliği ayrımıyla başlamayı, büyük ya da özel gereksinimli müşteriler için ileride ayrı veritabanı seçeneğini açık tutmayı mantıklı buluyoruz. Kurumsal müşteriler verinin belirli bir ülkede tutulmasını isteyebilir; bu talep, sağlayıcı ve bölge seçiminizi etkiler. SaaS pazarlaması tarafında ise SaaS şirketleri için SEO ve GEO stratejisi yazımız işinize yarar.

Hangi işleri kendiniz yapmamalı, yönetilen hizmete bırakmalısınız?

Dürüst olmak gerekirse, bir girişimin her altyapı işini kendisi yapması çoğu zaman yanlış bir tasarruftur. Kurucu ekibin saati, ürün ve müşteri için harcandığında çok daha değerlidir. Bu yüzden şu işleri, ekipte gerçek uzmanlık yoksa yönetilen hizmete ya da hosting sağlayıcınıza bırakmanızı öneriyoruz:

• Veritabanı işletimi: Yedek, güncelleme ve yük devretme hata kabul etmez.
• E-posta gönderimi: Teslim edilebilirlik ve itibar yönetimi ayrı bir uzmanlık alanıdır.
• Sertifika ve DNS altyapısı: Sağlayıcının otomatik araçlarını kullanın.
• Sunucu güvenliği ve yamalar: Düzenli zaman ayıramıyorsanız yönetilen sunucu tercih edin.
• Ödeme altyapısı: Kart verisini kendi sunucunuzda tutmayın; ödeme kuruluşunun çözümünü kullanın.

Kendi yönetiminizde tutmanız gerekenler ise kod, yapılandırma, alan adı, yedeklerin bir kopyası ve erişim yetkileridir. Kısacası işletimi devredebilirsiniz, ama sahipliği devretmeyin.

Ekibinizde güçlü bir teknik kurucu olsa bile şu soruyu sorun: gece yarısı veritabanı durduğunda kim uyanacak? Cevap "yine aynı kişi" ise o kişinin zamanı ürün geliştirmeden çalınıyor demektir. Bu durumda yönetilen hizmetin ek maliyeti, çoğu zaman kaybolan odaktan daha ucuza gelir. Ürün büyüyüp ekibe altyapı uzmanı katıldığında bu kararı yeniden değerlendirebilirsiniz.

Startup için hosting kontrol listesi: yayına almadan önce neleri doğrulamalısınız?

Aşağıdaki liste, startup için hosting kararını verdikten sonra canlıya çıkmadan önce gözden geçirmenizi önerdiğimiz maddeleri özetliyor. Her madde, önceki bölümlerde anlattığımız bir ilkeye dayanıyor.

1. Alan adı ve DNS kendi hesabınızda, erişimi iki adımlı doğrulama koruyor.
2. Kod sürüm kontrolünde, yapılandırma ortam değişkenlerinde ve parolalar koda gömülü değil.
3. Veritabanı yedekleri otomatik, en az bir kopya farklı konumda ve geri yüklemeyi en az bir kez denediniz.
4. Staging ve üretim ayrı; dağıtım otomatik ve geri alma yolu hazır.
5. Bütçe uyarıları kurulu, kaynaklar etiketli ve aylık fatura incelemesi takvimde.
6. Temel izleme ve hata kayıtları çalışıyor; uyarılar doğru kişiye gidiyor.
7. HTTPS her yerde aktif; sertifika durumunu SSL sorgulama aracı ile kontrol ettiniz.
8. Kişisel verinin nerede durduğunu ve kimlerin eriştiğini belgelediniz.

Site yapısı, mesaj ve yatırımcıya dönük içerik tarafını ise startup web sitesi nasıl olmalı yazımızda ele aldık. Altyapı kararları değişir; bu listeyi her büyüme aşamasında yeniden gözden geçirmenizi öneriyoruz.