Tek Bir Büyük Sunucu Kullanın (2022)

• Tartışmanın özü monolitik mi mikroservis mi değil, dağıtık sistemlerin geliştirme/işletim ek yüküne değecek kadar değer üretip üretmediği sorusudur
• Modern bir tekil sunucu; onlarca ila yüzlerce çekirdek, TB düzeyinde bellek, onlarca ila yüzlerce Gbps I/O ile çoğu web hizmetini kaldıracak yeterli performans payına sahiptir
• Gerçek benchmark'lar, tek bir sunucuyla Nginx 500 bin RPS, PostgreSQL 70 bin IOPS, NoSQL 1 milyon IOPS, 4K kodlama 75 FPS gibi yüksek performanslı işleme yapılabildiğini gösterir
• Cloud kullanmak kolaylık ve erişilebilirliği artırır, ancak maliyet primi yüksektir; yatırımın karşılığını dikkatle değerlendirmek gerekir
• Yalnızca kullanım örüntüsü aşırı derecede dalgalı olduğunda cloud-native ve serverless mimariler maliyet açısından avantaj sağlar
• Ancak serverless/mikro VM yapılandırmalarının maliyet primi büyüktür; iş yükü sürekli/öngörülebilir ise dikey ölçekleme daha ekonomiktir
• Erişilebilirlik, birincil/ikincil (veya 2×2) yedeklilik ve farklı donanım kombinasyonları ile büyük ölçüde çözülebilir; yalnızca CDN ve yedeği dağıtık olarak satın alma stratejisi makuldür

---

Genel Bakış: Dağıtık sistemler yerine “tek bir büyük sunucu”nun değeri

• “Monolitik vs. mikroservis” tartışmasının özü, dağıtık sistem benimsemenin gerektirdiği gerçek geliştirici zamanı ve maliyetinin buna değip değmediğidir
• Modern yazılımlar sunucu sanallaştırması ve çeşitli soyutlama katmanları üzerinde çalışır; “serverless” ya da “bare metal” de sonuçta fiziksel sunucu kaynakları üzerine kuruludur
• Günümüz sunucuları, düşündüğümüzden daha fazla performans/maliyet verimliliği sunar
  • Geçmişe kıyasla sunucu özellikleri çekirdek sayısı, bellek bant genişliği, PCIe hattı ve NVMe depolama açısından sıçrama yapmıştır; birçok hizmet dağıtık yapı olmadan da hedef QPS düzeyine ulaşabilir

Sunucu donanımının güçlü performansı

• Microsoft Azure'un örnek sunucusu, toplam 128 çekirdek 256 thread yapılandırmasına sahip iki adet AMD 3. nesil sunucu CPU içerir
• Tek bir sunucuda 4 TFLOPs düzeyinde hesaplama performansı elde edilebilir; bu, 2000'lerin başındaki süper bilgisayarları aşar
• Soket başına 16 yuvalı DDR4-3200 RAM yerleşimi ile en fazla 8 TB bellek ölçeklenebilirliği sağlanır; pratik satın alma seçeneklerinde de 1 TB bellek desteklenir
• Toplam 128 adet PCIe Gen4 hattı, 30 NVMe SSD ve 50~100Gbps ağ kartı ile yüksek performanslı depolama ve ağ bağlantısı mümkündür

Böyle tek bir sunucuyla yapılabilecekler (benchmark alıntıları)

• 400–800 Gbps video aktarımı, NoSQL 1 milyon IOPS, PostgreSQL 70 bin IOPS, Nginx 500 bin RPS mümkündür
• Linux kernel'i 20 saniyede derleme, x264 4K 75FPS kodlama gibi CPU, bellek ve I/O yoğun işlerde de yüksek çıktı alınır

Sunucu kiralama/satın alma maliyeti karşılaştırması

• OVHCloud: 128 çekirdek/512GB RAM sunucu aylık yaklaşık $1,318'e kiralanabilir
• Hetzner: 32 çekirdek/128GB RAM sunucuyu aylık €140'a sunar; boyuta göre fiyat aralığı değişir
• AWS m6a.metal: 96 fiziksel çekirdek/768GB RAM sunucu saatlik $8.29, aylık yaklaşık $6,055'tir; yani cloud primi yüksektir
• Dell'den benzer özellikte sunucuyu doğrudan satın almak yaklaşık $40,000'dır; cloud'a kıyasla yatırım geri dönüşü yaklaşık 8 ayda mümkündür
• Aynı throughput serverless ile varsayıldığında, maliyet priminin instance'lara göre 5.5 kat, düşük maliyetli hosting'e göre 25 kat olduğu tahmin edilir

Dağıtık sistemler neden öne çıktı

• Geçmişte (2010 civarı), CPU, bellek ve depolama performansı sınırlı olduğu için büyük ölçekli hizmetlerde birden fazla sunucunun birleşimi gerekirdi
• Son yıllarda büyük tekil sunucular, NVMe SSD'ler ve yüksek bellek bant genişliği sayesinde tek düğümün işleme sınırı ciddi biçimde yükseldi; ancak VM ve container birimleri hâlâ küçük sunucu kaynakları temel alınarak tasarlanıyor

Tek bir büyük sunucunun yeterli olduğu durumlar

• 10k QPS altındaki çoğu web hizmeti için tek bir makine yeterlidir; basit hizmetler milyon QPS düzeyine kadar çıkabilir
• Video streaming'de bile control plane için tek bir sunucu gerçekçidir; benchmark'lar ve ortak performans tablolarıyla uygun sunucu boyutu hesaplanabilir
• Özel durumlar dışında, yalnızca ana sunucu ve yedek sunucu kurulumu ile erişilebilirlik sağlamak da yeterlidir

“Yatay” değil “dikey”: büyük sunucu sayısı az, küçük sunucu sayısı çok olmasın

• Cluster gerekse bile birkaç büyük sunucu, çok sayıda küçük sunucuya göre orkestrasyon ek yükünü (O(n)) azaltır
  • Yani uzun vadede sunucu sayısını azaltıp özelliklerini büyütmek daha verimlidir
• Serverless ve kısa ömürlü container temelli yapılarda ek yük oranı özellikle daha yüksektir
• Dezavantaj tek hata noktası olmasıdır, ancak birincil/ikincil (farklı DC'lerde) kurulumla bu büyük ölçüde giderilebilir
• Daha sağlam bir yapı için 2×2 kurulum (birincil DC'de 2, ikincil DC'de 2 sunucu) ve farklı donanım/üretim partileri ile ilişkili arıza riski azaltılabilir
• Kiralama durumunda sunucu modeli çeşitlendirmesi ile aynı parti disk/SSD kaynaklı zincirleme arıza riski düşürülebilir

Cloud kullanımının avantajları ve sınırları

• Cloud'un güçlü yanları erişilebilirlik, kurtarma hızı ve operasyonel kolaylıktır; bunun için prim maliyet ödemek anlamlı olabilir
  • Kesinti olmadan, bütçe dahilinde hızlı yeniden başlatma mümkündür; grid olarak yönetilen büyük kaynak havuzlarından yararlanılabilir
  • Kiralık sunucu sağlayıcıları daha ucuzdur, ancak kalite, ağ ve premium destek açısından sınırlamaları olabilir
• Ancak cloud satış yaklaşımı auto-scale VM, serverless, managed HA DB gibi vendor lock-in yaratan mimarileri teşvik eder; bu yüzden maliyet ve karmaşıklık açısından dikkatli olmak gerekir
• Büyük ölçekli trafiği işlemek tek başına cloud-native'in ana gerekçesi değildir; tek bir büyük sunucu ile de aynı anda milyonlarca kullanıcıya hizmet veren çok sayıda örnek vardır

Tepe yük maliyeti ve bursty yük ölçütü

• Birileri tepe yüke göre kapasite hazırlamak zorundadır; dolayısıyla tepe maliyeti tedarik zincirinin bir yerinde mutlaka faturalandırılır
• Ani ve geçici işler (ör. tek seferlik büyük simülasyonlar) için serverless/auto-scale ekonomiktir; ancak sürekli ve öngörülebilir yükte büyük sunucuyu sabit çalıştırmak daha maliyet verimlidir
• 1 yıllık taahhüt/spot/satış pazarlığı kullanılırsa instance maliyeti daha da düşer, serverless'e kıyasla prim daha da büyür

“Cloud primi”nin nicel değerlendirmesi

• AWS Lambda gibi serverless computing seçeneklerinde, aynı sunucuya kıyasla maliyet primi 5 ila 30 kat olabilir
• Varsayım: Saatlik $8.2944'lık bir sunucu 1k QPS, 768GB RAM sağlıyorsa, aynı throughput'u Lambda ile değiştirmek yaklaşık saatlik $46 ile 5.5 kat prim anlamına gelir
• OVH kiralamasına göre 25 kat prim tahmin edilir; yalnızca %5 kullanım oranı olsa bile düşük maliyetli hosting, serverless'tan daha ekonomiktir
  • Uzun vadeli sözleşmeler, spot instance'lar vb. kullanıldığında prim farkı daha da açılabilir
• QPS değişse bile bellek-zaman dönüşümü üzerinden prim katsayısı benzer kalır; asıl kritik nokta sunucuyu iş yükünün boyutuna göre ölçeklemektir

Yaygın itirazlar ve yanlış anlamalar

• “Cloud kullanırsak sistem operasyon ekibine gerek kalmaz”: Sadece rolün adı Cloud Ops olur; dokümantasyon, değişiklik takibi ve deprecation yönetimi hâlâ gerekir, hatta personel maliyetini artırabilir
• “Cloud'da güvenlik güncellemeleriyle uğraşmaya gerek yok”: Bazı alanlarda yük azalır, ancak bu otomasyonun kolay olduğu bölümlerle sınırlıdır; kütüphane denetimi ve yapılandırma doğrulaması yine gerekir
• “Cloud yüksek erişilebilirlik tasarımı sunduğu için içimiz rahat”: Artan karmaşıklık yeni zayıflıklar yaratır; region veya provider yedekliliği bile ilişkili arızaları tamamen ortadan kaldırmaz
• “Cloud geliştirme hızını artırır”: Başlangıç çevikliği bir avantajdır; yine de maliyet kırılma noktasını izleyip zamanında geçiş yapmak gerekir
• “Bizim trafik çok bursty”: Bu durumda serverless ve auto-scale uygundur
• “Peki CDN?”: Gecikme ve bant genişliği tasarrufu için mutlaka dağıtık olarak satın alınması gereken bir bileşendir; yedekleme de benzer şekilde satın alınıp kullanılan bir alandır

Monolitik vs. mikroservis ve sunucu yapısı

• “Büyük sunucu” çoğu zaman monolitik mimari ile ilişkilendirilir, ancak tek bir sunucu üzerinde birden fazla container olarak mikroservis kurmak da mümkündür
  • Ancak süreçler arası iletişim, deployment ve gözlemlenebilirlik ek yükü, tek host üzerinde bile maliyet yaratır; bu yüzden karmaşıklığa kıyasla gerçek performans kazanımı ciddi biçimde azalır
• Erken aşama ve orta ölçekli yapılarda monolitik veya az sayıda servis, operasyonel sadelik açısından daha avantajlıdır

Sonuç

• Çoğu durumda yatay ölçekleme veya cloud merkezli mimariler yerine dikey ölçeklemeyi, yani tek bir büyük sunucuyu tercih etmek daha basit ve daha ekonomiktir
• Birincil/ikincil yedeklilik, farklı donanım kullanımı ve CDN/yedek dışsallaştırması birlikte kullanıldığında pratik güvenilirlik sağlanabilir; sürekli yük ortamlarında toplam sahip olma maliyeti (TCO) açısından üstünlük büyüktür
• Sağlam bir donanım yedekliliği stratejisi kurulduğu sürece, “tek bir büyük sunucu” yaklaşımı gerçek hizmetler için son derece uygun bir seçimdir

[GN⁺]

Hacker News yorumu

• Cloud Tax’ın en büyük sorunlarından biri, mühendislerin düşünebileceği çözüm alanını yapay olarak sınırlaması. Örneğin AWS’ye ayda yaklaşık $200 ödediğinizde 4 vCPU ve 16GB RAM’li bir sunucu alıyorsunuz; bu da yaklaşık 5 yıl önceki bir geliştirme dizüstü bilgisayarının seviyesi. Buna karşılık Hetzner’da aynı paraya 48 çekirdekli, 128GB RAM’li bir sunucu kiralayabiliyorsunuz. Hesaplama gücü farkı devasa. Elinizde 10 kat daha büyük kapasite varsa yeterince etkili olabilecek yöntemler, küçük nodlarda anlamsız hale geliyor. Bu koşullar bazen daha karmaşık sistemler kurmak için harcanacak mühendislik zamanından tasarruf ettiriyor. Elbette dayanıklılık gibi başka konular da var ama öte yandan dedicated sunucular, noisy neighbor derdi olmadan tutarlı performans sağlıyor
  • 2025 itibarıyla fly.io gibi hizmetleri genel amaçlı kullanım için rahatça kullanabiliyorsunuz; belirli framework’ler için de Vercel gibi seçenekler var (belli stack’lere odaklanan iyi çözümler). Bundan fazlasına ihtiyaç varsa OVH/Hetzner/Latitude’dan gerçekten canavar makineleri ucuza kiralamak mümkün. Sadece blog çalıştıracaksanız zaten tonla VPS var. Geleneksel cloud artık daha çok regülasyon, şirket içi süreçler ya da verimsizlik için kullanılıyor. Ne geliştirici verimliliği ne de makine başı maliyet açısından sıfır faydası var gibi geliyor. Gerçekten hiçbir kısıtı olmayan bir ekip DMV tarzı onay sistemlerini, gürültülü Intel nodlarını, pahalı marjları ve kötü desteği sevmiyorsa, çoğu durumda anlamı yok
  • Bu bundan da öte — bare metal sunucu kullanınca ağ gecikmesi, VM’lerde bellek bant genişliği gecikmesi/çekişmesi, ayrı caching yapıları gibi şeylere ihtiyaç kalmıyor; örneğin Postgres’e bolca RAM verip sadece Linux disk cache’iyle devam edebiliyorsunuz. Çok daha basit ve hızlı
  • Neden en ufak servis için bile doğrudan AWS kullanmak gerektiğini anlamıyorum. Seninki kadar karmaşık değilim ama bir müşterim küçük bir PHP web uygulaması + AWS sunucusu/SQS/S3 kombinasyonu için ayda $100 ödüyordu. Bunu Python/Django/PostgreSQL ile (başta SQLite idi) yeniden yapıp ayda $25’lık bir VPS’ye taşıdım. PDF OCR, fiyat güncelleme, eksik ürün bulma, site servisi vs. her şey 4 çekirdek 6GB RAM ile gayet iyi çalışıyor. 100 kullanıcıyı çok aşmayacak şirket içi bir uygulama olduğu için, bir gün büyüse bile migration çok kolay. Şu anki ölçekte gerçekten büyük çaplı ölçekleme gerekene kadar AWS’de $100’lık sunucu kullanmak için bir neden yok
  • Kesinlikle katılıyorum. sqlite gibi gömülü bir veritabanı kullanıp yazma işlemlerini (batch) optimize ederseniz Hetzner üzerinde çok ileri gidebilirsiniz. “Fazla kapasite rezerve edip israf etme” argümanı AWS dışına çıktığınız anda anlamını yitiriyor (fiyat/performans farkı uçurum). Hatta sistem ne kadar karmaşıksa, bazı durumlarda tek noddan daha az güvenilir ve daha az dayanıklı bile olabiliyor. Bir şeyin tek başına izole şekilde bozulması pek sık olmuyor
  • Benim düşüncem ise tam tersi. Küçük siteler için Hetzner’ı çok seviyorum ama büyük projelerde cloud neredeyse sınırsız hissettiriyor. Zamanımın değerli olduğu bir projeyse, hosting maliyetinin $200 ya da $2000 olması anlamsız. AWS CDK/Terraform+GitHub Actions ile Docker/K8s/Ansible+CI pipeline geliştirme süresi arasında da öyle ciddi bir fark görmüyorum. Bare metal yaklaşımının mühendislik zamanında çok daha fazla tasarruf sağladığını da düşünmüyorum. Fargate+RDS gibi IaC çözümleri de rahat. Gerçekten dosya depolamayı ayırmanız, ölçeklemeniz, dayanıklı hale getirmeniz gerekiyorsa ya da dinamik subdomain üretimi gibi çeşitli altyapı katmanlarında birçok dedicated servisi entegre edecekseniz, yeni servisleri öğrenip entegre etme yükü çok daha büyük olabiliyor. Aslında cloud öncesi dönemde de bunları yaptım ve gelir üreten projelerde cloud maliyetinin yatırım olarak değerli olduğunu düşünüyorum. Maliyeti kaldıramayacak kadar pahalıysa, o proje muhtemelen işten çok hobidir. RAID ya da çeşitli cluster dosya sistemlerini yönetmek, çoğu startup/şirket kaynağıyla ya da kendi zamanımla uğraşmak isteyeceğim şeyler değil. Bu biraz Arch+Emacs ile uğraşmayı seven zevk ile MacBook’tan memnun olma zevki gibi. Kernel scheduler değiştirmek istiyorsanız Arch derim ama istemiyorsanız MacBook öneririm. Öte yandan gerçekten bütçe yoksa ve raw throughput önemliyse dedicated sunucuların tam isabet olduğu deneyimlerim de oldu (binlerce dolar tasarruf ettirdi). Başarılı olsaydı o noktadan sonra vertical scale yapardık diye düşünüyorum; ama bu nadir bir durum
• HN, yani Hacker News, biri canlı servis için diğeri yedek olmak üzere 2 sunucu işletiyor. Donanım sorunu ya da upgrade ihtiyacı olduğunda anında failover yapabilmek açısından faydalı bir model. Yalnız sunucular tamamen aynı klonsa ikisinin de aynı anda çökebileceğini unutmamak lazım
  • SSD kadar kritik olmasa da AMD CPU’larda da ilginç bir hata vardı. Yaklaşık 1044 gün geçince belirli bir çekirdek tamamen duruyordu AMD EPYC Rome CPU Hang vakası
  • HN’nin downtime istatistikleri var mı merak ediyorum. Son 10 yılda sadece bir iki kez kapandığını hatırlıyorum; hissiyat olarak %99,99’dan yüksek uptime’ı var gibi
• 10 yılı aşkın süredir hibrit colo + public cloud kullanıyorum ve belli bir ölçekten sonra maliyet optimizasyonu açısından hep en iyisi oldu. Donanım verimliliği de sürekli artıyor. Ağ/altyapı yöneticisine ihtiyaç var ama bugünlerde yönetim aslında çok kolay; hatta “cloud” yöneticisi de temelde gerektiği için personel maliyetinde neredeyse hiç tasarruf olmuyor. Colocation seçenekleri çeşitli ve sağlayıcılar bant genişliğini paketli satıyor. Bir dönem 8 adet Dell VRTX cluster, SAN ve 500’den fazla VM çalıştırıyordum (büyük msSQL’den kube’a kadar); public cloud olsaydı reserved indirimlerle bile fatura altı haneli olurdu. Oysa colo maliyeti aylık $2.400’dı (esas olarak güç tüketimi). Public cloud nodlarının bariz yavaşlığı da her zaman şaşırtıcı geliyor (aynı CPU/vCPU nesli olsa bile). Cihaz anlaşmaları, güncellemeler, lisanslar ve destek sözleşmelerini iyi takip etmek gerek ama pratikte gayet yönetilebilir. Ayrıca artık cloud ve networking’i bağlamak da kolay; fiber drop alıp VPC’ye bağladınız mı iş bitiyor
  • Colocation’ı kendi donanımınızı satın alıp veri merkezinden sadece elektrik/rack/hat kiralamak olarak anlıyorum; gerçekten bu mu diye merak ediyorum. Sıradan bare metal sunucu kiralamaya göre ne avantajı var, onu da bilmek isterim
• Bu konuyu yıllardır arkadaşlarımla tartışıyorum. Yerel altyapının en büyük dezavantajı, bunu düzgün işletecek uzman personele ihtiyaç duyması. Bu yazı daha üst ölçeğe odaklanmış ama alt pazarda bile biraz ekipmanınız varsa küçük bir rack ya da ağ kurulumuyla bir yıl içinde başa başa geliyorsunuz. Bugünün cloud primi düşünülünce, bir yönetici istihdam etseniz bile yerel altyapı daha ekonomik olabilir
• Kuruluşunda yer aldığım bir şirkette enterprise otomasyon motoru geliştiriyorduk ve ekip çözümü SaaS olarak sunup geliri maksimize etmek istiyordu. Aslında multi-tenant DB şeması + VPS gayet yeterliydi ama ekip kubernetes öğrenmeye ve cloud-native stack’e fazla odaklandı; 1 yıl boyunca geliştirme ortamı ve operasyon otomasyonuna gömüldü. Sonunda şirket çok yaşamadan battı
  • Ama mühendisler bu deneyim sayesinde k8s tecrübesi kazanıp yeni iş fırsatları bulabildi
  • Benim de benzer deneyimim var — 5 yıl sonra belki gerekecek sorunları bugünden çözmeye çalışırken çok fazla zaman harcadım. Çoğu proje ve erken aşama startup için sadece PaaS ya da nginx+docker container bile yeterli. Gerçek pain point geldiğinde o zaman düşünmek lazım
  • Bu yüzden ben “fatura gerçekten can acıtmaya başlayana kadar” PaaS severim. Heroku/Render/Fly için para verip PMF’ye odaklanmak daha mantıklı. Ya da sunucu merakı uğruna K8s’e yatırım yapıp VC parasını yakar, sonra bir sonraki işe geçip döngüyü tekrar edersiniz
• Pek çok iş o kadar da kritik değil. İnsanlar operasyon durursa ne olacak diye gereğinden fazla stres yapıyor ama gerçekte uğraştıkları servisler o kadar hayati değil. Öğle vakti production ortamı uçsa bile can sıkıcı olur ama dünyanın sonu gelmez. Böyle şirketler, ofisteki basit bir sunucuyla 250 kişiyi rahatça destekleyebilecekken sırf cloud’a geçip bütçeyi şişiriyor. Cloud bazı işler için mükemmel ama geri kalanında pazarlama abartısı gibi. Yine de birçok mühendis “mükemmel ölçeklenebilirlik” fikrine takılıp, yeterince iyi çözüm yerine ideal mimariyi arama eğiliminde
  • Eskiden birlikte çalıştığım bir ekip arkadaşım iş sırasında hep şunu söylerdi: “En azından hata yaparsak kimse ölmeyecek, o yüzden çok da kaygılanmaya gerek yok.” Daha ağır sorumluluk gerektiren işlerde bulunmuş biri olduğu için, zor durumlarda bu bakış açısı çok işe yarıyordu
• %100 uptime hedefiyle karmaşık yapılar kurmaya çalışınca, insan daha az güvenilir sistemler ortaya çıkaran hataları daha sık yapıyor. Çoğu işletme aslında ara sıra 1-2 saatlik kesintiyi ya da veri kaybını tolere edebilir. Bu beklenti en başta netleştirilirse, çok daha basit ve güvenilir yapılarla mühendislik yapmak mümkün
  • Maliyeti de çok daha düşük. Ama bu tür beklentiler mühendislerden ziyade teknik olmayan yöneticiler tarafından çoğu zaman kabul edilmiyor (özellikle veri kaybı neredeyse hiç tolere edilmiyor). Mühendisler “ben sadece ortamı yönetiyorum” diyebilir ama pratikte bu o kadar kolay değil; hata olursa beceriksiz görünme riski var
• Oldukça iyi bir makale. Bu yaklaşımla (cloud dışı) ölçeklenirken CDN eklemeyi de düşünmek mantıklı olabilir. CDN kullanınca WAF ve DNS failover açısından da fayda sağlanır. Yalnız cloud dışı yaklaşımda veritabanını kendiniz işletmek zorunda olmanız biraz can sıkıcı. Bu yüzden cloud DB seçeneği de veren sağlayıcılara bakmak ya da active/passive yapıda passive nodu cloud VM + autoscale ile daha ucuza çalıştırmak iyi bir çözüm olabilir. Bugünlerde sunucu kiralama fiyatları gerçekten düşük; 4GB VPS yaklaşık $6, 32GB quad-core bare metal ise $90 civarında. serversearcher.com gibi fiyat karşılaştırma siteleri faydalı oluyor
  • Postgres’i bir Docker container içinde çalıştırıp düzenli yedek almak benim için gayet sorunsuz oldu. Operasyonu da basit; rahatsız edici bir yanı yok
  • Tek makinede Postgres/MySQL’e göre sqlite ile çok daha yüksek performans ve daha kolay yönetim mümkün
• Ben de servislerimi VPS üzerinde çalıştırıyorum. Cloud’u yıllar önce bıraktım. Projelerim para kazanmaya başlarsa cihaz alıp colo’ya koymayı planlıyorum. Cloud bir flört uygulaması gibiydi; artık eğlencesi bitti, gerçekten üretken bir şey yapmak istiyorum
  • Colo’nun kendisi de sorunlarla dolu. Veri merkezi elektrik kesintileri yüzünden donanımın ölmesi aslında çok yaygın. Hatta paradoksal biçimde evimdeki elektrik daha stabil. Dakikalar süren downtime’ın milyonlarca gelir etkisi yaratmadığı bir iş için çoğu durumda bodrumda sunucu çalıştırmak bile sorun olmaz. İnsanlar 99.999% uptime ya da yüksek bant genişliği ihtiyacını çok abartıyor. Colo da sanıldığı kadar ucuz değil. Veri merkezlerindeki elektrik ücretleri bazen genel ticari ya da konut elektriğinden daha pahalı olabiliyor. Gerçekten ucuz olan şey internet/fiber hat ve artık pek çok ülkede 5–10Gbit business bağlantı 100 euro’ya alınabiliyor (eskiden sadece 1Gbit için bile 2.000 eurodan fazla istenirdi)
• Maliyet ya da kapasite analizinden bağımsız olarak, sektör trendine karşı gitmek kolay değil. “Donanımı hiç düşünmemek” diye gerçek bir avantaj var. Ayrıca capex’ten kaçınılması gerektiğine dair çok güçlü bir düşünce yapısı da mevcut (sunucu donanımı ciddi ön yatırım gerektiriyor). Bir de AWS region çökerse bu “bizim suçumuz” gibi görünmüyor ama şirket içi sunucu giderse “bizim sorumluluğumuz” gibi algılanıyor
  • capex’ten bu kadar kaçınma refleksi neredeyse tamamen VC yatırım yapısının etkisi — yatırımcılar sadece hızlı büyüme istiyorsa, ön yatırım (sunucu satın alma) mantıken savunulamaz hale geliyor. Buna karşılık istikrarlı bir iş modeli her yıl küçük capex’i rahatlıkla kaldırabilir
  • Sunucu donanımını mutlaka satın almak zorunda değilsiniz — Hetzner gibi yerlerden kiralamak da yeterli. “Donanımı düşünmek zorunda olmama” avantajının tam olarak ne anlama geldiğini biraz daha açmanızı isterim
  • capex’ten kaçınma zihniyeti gerçekten var. Bugün hesap makinesi kullanmayı bilen herkes sunucu maliyetinin işin bütünü içinde artık çok büyük anlam taşımadığını görebilir. Asıl pahalı olan şey sunucunun etrafındaki “alan”; çoğu durumda kiralanan şey sunucu değil, alan (rack/elektrik)
  • Şirketlerin aslında para ödediği şey sonuçta “sorumluluğun soyutlanması” oluyor. Büyük şirket yöneticileri MS ya da AWS gibi büyük tedarikçileri seçince içleri rahat ediyor
  • Bare metal sunucu kiralarsanız capex ya da bakım derdiyle uğraşmanız gerekmez