2023'te ihtişam yalnızca 11 MB/sn uzakta

Bulut maliyetlerine dair gerçek

• Bulut hizmetlerinin ucuz olduğu yönünde bir algı var, ancak gerçekte kullanıcıların aşırı maliyet ödeme ihtimali bulunuyor.
• AWS, Amazon'un kârının büyük bölümünü yaratıyor; bu da bulut hizmetlerinin aslında pahalı olabileceği anlamına gelebilir.

İlk ilkelerden hesaplama

• En büyük 1000 web sitesinden birini kurmak istiyorsanız, örneğin businessinsider.com gibi aylık 200M ziyaretçi ve 400M sayfa görüntüleme gerekir.
• Yalnızca HTML belgeleri için ayda 30TB bant genişliği gerekir, ancak bu saniyede sadece 11MB anlamına gelir; bu da modern donanım için oldukça düşük bir ölçüttür.

Gecikmeyi anlamak

• Işık hızına göre dünyanın öbür ucuna gidiş-dönüş yaklaşık 200ms sürer, ancak pratikte bu süre yaklaşık 300ms'dir.
• JS, CSS ve medyayı CDN ile sunarsanız, sunucu işleme süresinden 300ms düşerek sunucuyu kullanıcının yanına koymuşsunuz gibi bir etki elde edebilirsiniz.

Edge teknolojilerinin sınırları

• Edge teknolojileri, ikinci nesil serverless teknolojilerdeki gelişmelere rağmen veritabanı sorununu çözemiyor.
• Karmaşık sayfaların çoğu veritabanı sorguları gerektirir ve bu da gecikmeyi artırabilir.

Maliyet üzerine düşünceler

• Hetzner.com, AWS EC2 ile karşılaştırıldığında çok daha ucuz sunucu ve bant genişliği maliyetleri sunuyor.
• Bulut sağlayıcıları başlangıçta pek çok şeyi ücretsiz veriyor, ancak ölçek büyüdükçe maliyetler ciddi biçimde artıyor.

Gerçekçi durum

• Belirli kullanım senaryoları dışında, çoğu web sitesi veya SaaS tek bir sunucuda çalışabilir; bu da daha ucuzdur ve bakımı daha kolaydır.
• SQLite'ı yerelde kullanıp CSS, JS ve görselleri CDN üzerinden önbelleğe alarak ve sunucu taraflı render ile performansı artırabilirsiniz.
• Karmaşık Docker ya da sanallaştırma olmadan da yeterince ölçeklenmek mümkündür; ayrıca yönetimi daha kolay ve maliyeti daha düşüktür.

GN⁺ görüşü

• Bu yazı, bulut hizmetlerinin maliyet etkinliğine dair yaygın inanca meydan okuyor ve kullanıcıların gerçekte ihtiyaç duyduklarından daha fazla ödüyor olabileceğine dikkat çekiyor.
• Bulut hizmetlerinin maliyet yapısıyla karşılaştırıldığında, geleneksel tek sunuculu barındırmanın hâlâ geçerli bir alternatif olabileceğini gösteriyor.
• Serverless, Docker ve yatay ölçeklenebilirlik gibi teknolojilerin her durumda gerekli olmadığını; bazen daha basit bir yaklaşımın daha iyi performans ve maliyet tasarrufu sağlayabileceğini vurguluyor.
• Veritabanı optimizasyonu ve bölgesel yerleşimin önemini öne çıkarıyor; bunun, bulut hizmetlerinin sunduğuna eşdeğer veya daha iyi performans sağlamaya yardımcı olabileceğini ima ediyor.
• Teknoloji seçerken gerçek trafik ve performans gereksinimlerini değerlendirmek, maliyet-etkinliği dikkate alarak bulut yerine geleneksel sunucu barındırmayı da düşünmek gerektiğini belirtiyor.

[GN⁺]

Hacker News görüşleri

• Hosting işinden deneyimler

  • Geçmişte hosting işinde, müşteri taleplerine göre karmaşık sistemler sunuluyordu.
  • AWS’ye karşılık vermek için API tabanlı bir bulut hosting platformu geliştirildi, ancak gelir 2012’de zirve yaptı.
  • Müşteriler, AWS tabanlı daha karmaşık çözümler istiyordu ve basit sunuculara güvenmiyordu.
  • Şirket bootstrap yöntemiyle işletiliyordu ve AWS’nin maliyet riskini üstlenme gerekliliğini anlamıyordu.
  • AWS, yazılım geliştirici kuşağına derinlemesine yerleşmiş olan "zekice olma" kültürü nedeniyle tercih ediliyor.

• Trafik analizindeki hatalar

  • Trafik eşit dağılmaz; yoğun saatlerde gereken bant genişliği ortalamadan çok daha yüksektir.
  • Gerçek servislerde TCP ve TLS bağlantı kurulumu birkaç gidiş-dönüş gerektirir ve kullanıcı deneyimi açısından yanıt süresi önemlidir.

• Sunucu hataları ve trafik

  • 500 Internal Server Error, sunucunun beklenenden fazla trafiği işlediğini gösterir.

• Hizmeti ölçeklendirmeye yaklaşım

  • Gereksiz ölçeklendirmeden kaçınmak ve yalnızca gerektiğinde bir şeyler inşa etmek tercih edilir.
  • Performans sorunu ortaya çıktığında müdahale etmek daha iyidir.

• AWS’nin avantajları

  • AWS kullanmak, hizmet kesintisi olduğunda bir mazeret alanı sağlar.

• Bulut mimarisi üzerine tartışma

  • Bu, bulut mimarisinin gerekliliğiyle ilgili bir tartışma değil; alternatif sunmak için bir araçtır.
  • Sunucu çökerse ortaya çıkan erişilebilirlik sorunları başka yöntemlerle çözülebilir.

• SQLite ve dikey ölçeklendirme

  • SQLite yerine kendi kendine barındırılan Postgres kullanılabilir, ancak bu daha fazla kurulum çabası gerektirir.
  • Tüm küresel durumu bellekte tutup diske snapshot kaydeden bir mimari mümkündür.

• API ile SQLite veritabanının birleşimi

  • SQLite, tek bir thread üzerinde çok sayıda sorgu işleyebilir.
  • API tarafında bellek önbellekleme kullanmak ve statik sayfalarda veritabanını atlamak performansı artırabilir.

• Tek sunucunun erişilebilirlik sorunları

  • Hizmeti tek bir sunucuda çalıştırmak, planlanmamış kesintilere yol açabilir.
  • Veri kurtarma süresiyle veri kaybı miktarı dikkate alınmalıdır.

• Buluta geçiş ve erişilebilirlik

  • Buluta geçiş çoğu zaman akran baskısı gibi hissettirilir.
  • Erişilebilirlik açısından tek sunucu riskli olabilir; CDN ile bulutu akıllıca harmanlayarak kullanmak daha iyidir.