AWS faturanız geldi. Ona alışık olduğunuzdan biraz daha uzun süre baktınız. Ardından, konusuz bir şekilde CTO'nuzla paylaştınız. O zaten biliyordu.
AWS, Azure veya GCP üzerinde ölçekli üretim iş yükleri çalıştırıyorsanız ve aylık harcamalarınız birim ekonominizi gerçekten etkileyen bir eşiği aştıysa, her şeyinizi orada dağıtmanın hâlâ doğru olup olmadığını sorgulayan tek kişi olmadığınızı söyleyebiliriz. Artan sayıda mühendislik ekibi, bu soruya başka bir Reserved Instance satın alma turu yerine bir geçiş planı ile yanıt veriyor.
Bu kılavuz, bu kararın uygulama tarafını kapsar: neye sahip olduğunuzu denetleme, savunulabilir bir iş vakası oluşturma, doğru bare-metal konfigürasyonunu seçme, iş yüklerini üretimi bozmadan taşıma, geçiş sırasında ağ boşluğunu köprüleme ve yeni ortamınızı sağlamlaştırma. Henüz taşınıp taşınmayacağınıza karar veriyorsanız, bu ayrı bir konuşma. Taşınmaya karar verdiyseniz, okumaya devam edin.
Anahtar Çıkarımlar
- 2026'da bulut repatriasyonu, düz hiperscaler fiyatlandırması, düşen donanım maliyetleri ve Broadcom'un VMware lisanslama değişiklikleri nedeniyle hızlanıyor.
- Sürekli olarak yüksek, öngörülebilir kullanımda çalışan iş yükleri, genellikle bulut harcamalarında aylık yaklaşık 15.000-25.000 $ üzerinde bare metal üzerinde her zaman daha az maliyetlidir.
- Güvenli bir geçiş beş aşamayı izler: sağlama, veritabanı geçişi, paralel uygulama dağıtımı, kademeli trafik kaydırma ve ardından 30 günlük gözlem penceresinden sonra bulutun devre dışı bırakılması.
- Bare metal üzerinde güvenlik yığınının daha fazlasına sahipsiniz. Güvenlik duvarı kuralları, izinsiz giriş tespiti, yedekleme RPO/RTO ve donanım izleme, üretim trafiği gelmeden önce açık bir şekilde kurulmalıdır.
- Repatriasyon, her şey ya da hiçbir şey olmak zorunda değildir. Kararlı iş yükleri için özel altyapı ve gerçek esneklik için daha küçük bir bulut ayak izi ile hibrit bir model, rasyonel bir uzun vadeli stratejidir.
İçindekiler
- Bulut Repatriasyon Dalgası: 2026'da İşletmeler Neden Hiperscaler'ları Terk Ediyor
- Hangi İş Yükleri Bare Metal İçin Daha Uygun (ve Hangileri Genel Bulutta Kalmalı)
- Sahip Olma Maliyeti: Bulut Repatriasyonu İçin İş Vakası Oluşturma
- Ön Geçiş Denetimi: Bağımlılıkları, Gecikme Gereksinimlerini ve Uyumluluk Kısıtlarını Haritalama
- İş Yükünüz İçin Doğru Bare-Metal Sunucu Konfigürasyonunu Seçme
- Geçiş Mimarisi: Lift-and-Shift vs. Re-Platform vs. Re-Architect
- Geçiş Sırasında Genel Bulut ve Bare Metal Arasında Ağ Boşluğunu Köprüleme
- Geçiş Sonrası Güçlendirme: Özel Donanımda Güvenlik, Yedeklemeler ve İzleme
- Yaygın Repatriasyon Hatalarından Kaçınma (ve Gerektiğinde Buluta Geri Dönme)
Bulut Repatriasyon Dalgası: 2026'da İşletmeler Neden Hiperscaler'ları Terk Ediyor
Repatriasyon trendi gerçek ve hızlanıyor. OpenMetal'den araştırma, işletmelerin iş yüklerini hiperscaler'lardan çekip özel veya ayrılmış altyapıya yerleştirdiği ölçülebilir bir değişime işaret ediyor. Bare-metal bulut pazarı, yüzde 17 ila 25 bileşik yıllık büyüme oranı ile büyüyor, bu da bunun marjinal bir hareket olmadığını gösteriyor.
Bu anı üretmek için birkaç güç birleşti. Hiperscaler fiyatlandırması yıllardır anlamlı bir şekilde düşmedi, oysa yüksek yoğunluklu özel donanım maliyeti keskin bir şekilde düştü. Broadcom'un VMware'i satın almasının ardından gelen lisanslama değişiklikleri, binlerce kuruluşu tüm sanallaştırma yığınlarını yeniden değerlendirmeye itti ve tam bir altyapı incelemesini bir sapma değil, gerekli bir durak haline getirdi. Aynı zamanda, AI ve GPU iş yükleri, genel bulut fiyatlandırmasının özellikle kötü bir şekilde ele aldığı yeni bir hesaplama talebi sınıfı yarattı: talep üzerine veya hatta Reserved fiyatlandırmasının, özel donanımın maliyetini aşan faturalar ürettiği uzun süreli, yüksek kullanım iş yükleri.
Bu, genel bulutun her iş yükü için yanlış olduğu anlamına gelmez. Bu, her şeyin bir hiperscaler'a ait olduğu varsayımının, eskisinden daha fazla incelemeyi hak ettiği anlamına gelir.
Hangi İş Yükleri Bare Metal İçin Daha Uygun (ve Hangileri Genel Bulutta Kalmalı)
Her şey taşınmamalı. Bunu yanlış yapmak her iki yönde de pahalıdır.
Bare metal üzerinde yer alması gereken iş yükleri birkaç ortak özelliği paylaşma eğilimindedir: sürekli olarak yüksek kullanımda çalışırlar, gürültülü komşu etkilerine duyarlıdırlar, öngörülebilir kaynak gereksinimlerine sahiptirler ve sıfırdan yüzlerce node'a dakikalar içinde ölçeklenmeye ihtiyaç duymazlar. Veritabanları (özellikle gecikmeye duyarlı OLTP sistemleri), AI eğitim işleri, video kodlama pipeline'ları, yüksek frekanslı ticaret altyapısı ve sabit node sayısına sahip büyük Kubernetes cluster'ları bu profile uyar.
Genel bulutta kalması gereken iş yükleri, gerçekten esnek ölçeklemeye ihtiyaç duyanlardır. Ani, öngörülemeyen talep ile batch işleri. Hızla oluşturup kaldırmak istediğiniz geliştirme ve aşama ortamları. Coğrafi dağıtımın onlarca bölgeye yayılması zorunlu bir gereklilik olan her şey. İhtiyacınız olana kadar hiçbir şey ödemediğiniz felaket kurtarma hedefleri.
Kullanışlı bir zihinsel test: Kaynak tüketiminizi 90 gün öncesinden makul bir güvenle tahmin edebiliyorsanız, bare metal neredeyse kesinlikle daha ucuz olacaktır. Tüketiminiz en yoğun ve en sessiz haftalarınız arasında beş kat değişiyorsa, genel bulutun esnekliği hala ödemeye değer.
Kubernetes çalıştıran ekipler için bu analiz özellikle önemlidir. Zaten K8s bulut faturanızı optimize etme çalışmasını yaptıysanız ve rakamlar hala işe yaramıyorsa, sorun yapılandırma değil, altta yatan hesaplama modelidir.
Sahip Olma Maliyeti: Bulut Repatriasyonu İçin İş Vakası Oluşturma
Çoğu ekibin TCO modeli oluştururken yaptığı hata, yanlış rakamları karşılaştırmaktır. Mevcut bulut faturalarını alır ve yalnızca donanım maliyetiyle karşılaştırırlar. Bu, bulutta kalmanın gerçek maliyetini küçümser ve taşınmanın gerçek maliyetini abartır.
Bare-metal geçişi için eksiksiz bir TCO modeli, donanım amortismanını (genellikle üç ila beş yıl arasında), kolokasyon veya veri merkezi ücretlerini, ağ maliyetlerini, donanım yönetimi için personel maliyetlerini, yazılım lisanslamasını (OS, hipervizör kullanıyorsanız, izleme) ve gücü içerir. Genel bulut için eksiksiz bir TCO modeli, hesaplama, depolama, çıkış ücretleri (ki bunlar önemli ve genellikle hafife alınır), destek planları ve bulut yerel araç karmaşıklığını yönetmek için harcanan mühendislik zamanının maliyetini içerir.
Bu rakamları dürüstçe çalıştırdığınızda, öngörülebilir iş yükleri çalıştıran çoğu orta ölçekli şirket için kesişim noktası, bulut harcamalarında aylık 15.000 ila 25.000 $ arasında bir yere düşer. Bu eşik altında, kendi donanımınızı yönetmenin operasyonel yükü genellikle tasarrufları aşar. Üzerinde, matematik genellikle repatriasyonu tercih eder.
Modelinizi, üç senaryoyla bir elektronik tabloda oluşturun: iyimser (donanım beş yıl dayanır, beklenmedik arızalar yok), baz (dört yıl, bir büyük donanım yenilemesi) ve kötümser (üç yıl, personel maliyetleri projeksiyondan %20 daha yüksek). Üç senaryonun tümü mevcut bulut faturanızı yenerse, savunulabilir bir vakaya sahipsiniz. Sadece iyimser senaryo kazanırsa, karar göründüğünden daha yakındır.
Zaten bir bulut maliyet optimizasyonu egzersizi yapmış ve doğru boyutlandırma ve Reserved Instance'ların yalnızca bu kadar ileriye götürdüğünü görmüş ekipler için, repatriasyon için TCO modeli mantıklı bir sonraki adımdır.
Ön Geçiş Denetimi: Bağımlılıkları, Gecikme Gereksinimlerini ve Uyumluluk Kısıtlarını Haritalama
Tek bir iş yükünü taşımadan önce, sahip olduklarınızın tam bir haritasına ihtiyacınız var. Bu bariz görünüyor. Sürekli olarak hafife alınıyor.
Bir bağımlılık grafiği ile başlayın. Taşımayı düşündüğünüz her hizmet için, çağırdığı diğer hizmetler, okuduğu veritabanları, yazdığı kuyruklar, vurduğu üçüncü taraf API'lar gibi her yukarı ve aşağı bağımlılığı belgeleyin. Gecikmeye duyarlı bağlantılara özellikle dikkat edin. Aynı AWS bölgesinde bulunan beş diğer hizmete senkron çağrılar yapan bir mikro hizmet, bu hizmetlerin bazılarının artık 0.5 milisaniye yerine 40 milisaniye uzakta olması durumunda çok farklı davranacaktır.
Ardından, uyumluluk kısıtlarınızı haritalayın. Ödeme kartı verilerini (PCI DSS), sağlık kayıtlarını (HIPAA) veya GDPR'ye tabi kişisel verileri işliyorsanız, altyapı seçimlerinizin düzenleyici etkileri vardır. Sertifikalı bir veri merkezindeki bare metal kesinlikle bu gereksinimleri karşılayabilir, ancak sözleşme imzalamadan önce sertifikaları doğrulamanız gerekir, sonrasında değil.
Mevcut SLA'larınızı ve bunları destekleyen izlemeyi belgeleyin. Bunu, geçiş sonrası ortamı doğrulamak için temeliniz olarak kullanacaksınız. Ölçemezseniz, koruduğunuzu kanıtlayamazsınız.
Son olarak, patlama yarıçapınızı belirleyin. Bu geçiş yanlış giderse, ne kırılır? Hangi iş yükleri, hataları kurtarılabilir olduğu için ilk taşınacak kadar güvenlidir? Hangileri, her şey için yük taşıyıcı oldukları için son taşınması gerekenlerdir?
İş Yükünüz İçin Doğru Bare-Metal Sunucu Konfigürasyonunu Seçme
Donanım seçimi, birçok repatriasyon projesinin zaman kaybettiği yerdir. Eğilim, en büyük mevcut konfigürasyonu satın almak, çünkü bu güvenli hissettirir. Bu pahalıdır ve genellikle ters etki yapar.
Donanım profilini iş yükü türüne göre eşleştirin:
- CPU tabanlı iş yükleri (web uygulama sunucuları, API geçitleri, derleyiciler): Yüksek çekirdek sayısı, yüksek saat hızı, büyük L3 önbellek. Modern AMD EPYC ve Intel Xeon Scalable işlemciler burada özellikle güçlüdür.
- Bellek tabanlı iş yükleri (Redis veya Memcached gibi bellek içi veritabanları, önbellekleme katmanları, büyük yığınlara sahip JVM tabanlı hizmetler): Ham CPU yerine RAM kapasitesine ve bellek bant genişliğine öncelik verin.
- Depolama tabanlı iş yükleri (ağır I/O ile ilişkisel ve NoSQL veritabanları, günlük pipeline'ları, nesne depolama): Gecikmeye duyarlı okuma ve yazmalar için NVMe SSD'ler, toplu depolama için yüksek kapasiteli HDD'ler.
- GPU iş yükleri (AI eğitimi, LLM çıkarımı, render, HPC): NVLink veya InfiniBand gibi yüksek bant genişlikli ara bağlantılara sahip özel GPU node'ları. Bu, başka bir şeyle paylaşmak istemediğiniz bir iş yüküdür.
PlusClouds'un bare-metal X7000 ve Leo CN sunucuları bu spektrumun her iki ucunu da kapsar. X7000 serisi, AI eğitimi, HPC ve GPU render iş yükleri için özel olarak üretilmiştir, Dell sertifikalı Leo CN sunucuları ise genel amaçlı yerinde dağıtımları yönetir. Aralarındaki seçim, büyük ölçüde birincil kısıtınızın GPU verimi mi yoksa genel hesaplama yoğunluğu mu olduğuna bağlıdır.
Geçiş Mimarisi: Lift-and-Shift vs. Re-Platform vs. Re-Architect
Her iş yükünü taşımak için üç geniş seçeneğiniz var ve doğru seçim, ne kadar zamanınız olduğuna ve ne kadar teknik borç taşımak istediğinize bağlıdır.
Lift-and-shift, iş yükünü olduğu gibi, minimum değişikliklerle taşımak anlamına gelir. Ortamı bare metal üzerinde çoğaltır ve trafiği yönlendirirsiniz. Bu, en hızlı yol ve iş yükünüzün gerçekten özel donanımda daha iyi çalışıp çalışmadığını test etmenin en yüksek sadakatli yoludur. Dezavantajı, tüm mevcut mimari borcunuzu yanınızda taşımanızdır.
Re-platform, uygulamayı yeniden tasarlamadan yeni ortamdan yararlanmak için hedefli değişiklikler yapmak anlamına gelir. Amazon RDS gibi yönetilen bir veritabanı hizmetinden kendi kendine barındırılan bir PostgreSQL veya MySQL örneğine geçmek, Amazon SQS gibi bulut yerel bir kuyruğu kendi kendine yönetilen bir RabbitMQ veya Kafka cluster'ı ile değiştirmek veya Amazon S3'ten yerinde blok veya nesne depolamaya geçmek bu kategoriye girer. Başlangıçta daha fazla iş, ancak yinelenen yönetilen hizmet ücretlerini ortadan kaldırırsınız.
Re-architect, geçişi temel tasarım sorunlarını düzeltmek için bir fırsat olarak kullanmak anlamına gelir. Bu, en yüksek riskli, en yüksek ödüllü seçenektir. İlk repatriasyon projenizde kritik üretim iş yükleri için denemeyin. Önce altyapıyı kanıtlayın, ardından uygulamaları iyileştirin.
Çoğu ekip için pratik yaklaşım, ilk iş yükü dalgası için lift-and-shift, yönetilen hizmet maliyetinin önemli olduğu bileşenler için seçici re-platforming yapmaktır. Yeniden mimari çalışmasını ayrı bir proje parçasında tutun.
Tipik bir üç katmanlı web uygulaması için kullanışlı bir geçiş sırası:
Aşama 1: Bare-metal node'ları sağlama, ağ yapılandırma, izleme kurma
Aşama 2: Veritabanını taşıma (replica promotion deseni, soğuk taşıma değil)
Aşama 3: Uygulama katmanını bare metal'e dağıtma, bulut ile paralel çalıştırma
Aşama 4: Trafiğin bir yüzdesini kaydırma (10%, 25%, 50%, 100%) geri alma hazır
Aşama 5: 30 günlük gözlem süresinden sonra bulut kaynaklarını devre dışı bırakmaGeçiş Sırasında Genel Bulut ve Bare Metal Arasında Ağ Boşluğunu Köprüleme
Geçiş dönemi, ağın karmaşıklaştığı zamandır. İki yerde iş yükleriniz olacak ve bunların birbirleriyle güvenilir ve güvenli bir şekilde konuşmaları gerekecek.
Standart desen, bulut VPC'niz ile bare-metal ortamınız arasında site-to-site VPN'dir. Bu, çoğu hizmetler arası trafik için kabul edilebilir gecikme ile şifreli bağlantı sağlar. Daha yüksek verim gereksinimleri için, AWS Direct Connect, Azure ExpressRoute veya GCP Cloud Interconnect özel özel bağlantılar sağlar, ancak bunlar maliyet ve kurulum süresi ekler.
Geçiş sırasında, DNS hakkında dikkatlice düşünmeniz de gerekir. Geçiş sırasında değişecek herhangi bir kayıtta düşük TTL'ler (60 saniye veya daha az) kullanın, böylece trafik kaymaları hızlı bir şekilde yayılır. Bare-metal eşdeğerlerinin gerçek trafik altında kararlı olduğunu doğrulayana kadar eski bulut uç noktalarınızı canlı ve sağlıklı tutun.
Kenar yük dengeleme, başka bir dikkate alınması gereken konudur. Kademeli bir trafik kaydırması yapıyorsanız, bulut ve bare-metal backend'ler arasında ince ayarlı kontrol ile trafiği bölebilen bir yük dengeleyiciye ihtiyacınız var. PlusClouds'un Ağ ve Yük Dengeleyicileri, tek bir kontrol düzleminden yönetilen beş ağ türünü destekler: genel, özel, VPN, yönetim ve DMZ yapılandırmaları. Bu, hibrit geçiş dönemini ayrı araçları birleştirmekten çok daha yönetilebilir hale getirir.
Geçiş Sonrası Güçlendirme: Özel Donanımda Güvenlik, Yedeklemeler ve İzleme
Bare metal'e geçmek, güvenlik yığınının daha fazlasına sahip olduğunuz anlamına gelir. Hiperscaler bunun çoğunu sizin için halletti. Şimdi bunu kendiniz halletmeniz gerekiyor.
Güvenlik duvarı yapılandırmanızla başlayın. Her hizmetin açık giriş ve çıkış kuralları olmalıdır. Hiçbir şey varsayılan olarak açık olmamalıdır. AWS Security Groups veya Azure Network Security Groups'a güveniyorsanız, yeni altyapınızda eşdeğer durumsal güvenlik duvarı kurallarına ihtiyacınız var.
İzinsiz giriş tespiti (Wazuh, Suricata veya Falco gibi araçlar kullanarak) ve günlük toplama (bir ELK yığını, Grafana Loki veya benzeri bir platform aracılığıyla) erken kurun. Node'larınızda neler olduğunu görmek istiyorsunuz, üretim trafiğini oraya yönlendirmeden önce, bir şeyler yanlış gittikten sonra değil.
Yedeklemeler, genellikle geçiş planlamasında hak ettiklerinden daha fazla dikkat gerektirir. Kurtarma noktası hedefiniz (RPO) ve kurtarma süresi hedefiniz (RTO) tanımlanmalı, test edilmeli ve kesilmeden önce belgelenmelidir. PlusClouds'un Otomatik Yedekleme hizmeti, açık RPO/RTO hedefleri ve uzaktan geri yükleme yeteneği ile otomatik yedekleme ve kurtarma sağlar. İlk iş yükünüz bare metal'e inmeden önce bunu kurun, sonradan düşünce olarak değil.
Depolama için, katmanlı seçenekler önemlidir. Uygulamanızın sürekli okuduğu sıcak veriler NVMe üzerinde yer alır. Ara sıra eriştiğiniz sıcak veriler SSD üzerinde yer alır. Soğuk veriler (günlükler, arşivler, uyumluluk kayıtları) yüksek kapasiteli HDD üzerinde yer alır. PlusClouds'un Bulut Depolama, tüm üç katman arasında standartlara dayalı havuzlanmış depolama sağlar, bu da ayrı depolama sistemlerini yönetmeden bunu kurabileceğiniz anlamına gelir.
Bare metal üzerinde izleme, daha önce bulutun görünmez bir şekilde yönettiği şeyleri enstrümante etmeyi gerektirir: disk sağlığı (S.M.A.R.T. izleme yoluyla), ağ arayüzü hataları, bellek ECC olayları ve sürekli yük altında CPU sıcaklığı. Bu donanım düzeyindeki sinyalleri, Prometheus ve node_exporter, Netdata veya Datadog gibi araçlar kullanarak uygulama düzeyindeki metriklerinizle izleme yığınıza ekleyin.
Yaygın Repatriasyon Hatalarından Kaçınma (ve Gerektiğinde Buluta Geri Dönme)
En yaygın hata, çok hızlı hareket etmektir. Ekipler, maliyet projeksiyonları konusunda heyecanlanır, denetim aşamasını atlar ve geçiş ortasında bir iş yükünün, bare-metal eşdeğeri olmayan bir bulut yerel hizmetine bağımlı olduğunu keşfeder. Planlama aşamasında yavaşlayın. Uygulama aşamasında hızlanın.
İkinci en yaygın hata, bulut kaynaklarını çok hızlı devre dışı bırakmaktır. Kesimden sonra en az 30 gün boyunca bulut ortamınızı paralel olarak çalışır durumda tutun. Her iki ortamı bir ay boyunca çalıştırmanın maliyeti, sabah 2'de acil bir geri alma maliyetine kıyasla küçüktür.
Üçüncü hata, operasyonel farkı hafife almaktır. Bir hiperscaler'da, arızalı donanım başkasının sorunudur. Bare metal üzerinde, bu sizin sorununuzdur. Ekibinizin, donanım arıza senaryoları (disk arızası, NIC arızası, node arızası) için belgelenmiş çalışma kitaplarına sahip olduğundan emin olun. Bunu yönetmek için dahili kapasiteniz yoksa, yönetilen bir bare-metal sağlayıcı, prim değerindedir.
Geri dönme sorusuna gelince: Taşındıktan sonra bile bulut hesaplarınızı aktif tutun ve altyapı kodunuzu güncel tutun. Bare-metal kapasitenizi aşan beklenmedik bir trafik artışı yaşarsanız, bulut kapasitesini dakikalar içinde, günler değil, başlatabilmek istersiniz. PlusClouds Cloud Servers, 60 saniyelik dağıtım ve sıfır çıkış ücretleri ile, size özel altyapınızı tamamlayan esnek kapasite sunarak, sizi bir hiperscaler'ın fiyatlandırma modeline geri kilitlemeden iyi bir patlama hedefi olarak çalışır.
Ayrıca, repatriasyonun her şey ya da hiçbir şey olmak zorunda olmadığını unutmayın. Birçok ekip, tahmin edilebilir, yüksek kullanım iş yüklerini bare metal üzerinde ve gerçek esneklik ihtiyaçları için ayrılmış daha küçük bir bulut ayak izi ile kararlı bir hibrit ile sonuçlanır. Bu, başarısız bir repatriasyon değildir. Bu, rasyonel bir altyapı stratejisidir.
Bulut repatriasyonu, modern altyapı düşüncesinden bir geri çekilme değildir. Bu, modern altyapı düşüncesinin, olması gerekenden daha pahalı hale gelen bir soruna uygulanmasıdır. Hiperscaler'lar olağanüstü platformlar inşa etti ve doğru iş yükleri için hala doğru cevap olmaya devam ediyorlar. Ancak sürekli yüksek kullanımda çalışan iş yükleri için, özel donanımın ekonomisi göz ardı edilemeyecek kadar çekici hale geldi.
İş yüklerinizi haritalamaya ve iş vakası oluşturmaya başlamaya hazırsanız, PlusClouds'un bare-metal X7000 ve Leo CN sunucuları, tam bir üretim ortamını desteklemek için ağ, depolama ve yedekleme altyapısı ile birlikte yakından bakmaya değer. Ekibinize, belirli iş yükü profiliniz hakkında konuşun ve endüstri ortalamaları değil, gerçek rakamlarınıza dayalı bir TCO karşılaştırması alın.
