Bare Metal’e Geçişin Üzerinden 2 Yıl: AWS’ten Çıkış Hakkındaki Sorulara Yanıtlar

 (oneuptime.com)
16 puan yazan GN⁺ 2025-10-30 | 3 yorum | WhatsApp'ta paylaş
  • 2 yıl önce AWS’ten Bare Metal’e geçerek yılda 230 bin dolar tasarruf ettikleri deneyimi paylaştıktan sonra, topluluktan gelen çeşitli sorulara verilen takip yanıtlarını derleyen bir rapor 2 yıllık gerçek operasyon verilerini paylaşarak yıllık 1,2 milyon doların üzerinde tasarruf sağladıklarını açıklıyor
  • Gerçek operasyon deneyimiyle tasarruf tutarı yıllık 1,2 milyon doların üzerine çıktı ve bu kaynak, yapay zeka tabanlı olay özeti ile otomatik kod düzeltme için sunucu yatırımlarına yeniden aktarılıp hizmet kalitesinin artmasına katkı sağladı
  • MicroK8s + Ceph yığını temelinde %99,993 erişilebilirlik korundu ve çift veri merkezi yapısı ile tekil hata noktaları ortadan kaldırıldı
  • Gerçek işletme maliyetleri, arıza müdahalesi, donanım ömrü, güvenlik sertifikasyonları, bulut alternatif hizmetleri gibi başlıca konular somut rakamlarla açıklanıyor
  • Sonuç olarak hem istikrar hem maliyet verimliliği arttı; belirli bir ölçeğin üzerindeki sürekli yük sistemlerinde Bare Metal’in daha mantıklı olduğu sonucuna varılıyor

2 yıllık operasyon sonuçlarının özeti

  • 24 ay boyunca MicroK8s + Ceph yığını prodüksiyon ortamında çalıştırılarak %99,993 erişilebilirlik sağlandı
    • Tek bir rack sorununu gidermek için Frankfurt’ta ikinci bir rack eklendi ve Paris’teki ana rack ile DWDM çift bağlantı kuruldu
    • Yerel NVMe ve gürültü kaynaklı parazitlerin kaldırılmasıyla müşteri gecikmesi %19 azaltıldı
  • Tasarruf edilen maliyet, Bare Metal yapay zeka sunucuları satın almaya yeniden yatırıldı; böylece OneUptime’ın LLM tabanlı uyarı özeti ve otomatik kod düzeltme özellikleri genişletildi

Tasarruf etkisi ve maliyet karşılaştırması

  • Başlangıçta öngörülen tasarruf yıllık 230.000 dolardı, ancak bugün bu rakam 1,2 milyon doların üzerine çıktı
    • Bu, AWS’ye kıyasla yaklaşık %76 tasarruf anlamına geliyor
    • Küresel insan kaynağı maliyetleri açısından bu tutar 2 ila 5 mühendisin yıllık maaşına denk geliyor
  • Savings Plans / Reserved Instances uygulansa bile Bare Metal hâlâ daha avantajlı
    • Savings Plans, S3·Egress·Direct Connect maliyetlerine uygulanmıyor
    • EKS control plane maliyeti aylık 1.260 dolar, NAT gateway aylık 600 dolar gibi kalemlerde de tasarruf mümkün değil
    • 7/24 sürekli çalışan (steady) iş yükleri nedeniyle reserved instance verimliliği sınırlı kaldı

Migrasyon ve operasyon maliyetleri

  • İlk migrasyon yaklaşık 1 haftalık mühendislik çalışmasıyla tamamlandı
    • IaC düzenlemeleri, yedekleme politikasının güçlendirilmesi gibi işlerin çoğu zaten önceden gerekliydi
  • Mevcut operasyon maliyetleri şöyle:
    • Doğrudan yönetim: çeyrek başına yaklaşık 24 saat (patch ve firmware güncellemeleri dahil)
    • Remote Hands: 24 ay boyunca yalnızca 2 kez müdahale gerekti (çoğunlukla disk sorunları), ortalama müdahale süresi 27 dakika
    • Otomasyon: PXE boot (Tinkerbell), Talos image yönetimi, Flux/Terraform yapılandırma otomasyonu
  • Operasyon ekibinde, AWS dönemine kıyasla release hızı arttı; ayrıca “maliyet optimizasyonu toplantıları” yükünün de ortadan kalktığı görüldü

Arıza hazırlığı ve erişilebilirlik sağlama

  • Frankfurt’ta ikinci rack eklendi, DWDM çift yol bağlantısı ile tekil hata noktaları kaldırıldı
    • Asenkron replikasyon tabanlı Ceph mirroring ve çift control plane yapısı kuruldu
    • 4G/uydu tabanlı yönetim yolu eklenerek ağ arızalarında uzaktan erişim mümkün hâle getirildi
  • MicroK8s → Talos geçişi sürüyor
  • AWS failover yedek kümesi hâlâ korunuyor ve çeyreklik felaket kurtarma tatbikatları yapılıyor
  • Anycast+BGP tabanlı Ingress ile DNS geçiş gecikmesi de 1 dakikanın altına indirildi
  • 2 yıl boyunca %99,993 erişilebilirlik korundu ve yakın dönemdeki AWS region kesintilerinden de etkilenilmedi

Donanım ve CapEx yönetimi

  • Sunucular 5 yıllık amortisman esasına göre işletiliyor (2×EPYC 9654, 1TB RAM, NVMe yapılandırması)
    • Performans doygunluğa ulaştığında analitik kümesine aktarılıyor, ardından yeni sunucularla değiştiriliyor
    • Elde edilen tasarruf sayesinde her 2 yılda bir %40 yenileme mümkün hâle geldi ve buna rağmen AWS’ye kıyasla yıllık maliyet avantajı sürüyor
  • Supermicro garanti uzatımı + elde 3 yedek sunucu bulunuyor
    • Gerçek ömür 7-8 yıl olsa da hesaplama ihtiyatlı biçimde 5 yıl üzerinden yapılıyor

Yönetilen hizmetlerin yerine koyma mantığı

  • OneUptime’ın ürün felsefesi, kendi kendine barındırılabilme olduğundan aynı yığının korunması gerekiyor
    • Kubernetes·Postgres·Redis·ClickHouse gibi açık yığın tutarlılığı korunuyor
  • Terraform + EKS + RDS → MicroK8s + Argo Rollouts + Ceph şeklinde evrim yaşandı
    • Özel fork olmadan saf açık kaynak kullanılıyor
  • Hâlâ bulut da birlikte kullanılıyor: AWS Glacier (yedekleme), CloudFront (edge caching), yük testi için geçici instance’lar
  • Bulut esneklik odaklı, Bare Metal ise temel sürekli yük odaklı kullanım için uygun

Ağ ve güvenlik

  • 5Gbps (%95 persentil) kapasiteli 2 hat mevcut; AWS egress’e kıyasla 8 kat daha ucuz
  • DDoS koruması Cloudflare’ın öne yerleştirilmesiyle sağlanıyor
  • Ayrı bir 4G/uydu tabanlı yönetim ağı sayesinde arıza sırasında uzaktan erişim mümkün

Uyumluluk ve denetimlere yanıt

  • SOC 2 Type II, ISO 27001 sertifikaları korunuyor
    • Kolokasyon merkezinin Tier III sertifikası·giriş çıkış kayıtları·CCTV verileri kullanılıyor
    • Terraform/Talos yapılandırma logları, değişiklik geçmişi kanıtı olarak kullanılıyor
  • Denetçiler, AWS konsol ekran görüntülerinden daha çok bunlara güvendiklerini belirtti

Bulut alternatiflerinin karşılaştırması

  • Hetzner, OVH, Leaseweb, Equinix Metal, AWS Outposts karşılaştırıldı
    • Hyperscaler tarafında egress maliyetleri hâlâ yüksek
    • Avrupa’daki host sağlayıcıları büyük ölçekli Ceph kümeleri ve SLA gereksinimlerini karşılamakta zorlanıyor
    • Equinix Metal’de CapEx’e kıyasla %25-30 prim bulunuyor
    • Kendi donanımını işletmek, güç yoğunluğu ve yükseltme serbestliği açısından daha avantajlı
  • Sonuç olarak 15kW rack yapısı ve parça yeniden kullanım imkânı sayesinde kolokasyon hem maliyet hem performansta üstün bulundu

Operasyon yükünün (TOIL) ölçümü

  • Haftalık: kernel/firmware patch’leri ve Ceph kontrolü (1 saat)
  • Aylık: Kubernetes control plane canary yükseltmesi (2 saat)
  • Çeyreklik: DR tatbikatı, kapasite planlaması, operatör sözleşmesi gözden geçirmesi (12 saat)
  • Toplamda aylık 14 saat seviyesinde; AWS dönemine benzer olsa da odak “maliyet takibi”nden “operasyon otomasyonu”na kaymış durumda

Bulutun hâlâ geçerli olduğu durumlar

  • İş yükünün ani sıçramalı veya mevsimsel desenli olması
  • Aurora Serverless, Kinesis, Step Functions gibi yönetilen hizmetlere bağımlılığın yüksek olması
  • Kubernetes·Ceph·izleme·olay müdahalesi tarafını doğrudan işletme kapasitesinin bulunmaması
  • Yani erken aşamadaki ya da yükün çok değişken olduğu işler için bulut üstünlüğü hâlâ geçerli

Gelecek planları

  • Colo bütçe tahmini için Terraform modülü ve runbook yayımlanacak
  • Talos tabanlı operasyon deneyimini ele alan derin teknik bir yazı da hazırlanıyor
  • HN·Reddit geri bildirimlerine yanıt verilmeye ve gerçek rakamlara dayalı örnekler paylaşılmaya devam edilecek

İlgili okumalar

3 yorum

 
okxrr 2025-10-30

AWS’ye özgü hiçbir hizmeti hiç kullanmıyoruz ama AWS’yi büyük bir hevesle kullanan bir şirkette çalışıyorum.

Bu kararda bazı liderlerin kariyer geliştirme gibi son derece kişisel hırslarının büyük rol oynadığını görmek, hem komik hem de acı bir hikâye..
 
GN⁺ 2025-10-30
Hacker News görüşleri

  • AWS çok pahalı. Bir sistemi tamamen AWS üzerinde kurmak için sanıldığından daha az neden var. Eskiden herkes bare metal sunucuları bizzat çalıştırmayı bilirdi, ama artık bunu unutmuş gibiler. Bizim ekip 730 günden uzun süredir %99,993 erişilebilirliği korudu ve yakın zamandaki AWS bölge kesintisinden de etkilenmedi. DDoS savunması için Cloudflare kullanıyoruz, ama DNS ya da ingress yönetiminin tam zamanlı bir işe dönüşmesini de anlıyorum. Yine de birkaç mikroservis ve bir veritabanını doğrudan kendiniz çalıştırmanız fazlasıyla mümkün. AWS çoğu şirket için aşırı pahalıya geliyor

    • AWS'nin asıl sorunu çalışanların AWS'ye bağımlı hale gelmesi. AWS sertifikaları alınıyor, AWS Well Architected Framework'e uyma baskısı oluşuyor ve insanlar kendi başlarına düşünmemeye başlıyor. AWS'nin lock-in yaratan servisleri bilerek ucuzmuş gibi fiyatlanıyor, ama sonunda sizi daha da derine bağlıyor. Örneğin PostgreSQL'den DynamoDB'ye geçmek kısa vadede tasarruf gibi görünebilir, ama uzun vadede AWS'ye bağımlılığı artırır
    • On-premise daha ucuz, ama uzman personel bulmak zor. Basit ürünler için iyi bir seçenek, ama karmaşık sistemlerde iş gücü maliyeti ve operasyonel risk daha da büyüyebilir. AWS/Azure/GCP kusursuz değil, ama bugünlerde on-premise uzmanı fazla nadir
    • AWS'yi eleştirince garip şekilde tepki gösteren insanlar çok oluyor. Reddit'te de benzer bir durum var. Sanki birileri AWS'yi savunmak için para alıyormuş gibi hissettiriyor
    • Self-hosting başarı hikâyelerinde doğrulama yanlılığı var. Sunucuları kendin yönetmek başta iyi görünür, ama bir yıl kadar sonra dokümantasyonla gerçek yapılandırma birbirinden kopar ve sorumlu kişi ayrıldığında karmaşa büyür. Sonunda birçok startup yeniden AWS'ye döner. Bu tür başarısızlık hikâyeleri pek paylaşılmaz
    • Bare metal'i iyi işletmek için tecrübeli mühendisler gerekir. Yeni mezunlar ya da danışmanlık şirketi kökenli “bulut uzmanları” ile bu iş zordur

  • İlk dönem bulut, basit ve fiyat/performans açısından iyi servislerle başladı, ama şimdi 200'den fazla karmaşık servis birbirine dolanmış durumda. Yönetilmezse faturalar patlıyor

    • Aslında AWS'nin temel iddiası hiçbir zaman “ucuz” olmak değil, “hızlı ölçeklenebilmek”ti. 2010'ların başında pahalıydı ama esneklik avantajı vardı. Bugün de performansa göre fiyatı hâlâ yüksek. Sunucu yönetiminin temellerini biliyorsanız dedicated server çok daha iyi
    • AWS artık 200'den fazla servisle aşırı genişledi. Temel işlevlere odaklanması gerekiyor
    • AWS konsoluna her girişimde karmaşıklık ve yorgunluk hissi çöküyor. Gereğinden fazla büyümüş
    • AWS servisleri arasında fiyat/performans farkı çok büyük. Özellikle eski çekirdek servislerin bazıları hâlâ değerli

  • AWS'nin gerçek işlevi, (1) organizasyonun ölçeklenmesini ve güç yapılarının kurulmasını sağlamak, (2) muhasebede CapEx yerine OpEx yazabilmek, (3) beceriksiz personel yapısını gizlemek. Eskiden 5-10 kişiyle bir veri merkezi işletilebilirdi, şimdi ise 3000 kişilik DevOps organizasyonları ortaya çıkıyor

    • OpEx ile CapEx farkının neden bu kadar önemli olduğunu anlamıyorum. Sonuçta para paradır, değil mi?
    • Bulut erken aşama startup'lar için faydalı. Kapasite planlama derdi olmadan hızlı büyüyebilirler. Ama büyüme oranı düşük bir şirket bulutta kalmaya devam ederse bu verimsiz olur
    • On-premise çok fazla özelleştirildiği için personel değişimi zorlaşır. Buna karşılık AWS bilen insanı her yerde bulabilirsiniz
    • Tecrübeli sistem yöneticileri gerçekten zor bulunuyor ve pahalı. Ucuza kaçmaya çalışıp iki yıldır yedekleme yapılmayan durumlar bile gördüm

  • Bu başarının anahtarı 7/24 sabit yük olması. Çoğu şirketin deseni de aslında buna benziyor

    • Aslında başlangıçta tek rack, tek veri merkezi ile yola çıkmış olmaları bir bakıma şanstı. Çünkü güvenilirlik maliyetini en baştan ödemediler
    • İlgili yazı: One Big Server
    • AWS sık sık “stok yok” diyerek reserved instance almaya zorluyor. Sonunda bu da sürekli çalışan altyapının maliyetine yaklaşıyor
    • Hetzner gibi sağlayıcılar AWS'ye kıyasla aynı performansı 10 kat daha ucuza sunabiliyor. Bulutun “esnekliği” çoğu zaman abartılmış bir efsane

  • Asıl mesele esneklik ile taban yük arasındaki fark. Veri toplama gibi trafiğin patlayarak geldiği durumlarda bulut avantajlı. Çoğu durumda ise bare metal daha iyi

  • 2010'larda donanım ve ağlar yavaştı, ama bugün CPU performansı ve verimliliği yüzlerce kat arttı. Eskiden 64 sunucunun yaptığı işi şimdi 1 sunucu yapabiliyor. Gelecekte bu oran 100:1'e kadar çıkabilir. Böyle bir ortamda bulutun avantajı giderek azalıyor

  • Bir Amazon çalışanı olarak bakınca, Kubernetes'i kendi başına yönetmek fazla riskli. etcd gibi bileşenler kırılgan ve onları elle yamamak zorunda kaldığımız bile oldu. Yazıdaki self-hosting yaklaşımında riskler olduğundan az gösteriliyor

    • Diğer hyperscaler'larda da Kubernetes yönetimindeki başarısızlıklar büyük kesintilere yol açtı. Microk8s gibi tek rack için sade alternatifler daha iyi olabilir. İlgili yazı: Microk8s 6 Months Later
    • Karmaşık ortamlar her yerde zordur ve sonuçta uzman gerekir. AWS de bu açıdan kolay değil. Bulutta kesinti yaşansa da dünya dönmeye devam ediyor
    • k3 gibi hafif sürümler çok daha basit
    • Kubernetes yalnızca gerektiğinde kullanılmalı. Varsayılan tercih olarak kullanmak zaman ve para israfı

  • Birçok startup, AWS faturaları bu kadar pahalı olsaydı muhtemelen hiç var olamazdı. Örneğin GeoIP ücretsiz indirmeleri (bağlantı) gibi bir şey mümkün olmazdı. Bulut yavaş ve disk gecikmesiyle CPU aşırı paylaşımı ciddi boyutta. Aylık 10 bin doların altında kabul edilebilir, ama onun üstünde bare metal çok daha verimli

    • Bulutun yavaş performansına alışınca garip bir uyum hali oluşuyor. Karşılaştırmayı her zaman bare metal'i temel alarak yapmak gerekir

  • Çalıştığım şirketin trafiği de düşüktü ama yine de AWS'ye geçmek istiyordu. Nedeni basitti — özgeçmişe AWS eklemek istiyorlardı. Sadece geliştiriciler değil, yöneticiler de böyleydi. “AWS migration lead” unvanı kariyerde iyi göründüğü için. Sonunda şirket satıldı ve ofis boş kaldı. Belki de şimdi yeni kariyer puanı “AWS'den çıktık” demek olur

    • Geliştiriciler AWS isterse, bir sonraki nesil sadece AWS'yi bilir hale geliyor. Tartışma da doğal olarak taraflılaşıyor
    • Sonuçta karar liderliğin iradesine bağlı

  • Sonuçta önemli olan ne yapmaya çalıştığınız

    • İç kullanıma yönelik, veri odaklı bir web sitesi ise tek bir sunucu rack'i yeterli olabilir
    • Düzensiz, cache'lenemeyen büyük ölçekli trafik varsa bulut avantajlıdır
    • DNS ya da ingress karmaşıksa hibrit yaklaşım daha iyidir
    • Veri ölçeği büyüdükçe bulutun uzun vadeli amortisman yapısı daha avantajlı hale gelir