Bir VPS Sağlayıcısı Önermeden Önce Sorduğum Sorular

"Hangi VPS sağlayıcısını kullanmalıyız?" sorusu hemen hemen her yeni projenin en başında masaya gelir.

Bunun hiçbir zaman tek bir doğru cevabı yoktur. Avrupalı bir kitleye hizmet veren yüksek trafikli bir uygulama için doğru sağlayıcı, trafiği düşük bir şirket içi raporlama aracı için olanla tamamen farklıdır. O da, aylık maliyetin kesinlikle en düşük seviyede olmasını isteyen ve daha fazla manuel sunucu yönetimi yapmaya tamamen dünden razı olan bir müşteri için olan doğru sağlayıcıdan bambaşkadır.

Tamamen tutarlı kalan tek şey ise seçenekleri asıl daraltan o belirli soru setidir. Şaşırtıcı bir şekilde, bu soruların neredeyse hiçbirinin, özellik karşılaştırma sayfasındaki o süslü CPU benchmark skorlarıyla uzaktan yakından alakası yoktur.

Veri merkezi (datacenter) seçeneklerine kıyasla kullanıcılarınız nerede?

Gezegenin öbür ucundaki bir veri merkezine olan gecikme (latency), ne kadar sunucu optimizasyonu (tuning) veya önbellekleme (caching) yaparsanız yapın asla çözemeyeceğiniz, taşa kazınmış sabit bir maliyettir.

Eğer bir müşterinin kitlesi belirli bir bölgede yoğunlaşmışsa, sağlayıcının o bölgeye kıyasla fiziksel veri merkezi konumları, sentetik CPU benchmark'larından çok daha fazla önem taşır. Teknik olarak cayır cayır hızlı olan ama kullanıcılarınızın çoğundan üç saat dilimi uzakta bulunan bir sunucu, pratikte coğrafi olarak onlara çok yakın olan mütevazı ve ortalama bir sunucudan çok daha yavaş hissettirecektir. Çünkü algılanan yükleme süresinin (load time) oldukça anlamlı bir kısmı, sunucunun işlem süresi değil, sadece gidiş-dönüş ağ gecikmesidir.

Yeniden boyutlandırma (resizing) işlemi gerçekte ne anlama geliyor?

"Sunucuyu daha sonra büyütebilir miyim?" sorusu, cevabın neredeyse evrensel olarak "evet" olduğu bir sorudur.

"Yeniden boyutlandırma aslında neleri kapsıyor?" sorusunun cevapları ise sağlayıcıdan sağlayıcıya çılgınca değişir. Bazı sağlayıcılar bir VPS'i iki dakikada yürürlüğe giren basit bir yeniden başlatma (reboot) ile yeniden boyutlandırır. Diğerleri ise sizi tamamen farklı bir fiziksel donanıma taşımaya (migrate) zorlar, ciddi bir kesinti süresi (downtime) yaşatır ve hatta bazen herkese açık IP adresinizi (public IP) bile değiştirir.

Büyüme ihtimali yüksek olan bir proje için, "ölçeği büyütmek" (scale up) beş dakikalık bir yeniden başlatma mı demek, yoksa yoğun şekilde planlanmış stresli bir göç mü demek; işte bu her şeyi değiştirir. En başta ne kadar ekstra kapasite (headroom) ayırmanız gerektiğine ya da küçük başlayıp yavaş yavaş büyüme konusunda ne kadar rahat olacağınıza bu karar verir.

"Yedeklemeler" neleri gerçekten kapsıyor?

Birçok sağlayıcı "yedeklemeleri" (backups) otomatik, zamanlanmış bir eklenti (add-on) olarak gururla öne çıkarır. Asıl sorulmaya değer sorular şunlardır: Bu yedekler, VPS'in kendisiyle tam olarak aynı depolama dizisinde (storage array) mi saklanıyor (yani depolama seviyesinde bir arıza ikisini birden mi yok eder)? Günlük veya haftalık kaç adet yedek saklanıyor (retention)? Kendi başınıza bir butona tıklayıp geri yükleyebilir misiniz, yoksa bir destek bileti (support ticket) açıp beklemeniz mi gerekiyor?

Fiyatlandırma sayfasında kulağa inanılmaz derecede güven verici gelen bir snapshot özelliği, sadece 24 saat saklanan ve sunucuyla tam olarak aynı fiziksel dizide depolanan tek bir günlük snapshot çıkabilir. Bu elbette hiç yoktan iyidir, ancak kesinlikle güvenilir bir yedekleme stratejisi değildir. Sadece kendiniz düzgün bir tane kurmaya giderken size bir tık zaman kazandırır.

Müşteri hizmetleri (support) gerçekte neye benziyor?

Aşırı ucuz bütçeli sağlayıcılarda, destek sıkı bir şekilde bilet tabanlıdır (ticket-based) ve yanıt süreleri saatler hatta günlerle ölçülür. Acil olmayan bir fatura sorusu için bu gayet uygundur. Ancak son derece uygunsuz bir zamanda production tamamen çöktüğünde bu durum o kadar da uygun olmayacaktır.

Daha üst segment sağlayıcılarda ise özel telefon desteği veya 15 dakika garantili yanıt biletleri, ödediğiniz o devasa ekstra ücretin tam olarak karşılığıdır. İki model de özünde yanlış değildir, ancak kritik olan şey, bir müşterinin aktif bir olay (incident) olmadan önce, yani krizin tam ortasındayken değil, aslında hangisine imza attığını kesinlikle biliyor olmasıdır.

Gerçekliği hissetmenin acımasızca hızlı bir yolu: Reddit veya Twitter'da sağlayıcının adını "support" kelimesiyle birlikte aratın. Sadece satış sayfasının agresifçe vaat ettiklerine körü körüne güvenmek yerine, mevcut müşterilerin gerçek dünyadaki tecrübelerinin ne olduğuna bakın.

Faturalandırma modeli müşterinin gerçekten öngörebileceği bir şey mi?

Sabit miktarda CPU, RAM ve depolama için belirlenmiş düz ve öngörülebilir bir aylık fiyatın müşteri tarafından bütçelenmesi inanılmaz derecede kolaydır.

Tamamen kullanıma dayalı faturalandırılan her şey—bant genişliği aşımları, disk IOPS değerleri veya ek IP'ler gibi—aydan aya tahmin edilmesi imkansız, korkutucu bir faturaya hızla dönüşebilir. Bu durum, sabit bir yıllık bütçeyi sıkı bir şekilde yöneten bir müşteri için, değişken ölçeklendirme maliyetlerinin tamamen beklendiği ve yakından izlendiği devasa bir projeden çok daha önemlidir.

Bu, genel olarak kullanıma dayalı (usage-based) faturalandırmaya karşı bir argüman değildir; onun yeri kesinlikle ayrıdır. Ancak bu durum, müşterinin altı ay sonra devasa bir faturayla şiddetli bir şekilde yüzleşmesine izin vermek yerine, en baştan açıkça masaya yatırılması gereken bir konudur.

DDoS koruması: dahil mi, yoksa "kullanılabilir" mi?

Temel DDoS hafifletme (mitigation), artık çoğu modern sağlayıcı için olmazsa olmaz bir standarttır. Ancak "kullanılabilir" (available) kelimesi bazen bunun ekstra ücretli bir premium paket olduğu veya açıkça etkinleştirilip yapılandırılması gereken tamamen ayrı bir ürün olduğu anlamına gelir. Diğer sağlayıcılar için ise ağdaki her bir sunucu için varsayılan olarak zaten açıktır.

Dışa açık (public-facing) her proje için, bir sağlayıcının tam olarak hangi kategoriye düştüğünü—ve hafifletme sisteminin aslında ne ölçekte bir saldırıyı kapsadığını—bilmek, aktif bir saldırı altındayken çaresizce ona ihtiyaç duymadan önce beş dakikalık bir okumaya kesinlikle değer.

Asıl Çıkarım

Bu özel soruların hiçbirinin evrensel olarak doğru veya yanlış bir cevabı yoktur. Bunlar, ağır bir şekilde projenin kendi spesifik gerçekliğine bağlı olan bir karara giren kritik girdilerdir.

Hepsinin ortak noktası, hiçbirinin o parlak özellik karşılaştırma sayfasında açıkça görünmemesidir. Ve bunların istisnasız hepsi, kredi kartı bilgilerinizi girmeden önce açıkça bilmeyi tercih edeceğiniz; bir olay anında, göç sırasında veya şoke edici derecede büyük bir faturayla zor yoldan öğrenmek istemeyeceğiniz şeylerdir.

Bunları en baştan sormak tam olarak beş dakikanızı alır ve "en iyi sağlayıcı hangisi?" gibi imkansız bir soruyu, " bu özel proje için en iyi sağlayıcı hangisi?" şekline dönüştürür. Zaten iyi bir cevabı olan tek soru da budur.