2023'te Zafer Yalnızca 11MB/sn Uzaklıkta
(thmsmlr.com)- Aylık 200 milyon ziyaretçi ölçeğindeki ilk 1000 içindeki bir web sitesi bile yalnızca HTML açısından bakıldığında ayda yaklaşık 30TB/ay, ortalama 11MB/sn aktarım hacmine sahip; yani tek bir sunucunun kaldırabileceği bir ölçek
- Hesaplama, Business Insider örneğini temel alarak ziyaretçi başına 2 sayfa, ayda 400 milyon HTML belgesi ve sıkıştırılmış HTML boyutu yaklaşık 75KB varsayımıyla; JS, CSS ve görsellerin CDN üzerinden sunulduğu kabul edilerek yapılıyor
- Edge üzerinde çalıştırmanın kullanıcıya yakın sunucu avantajı var, ancak render sırasında veritabanına gidiş-dönüş oluşursa gecikme yeniden asıl veritabanının bulunduğu yere çekiliyor
- Maliyet farkı da büyük: Hetzner, 16 çekirdekli, 64GB RAM'li, NVMe'li sunucuyu $0.34/saat karşılığında sunuyor; 20TB ücretsiz aktarım sonrasında $1.5/TB alırken AWS ve Vercel'de bant genişliği birim fiyatı çok daha yüksek
- Özel olarak bulut gerektiren bir iş yükü yoksa tek sunucu + SQLite + Litestream + CDN yapısı daha basit, daha ucuz ve gereksiz yatay ölçeklemeden kaçınmayı sağlıyor
11MB/sn açısından üst sıralardaki web sitelerinin gerçek ölçeği
- İlk 1000'de yer alan bir web sitesi örneği olarak Business Insider kullanılıyor
- SimilarWeb'e göre dünya genelinde 587. sıradaydı ve aylık ziyaretçi sayısı yaklaşık 200 milyondu
- Ziyaretçi başına ortalama 2 sayfa kabul edilirse ayda 400 milyon HTML belgesi sunulması gerekiyor
- Örnek bir makaleye göre standart HTML belgesi sıkıştırıldıktan sonra yaklaşık 75KB
- Bu değerler çarpıldığında yalnızca HTML için yaklaşık 30TB/ay bant genişliği gerekiyor
- 30TB/ay ortalamaya vurulduğunda yaklaşık 11MB/sn ediyor
- Business Insider örneğinde bu, yaklaşık 150 requests/sec düzeyine denk geliyor
- Varsayım, HTML için CDN kullanılmadığı; JS, CSS ve görseller ise CDN ile sunulabilir
- Sıkıştırılmış 75KB HTML büyük sayılabilir; uygulamaya göre HTML boyutu küçültülerek ya da istek sayısı artırılarak farklı ayarlamalar yapılabilir
- Modern donanımda uygulama kodunun 11MB/sn HTML üretmesi düşük bir eşik
- Güncel AMD sunucu işlemcileri 64 çekirdek ve 128 thread sunuyor
- Zen 5 Turin sunucu işlemcilerinin 192 çekirdeğe çıkacağı konuşuluyor; çift soketli sunucularda 400 çekirdeğe yakın yapılandırmalar ve 768 thread'e kadar rakamlar anılıyor
- Bu açıdan bakıldığında Docker, serverless ve yatay ölçekleme her zaman gerekli seçenekler değil
Edge üzerinde çalıştırmak her zaman gecikmeyi azaltmaz
- Dünyanın öbür ucuna gidiş-dönüş gecikmesinin fiziksel alt sınırı ışık hızına göre yaklaşık 200ms
- Pratikte ise dünyanın öbür ucundaki iyi bir veri merkezine ulaşmak çoğu zaman yaklaşık 300ms sürüyor
- JS, CSS ve medyayı CDN ile sunuyorsanız ilk render sırasında sunucu işlem süresinden 300ms azaltmak, sunucuyu kullanıcıya yaklaştırmanın etkisine benzer bir sonuç verebilir
- İkinci nesil serverless teknolojileri, geçmişte cold boot nedeniyle 300ms'lik gecikme bütçesinin kolayca harcanması sorununu büyük ölçüde azalttı; ancak veritabanı gidiş-dönüşleri hâlâ duruyor
- Sayfa render'ı için tek bir veritabanı sorgusu bile gerekiyorsa edge sunucu, asıl veritabanının bulunduğu us-east-1 gibi bir konuma yeniden gidip gelmek zorunda kalıyor
- Gecikme, kullanıcı-asıl sunucu hattından edge sunucu-asıl sunucu hattına taşınmış oluyor
- Karmaşık sayfalarda render için çoğu zaman 5'ten fazla veritabanı sorgusu gerekiyor
- Birçok web framework'ü sorguları tek thread üzerinde sıralı çalıştırdığı için veri merkezleri arasında birden fazla gidiş-dönüş, bazen tek seferde doğrudan asıl sunucuya gitmekten daha yavaş olabiliyor
- Tecrübeye dayalı bir kural olarak veri merkezleri arası iletişim, veri merkezi içi iletişimden 10 kat daha yavaş; veri merkezi içi iletişim de aynı cihaz içindeki iletişimden 10 kat daha yavaş kabul ediliyor
- Bu bağlamda yerel SQLite, gecikmeyi azaltmak için avantajlı bir seçenek olarak öne çıkıyor
Hetzner, AWS ve Vercel arasındaki maliyet farkı
- Hetzner'in 16 çekirdekli sunucusu, 64GB RAM ve NVMe disk ile birlikte $0.34/saat
- Benzer bir x86 sunucu olarak karşılaştırılan AWS EC2 m5a.4xlarge ise $0.68/saat
- Bant genişliği fiyat farkı daha da büyük
- Hetzner, 20TB aktarımı ücretsiz veriyor ve sonrasında $1.5/TB ücret alıyor
- AWS, 100GB ücretsiz veriyor ve sonrasında $90/TB alıyor
- Vercel için ilk 1TB ücretsiz, sonrasında $200/TB ücret alınan bir örnekten bahsediliyor
- Bulut sağlayıcılarının ücretsiz kotaları başlangıcı kolaylaştırsa da ölçek büyüdüğünde yüksek maliyet olarak geri dönebilir
Tek sunuculu yapıyla işleri basit tutmak
- Video transcode etme, kendi yapay zeka modelini çalıştırma ya da sisteme gerçekten büyük yük bindiren işler gibi belirli bulut kullanım senaryoları yoksa bir web sitesi veya SaaS, tek bir sunucuda çalıştırılabilir
- Sunucuyu Virginia'ya koyarsanız İngilizce konuşan kullanıcılara 100ms altı gecikme sunmak mümkün olabilir
- Önerilen yapı, tek bir sunucu etrafında sade tutuluyor
- Veritabanı olarak aynı makinedeki SQLite kullanılıyor
- Litestream ile SQLite sürekli yedekleniyor
- CSS, JS ve görseller CDN üzerinde cache'leniyor
- SQLite'a yakın yerde server-side rendering yapılarak gidiş-dönüşler azaltılıyor ve performans artırılıyor
- Dağıtımı da karmaşıklaştırmaya gerek yok
- CI, kodu sunucuya SCP ile gönderebilir
- NGINX, kesintisiz dağıtımı destekliyor
- Docker ve sanallaştırma, kod çalıştırmayı ve CI/CD'yi yavaşlatan unsurlar olarak ele alınıyor
Yatay ölçeklemenin gerekli olduğu ve olmadığı durumlar
- Yatay ölçeklemenin gerekli olduğu iddiası çoğu durumda abartılıyor
- Sunucu performansının internetin büyümesinden daha hızlı geliştiği varsayımı temel alınıyor
- Gecikme gerçekten kritikse Almanya ve Kaliforniya'ya ek sunucular yerleştirmek mümkün
- Yazmalar primary'ye yönlendiriliyor
- Okumalar yerel read replica üzerinden yapılıyor
- Bu tür bir yapı yeterince ölçeklenebilir, yönetim karmaşıklığı düşük ve maliyeti de oldukça ucuz
- 11MB/sn ölçeğinde HTML sunumunu gereksiz yere zorlaştırmaya gerek yok
1 yorum
Hacker News yorumları
Eski küçük hosting işimiz tam da bu noktada yükseliş ve düşüş yaşadı; o zamanlar neler olduğunu anlamamıştık.
2000’lerin başında büyürken büyük gelirler genelde karmaşık stack’lerden geliyordu; yedekli load balancer’lar ve firewall’lar gibi müşterilerin gerçekte ihtiyaç duyduğundan fazla olan çok sayıda kurulum vardı, ama müşteriler bunları istiyordu.
Failover, çoğu zaman bir sunucu beklenen şekilde öldüğünde sağladığı faydadan daha fazla operasyonel karmaşıklık maliyeti getiriyordu; AWS’ye karşı API tabanlı bir bulut hosting platformu da yaptık, ama gelir 2012’de zirve yaptı.
Müşteriler AWS’yi kısmen ya da tamamen kullanan daha karmaşık çözümler istiyordu; biz ise donanım 10 yıl öncesine göre çok daha güçlü hale geldiği için büyük müşterilerin de daha az sayıda, daha basit sunucu isteyeceğini düşünüyorduk.
Ama bu zekâyı satmak değil, fiyat satmaktı ve böyle bir dönüşüm için gereken finansal hırsı anlayamamıştık. Ucuz tek sunucuya kimse güvenmedi; iki tane alsalar bile ölçeklenebilirlik için yeterli bir cevap yoktu.
Sonunda gelir ayakta kaldı, ama Amazon’dan daha hızlı şekilde yönetilen servis stack’i ve yazılım ekosistemi kuramadık; yeni teknik meydan okumalar kuruduktan sonra şirketi 2018’de sattık.
Bootstrap büyüdüğümüz için sınırsız hosting faturası çılgın bir risk gibi geliyordu; ürün tasarımımız da bu düşünceden çıkmıştı, ama herkesin bu riski aldığını sonradan gördük.
AWS’nin tutmasının nedeni yalnızca VC’nin pahalı ürünleri mümkün kılması değildi; onlara özgü zekânın bir yazılım geliştirici kuşağının içine işlemiş olmasıydı. Yine de buluta ne zaman ihtiyaç olmadığını ve alternatiflerin ne olduğunu bilmek artık epey niş bir bilgi gibi geliyor.
Sayılarda birkaç sorun var.
Birincisi, trafik eşit dağılmaz. Yazıdaki aylık 400 milyon sayfa yükleme rakamına yinelemeli bir 80/20 kuralı uygulanabilir; böyle bakınca 5,8 saat içinde yaklaşık 205 milyon istek yığılır ve bu da saniyede yaklaşık 9,7 bin istek eder.
Tek bir sistemle hâlâ mümkün, ama artık önemsiz değil; özellikle de okuma replikası olmayan tek bir DB istiyorsanız. Toplam trafik aynı olsa bile pik yük için gereken bant genişliği limiti, iyimser bir ortalamayla bulunan 11MB/s’den çok daha yüksek olur.
İkincisi, tek yönlü uçtan uca gecikme yalnızca streaming veri için geçerlidir. Gerçek dünyadaki cold start’ta HTTP/3 yoksa TCP bağlantısı için 3 round trip, TLS bağlantısı için en az 2 round trip gerekir; HTTP isteği ve yanıtı ancak bundan sonra gidip gelir.
Gerçek insanlara hizmet verecekseniz gözlemlenebilir her şeyin 1 saniyenin altında gerçekleşmesi gerekir; bundan sonra kullanıcıların sistemin bozulduğunu düşünüp sekmeyi kapatma oranı hızla artar.
Eskiden bir bahis borsasının işletimine yardım etmiştim; trafik aşırı sıçramalıydı, gecikme gereksinimleri sıkıydı ve işlem hacmi tüm etkinlik penceresinin çok küçük bir bölümünde yoğunlaşıyordu. Canlı işlemlerde sonuç, kullanıcının eylemi başlattığı andan itibaren 100ms içinde ekranda görünmeliydi; ağ round-trip gecikmesi de etkinlik işleme bütçesini kemiriyordu.
Referans: https://www.nngroup.com/articles/response-times-3-important-...
Böyle bir yük büyük tek sunuculu kurulumla da kaldırılabilir, ama artık basit bir web sunucusu değil; içinde web sunucusu olan epey güçlü bir frontend load balancer yapmış olursunuz.
AWS pahalı ücretlendirse de load balancer ve ağ altyapısına muazzam mühendislik koyuyor; bu sayede geri kalanımız o stack alanının tamamında uzman olmak zorunda kalmıyor.
Gerçekten dünya çapında erişilebilirlik gerektiren kaç servis var? Birden çok dil desteğini de birlikte mi yaptınız?
ABD ya da AB içinde hizmet veriyorsanız, iyi bir merkezi sunucuyla o bölgenin tamamına 30ms altında gecikme sunabilirsiniz.
Gerçekten global bir gereksiniminiz ve yönetmeniz gereken global bir veritabanınız yoksa edge biraz abartılıyor.
500 Internal Server Errorçıktığına göre yazar 11MB/s’den fazla trafik alıyor gibi. Arşiv kopyası burada: https://archive.is/UVpg0PR_END_OF_FILE_ERROR’ı ilk kez gördüm. Birçok web sitesi bunun proxy, VPN, DNS-over-HTTPS yüzünden oluştuğunu söylüyor, ama benim durumumda bunlar geçerli değil.Bu yazı bence konuya yanlış açıdan bakıyor.
Daha iyi yaklaşım çok erken ölçekleme yapma demek.
İhtiyacın kadarını kurarsın; çoğu durumda CDN bile gereksiz bir maliyettir. Tabii bulut sağlayıcısının aşırı bant genişliği vergisini ödemediğin varsayımıyla.
Performans sorunları görünmeye başladığında o zaman ele alırsın; sıradan bir iş atı birden herkesin istediği unicorn’a dönüşürse, bu sahip olmak isteyeceğin türden bir problemdir.
Ürün iyiyse kullanıcı bir saat sonra tekrar dener, doğrudan rakibe geçmez. Ölçeklenebilirlik sorunu çıkarsa yalnızca kaynak yoğun kısımları ölçeklenebilir bir hibrit modele taşırız.
Yine de baştan web-scale, onlarca mikroservis, aralarında patlayan arıza durumları ve ilk müşteri gelmeden AWS faturasıyla VC parasını yakmak istiyorsanız, keyfiniz bilir.
Fiziksel sunucuyu kendim işletmek daha sonrası için bir konu, şu anın konusu değil. 1 milyon dolarlık AWS faturası ile iri bir tek sunucu arasında seçim yapmam gereken noktaya geldiğimde, bir blog yazısına bakıp karar vermiyor, kendi testlerimi çalıştırıyor olacağım.
AWS kullanınca beraberinde bir günah keçisi de satın almış oluyorsunuz. Büyük bir bulut servis kesintisini patronlara ya da yatırımcılara açıklamak kolaydır; aynı kümülatif kesintinin ekipteki bir insan hatasından kaynaklandığını açıklamak ise çok daha zordur.
O halde bunun bulutun günah keçisi olduğu yorumuyla nasıl örtüştüğünü merak ediyorum.
Dikey ölçeklemeyi hedefliyorsanız neden SQLite? Aynı sunucuda uygulamayla birlikte kendi barındırdığınız Postgres ya da Supabase çalıştırmanızı engelleyen bir şey yok; kurulum için daha fazla çaba gerektirmesi dışında akla pek bir dezavantaj gelmiyor
Veritabanı kullanmadan gidip tüm küresel durumu tek bir büyük sunucunun gerçek belleğinde tutar, Redis'e gidip gelmeden süreç içi nesneler olarak saklar, ara sıra belleği diske anlık görüntü olarak yazar ve derlenen çok iş parçacıklı bir dil kullanırsanız, 1 Gbit'ten büyük bir NIC'i doyurarak tek bir makineden tüm dünyaya hizmet verebilirsiniz
Böyle bir mimarinin kullanılabileceği gerçek bir örnek olsa güzel olurdu diye de düşünüyorum
Standart ilişkisel kalıcılık kalıplarının dışında özellik farkları büyük olduğundan Postgres daha iyi olabilir, ancak bazı mimari kalıplarda SQLite öne geçebilir
BusinessInsider gibi içerik odaklı uygulamalarda SQLite tabanlı Baked Data kalıbı maliyet ve gecikme açısından daha iyi olabilir
simonw(datasette), içerik odaklı veya veri açısından zengin web sitelerinde SQLite'ı üretim ortamında kullanmaya yönelik birçok araç ve yazı üretti: https://simonwillison.net/2021/Jul/28/baked-data/
SQLite süreç içinde çalışıyor ve serileştirme gerektirmiyor, bu da mantıklı. Ayrıca işlemleri seri şekilde işleyebilme gibi ek bir avantajı var; bu da test etmeyi, akıl yürütmeyi ve önbellek katmanı kurmayı çok daha kolaylaştırıyor
Unix soketi kullanmazsanız ağ ek yükü de var, ama aynı sunucu denildiği için bunu ek bir not olarak bırakıyorum. Pratikte yalıtım için Postgres'i başka bir makineye koymak çok yaygın ve bu da ağ üzerinden çalışan veritabanlarının başlıca avantajlarından biri
Gerekli özelliklerin hepsi var; sadelik ve hız da daha iyi. SQLite terabayt ölçeğinde veriyi, birden fazla okumayı, gerçek zamanlı akış yedeklemelerini kaldırabilir ve genel olarak oldukça dengeli bir SQL uygulamasıdır
Postgres/MySQL'i ancak tek kutuda dikey ölçeklemenin ötesine geçildiğinde düşünürdüm
https://blog.cloudflare.com/introducing-d1
Görünüşe göre birçok kişi, yazar gecikme, bant genişliği ve maliyete odaklanınca, mevcut durumu kullanılabilirlik ve güvenilirlik gerekçesiyle savunmak zorunda hissediyor
Benim vardığım sonuç, ödünleşimler karşısında bulutun avantajlarını reddetmek değil; artık her yerde karşımıza çıkan bulut mimarisi kalıplarının ve bunların getirdiği bağımlılıkların gerçekten zorunlu olup olmadığını sorgulamak yönünde
Şu ve bu karşıtlığı, alternatifleri tanıtmak için kullanılan retorik bir araç; hangi çözümün doğru olduğu ise kullanım amacına göre sayısız etkene bağlı. Zaten mühendislerin iş bulmasını sağlayan da tam olarak bu etkenler
Yine de yazarın önerdiği kalıp içinde bile SRE kaygıları giderilebilir. “Tek bir sunucu ölürse kullanılabilirlik ne olacak?” sorusu, alışık olduğumuz sistemlerden farklı bir şekilde kullanılabilirliğin çözülebileceği gerçeğini ıskaladığı için saman adam argümanına yakın; çözüm, gerçekten önemli olana göre şekillenmeli
Tutumlu bir bütçeyle yalnızca bir katman daha ekleyerek çok daha fazlasını elde etmenin bir yolu var: API ile SQLite DB'yi yan yana koymak
İdeal olarak API, ek yükü düşük ikili serileştirme biçimi ve kalıcı bağlantılar kullanır; web sunumu için de para yakan VC destekli uç servislerin ücretsiz katmanından yararlanılır. Şu anda Cloudflare Workers oldukça cömert ve çıkış trafiği de ücretsiz
Esas nokta, SQLite'ın tek iş parçacığında bile saniyede muazzam sayıda sorguyu işleyebilmesi. Birçok işlemi seri olarak içeri itebildiğiniz için akıl yürütmek kolaylaşıyor; API tarafındaki bellek önbelleklemesi ve geçersiz kılma da basitleşiyor
Web sunumunu ayırırsanız el sıkışmalarında uç performansından yararlanır ve statik sayfalarda DB'yi tamamen atlayabilirsiniz. Yazı gidiş-dönüş süresi sorununu hafife almış; gerçek uygulamalar sanılandan daha fazla gidiş-dönüş gerektirdiği için bu sorun oldukça gerçek
DB dışındaki CPU kullanımının büyük bölümü ayrıştırma, ters serileştirme, veri kopyalama ve TLS'ten gelir; bu yüzden büyük bir parçayı ortadan kaldırırsanız giriş seviyesi makinelerde bile saniyede on binlerce yazmayı kolayca elde edebilirsiniz, okumalar daha da hızlıdır
Yine de tipik darboğazları, özellikle I/O'yu her zaman benchmark etmekte fayda var. Sağlayıcılar çoğu zaman abartılı ya da yanıltıcı olabilir; bu yüzden ücretsiz katmanda kendiniz denemelisiniz. Geçiş yapmanız gereken zamana karşı entegrasyon testleri ve benchmark'ları da hazır bulundurmak iyi olur
Sonuç büyükse oldukça iyi, ama PostgreSQL'in kendisinin büyük veri kümelerini JSON'a dönüştürme sürecinde darboğaza takılmamasını umuyorum
İnsanlar edge’de olunması, kullanıcıya yakın olunması ve gecikmenin azaltılması gerektiğini söylüyor
Peki gecikme gerçekten ne kadar büyük bir sorun?
Almanya’daki bir sunucuda çalışan kitap öneri projesi Gnooks buna örnek: https://www.gnooks.com
Birilerine fazla yavaş gelip gelmediğini merak ediyorum
Son birkaç yılda bu proje için kullanıcılardan binlerce öneri aldım; hatırladığım kadarıyla gecikmeyi konu eden kimse olmadı. En büyük kullanıcı grubu ABD’de olmasına rağmen durum böyleydi
Bu yüzden, mantığın çoğunu frontend’de uygulayıp gerekli verileri almak için backend’e birden fazla sorgu gönderen günümüz tarzı PWA’lara kıyasla gecikme sorunundan çok daha az etkileniyor
Yine de sitenin kendisi fena değil. Zaten yavaş bir siteyse sorun o zaman ortaya çıkıyor
Bunu Avrupa’dan yaparsanız, Avustralyalı bir kullanıcının gördüğü gecikmenin yaklaşık 2 katını yaşarsınız; en kötü deneyimi kestirmek için işe yarar
İyi tarafı şu: Bunu güvenilir biçimde test edip gerçekten önemli olup olmadığını görebilirsiniz. Böylece somut bir yanıt elde edilir
Yazı erişilebilirlik konusunu hiç ele almıyor. Tek bir kutuda çalışan hizmetlerde hem planlı hem de beklenmedik kesintiler olur
RPO/RTO’yu da düşünmek gerekir. Kutu patladığında, daha doğrusu patlarsa, toparlanmanın ne kadar süreceğine ve ne kadar veri kaybedileceğine bakmak gerekir
Sayfa render etmede tek bir veritabanı sorgusu bile varsa us-east-1’deki DB’ye dönmek gerekir cümlesi için şu seçenekler de var:
https://aws.amazon.com/rds/aurora/global-database/
https://aws.amazon.com/dynamodb/global-tables/
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
Benzerleri daha da çok; aynısını kendiniz yamalı bohça gibi kurmaya çalışırsanız epey uğraşırsınız
10–20 yıl önce olsa katılırdım. İnternet yeniydi; site çökerse insanlar siteyi suçlardı ve işler hızla çirkinleşirdi. Ama bugün önce internet sağlayıcılarını suçlamaları ya da sonra tekrar denemeleri daha olası
Herkes Google değil; daha basit sistemlerin zaten arızalanma olasılığı da daha düşük. Yedekleri tutun, gerçekten kaygılıysanız DB’yi soğuk bir felaket kurtarma sitesine replike edin. FAANG olmayan çoğu şirket ve durum için bu yeterli
Veri kaybedilmediği sürece, birçok şirket için bu kısa bir kesintiyle sınırlı kalır. İletişim iyi yapılırsa ve çok nadir bir olaysa birkaç günlük kesinti bile kaldırılabilir; bazı durumlarda veri kaybı da tolere edilebilir
Güvenilirliğe eklenen her bir 9’un maliyeti ikiye katladığı söylenirdi; ROI hesaplarken bu mutlaka dikkate alınmalı. Bir işletmenin gerçekte ne kadar güvenilirliğe ihtiyaç duyduğu hedef pazara bağlıdır; IT’nin varsayılan cevabı olan otomatik %100 bence yanlıştır
Tek sunuculu ya da çift sunuculu modelin karmaşıklığı da çok daha düşüktür; bu yüzden LetsEncrypt gibi operasyon ekipleri de küresel hizmetleri web ölçeğinde çalıştırmak için bu çift fiziksel sunucu mimarisini seçiyor: https://letsencrypt.org/2021/01/21/next-gen-database-servers...
Sunucu içindeki DB’nin ya da hemen yanındaki DB’nin çok düşük iç gecikmesi sayesinde yazılım DB sorgularını birkaç mertebe daha hızlı çalıştırabilir, kullanıcı başına daha az kaynak tüketir ve gerçek yönetilen DB hizmetlerine kıyasla daha çevik bir kullanıcı deneyimi sunabilir
Karmaşıklık kendi tuzaklarını yaratır ve bunu hiç berbat etmemiş bir web servisi olduğunu sanmıyorum. AWS’in kendisinin de olay çıkardığı oluyor
VPS’nin burada daha kötü olduğunu söylemek mümkün değil