Red Hat Summit 2026: Azure OpenShift ile AI Üretime Geçti
İtiraf edeyim, Geçen hafta Bostan’da Red Hat Summit 2026’yı uzaktan izlerken, açık konuşayım, bir an “yine aynı slaytlar mı?” diye düşündüm. Çoğu konferans böyle akıyor zaten; büyük sözler, küçük değişiklikler. Ama bu sefer biraz farklıydı. Microsoft, Platform Modernization Partner of the Year ödülünü aldı ve işin arkasındaki hikâye bence çoğu teknik haberden daha anlamlı.
Şahsen, Çünkü mesele artık sadece “AI yapıyoruz” demek değil. Asıl konu, pilotlardan production’a geçen şirketlerin bu yükü hangi platformda taşıdığı. Ve Azure Red Hat OpenShift (ARO) — biz kısaca böyle çağırıyoruz — tam da bu tartışmanın ortasında dürüyor.
Ödülün Arka Planı: Sadece Pazarlama Değil
Bakın şimdi, ben normalde bu tarz “Partner of the Year” haberlerine çok takılmam (bizzat test ettim). Genelde marketing ekiplerinin birbirine göz kırpması gibi gelir. Ama burada referans müşteri Banco Bradesco; Latin Amerika’nın en büyük bankalarından biri, (bu beni çok şaşırttı). Laf olsun diye seçilmiş bir işim değil.
Bradesco, ARO üzerinde 200’den fazla AI inisiyatifini tek bir governance çatısı altında yönetiyor. Düşünsenize: 200 ayrı model, 200 ayrı ekip, 200 ayrı veri akışı… Üstelik hepsi Azure’un kimlik, güvenlik ve policy katmanlarıyla bağlı. Kağıt üstünde anlatması kolay, ama bankacılık ortamında — LGPD gibi Brezilya düzenlemeleri varken — bunu sahada yürütmek başka bir hikâye.
İkinci referans da bana baya ilginç geldi: Topicus‘un Akkuro adlı kredi platformu — bence çok yerinde bir karar —. Bu platform İsviçre Kuzey bölgesinde çalışıyor; sebep çok net: veri egemenliği. İsviçreli müşterinin finansal verisi İsviçre’de kalacak, nokta. Aynı uygulama Hollanda’da da çalışıyor ama veri orada kalıyor. Tek mimarı var, bölgeler değişiyor, OpenShift dağıtımı aynı kalıyor.
İşte tam da bu noktada devreye giriyor.
Türkiye Perspektifinden Bakınca
İşin aslı şu ki, bu egemenlik meselesi Türkiye için de hayatı bir konu (evet, doğru duydunuz). BDDK düzenlemeleri var, KVKK var, son yıllarda yerli bulut tartışmaları var… Geçen yıl sigorta sektöründen bir müşteride tam bu yüzden hibrit mimarı kurmuştuk; hassas veriler on-prem kaldı, uygulama katmanı ARO’ya taşındı. Akkuro’nun yaptığı şey aslında benim Logosoft’ta bir finans projesinde 8 ay uğraşıp kurduğum yapının daha yönetilmiş hali gibi dürüyor. Daha ucuza mı? Hayır. Daha hızlı mı? Kesinlikle. Daha az ekiple mi dönüyor? Bence evet.
Aslında, Bunu Türkiye’deki şirketler açısından düşünürsek, küçük bir banka ya da orta ölçekli bir fintech için kendi Kubernetes ekibini kurup ayakta tutmak baya yorucu oluyor. Bir SRE mühendisinin maliyeti bile az buz değil; junior’ı saymıyorum bile, aylık 80-120 bin TL bandına çıkabiliyor. Üç kişilik platform ekibi tutmak yerine ARO’nun yönetilen hizmetini ödemek çoğu senaryoda daha mantıklı görünüyor (ciddiyim). Tabi büyük kurumsallarda durum değişiyor; orada ekip zaten var, mesele kontrol ve özelleştirme oluyor.
Dört Yatırım Alanı: Microsoft ve Red Hat Ne Yapıyor?
Summit’te konuşulan teknik başlıkları dört grupta toplamak mümkün. Hepsini sırayla anlatacağım ama önce şu tabloyu koyayım; bence resmî net gösteriyor: (kendi tecrübem)
| Alan | Önemli Yenilik | Kime Dokunuyor? |
|---|---|---|
| Modernization | Konfidansiyel container desteği, ARO Hosted Control Planes | Legacy uygulama göçü yapanlar |
| Security | Microsoft Defender entegrasyonu, ACS (Advanced Cluster Security) | Regulated sektörler |
| AI Innovation | Red Hat AI + Foundry" data-glossary-term="Azure AI Foundry">Azure AI Foundry entegrasyonu, OpenShift AI | ML platform ekipleri |
| Global Expansion | Yeni bölgeler, sovereign cloud desteği | Çok-bölgeli kurumsallar |
Nereden Başlayalım?
Madem modernizasyon dedik, oradan girelim. Eski uygulamaları konteynerize etmek hâlâ dertli bir iş. Çoğu firma “biz monolitleri parçalayacağız” diye yola çıkıyor… Üç ay sonra kim ne yaptı belli olmuyor. ARO’nun burada sağladığı şey en azından operasyon yükünü hafifletmesi; sen kodu konteynerize ediyorsun, platform işe Microsoft ve Red Hat tarafından joint-operated şekilde yönetiliyor.
Aşağı yukarı aynı şeyi Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek yazısında da söylemiştim — egemenlik ile modernizasyon birbirinden kopuk konular değil. Birini düşünmeden diğerine karar vermek zor oluyor.
Securitiy Tarafında Ne Var?
Dürüst olayım; güvenlik tarafındaki Azure Defender for Containers ile Red Hat Advanced Cluster Security entegrasyonu bence en oturmuş yeniliklerden biri. Çünkü iki dünyanın iyi yanlarını alıyor: Defender’ın Azure-native tehdit istihbaratı ve ACS’nın Kubernetes’e özel runtime koruması birlikte çalışıyor.
Geçen ay e-ticaret tarafındaki bir müşteride tam burada sıkıntı yaşamıştık — Defender şüpheli pod davranışını yakaladı ama hangi namespace’te hangi service account’ın ne yaptığını ilk anda çıkaramadık. ACS devreye girince detay ortaya döküldü. Yarım saat sürecek investigation işi beş dakikaya indi desem yeridir. Şu yazıya da bakabilirsiniz: Least Privilege Ajanlar: Güvenliği Baştan Kurmanın Yeni Yolu.
Peki neden?
Peki AI Üretime Geçerken Asıl Düğüm Nerede?
Sıradaki konu biraz can sıkıcı ama önemli. AI pilotlarının %80’i production’a geçemiyor dersem abartmış olmam; bunu Gartner’dan değil, son iki yılda gördüğüm projelerden söylüyorum. Neden mi?
- Model çalışıyor ama identity yönetimi yok; kim hangi modele erişebilir belli değil.
- GPU kaynakları paylaşılamıyor; her ekip kendi kümesini istiyor ve maliyet şişiyor.
- Governance dağılıyor; biri Hugging Face’ten model çekiyor, diğeri Foundry’den alıyor, üçüncüsü kendi fine-tune’ünü yapıyor.
- Production’da observability zayıf kalıyor; model saçmaladığında çoğu zaman sonradan fark ediyorsunuz. (bu kritik)
ARO + OpenShift AI + Azure AI Foundry üçlüsü tam buraya oynuyor aslında.
Bradesco örneğinin kıymeti de burada ortaya çıkıyor; 200 inisiyatifi tek policy çatısı altında tutabilmek öyle kağıt üstünde kolay görünen bir şey değil.
“Müşteriler artık feature istemiyor; en kritik iş yüklerini koşturacakları platformun güvenilirliğini istiyor.” — Aaron Isom, Technical Cloud Strategist
Bunu okuyunca kafamda bazı taşlar yerine oturdu açıkçası.
Son bir yıldır müşteri görüşmelerinde aynı soruyu defalarca duydum: “Aşkın bey, biz Azure OpenAI kullanıyoruz, Foundry’yi de kuracağız ama bunu enterprise seviyede nasıl yöneteceğiz?” Eskiden cevap biraz dolambaçlıydı; şimdi daha net görünüyor.
Eğer Kubernetes çevreindeyseniz ARO + OpenShift AI ciddi adaylardan biri oluyor.
Şimdi gelelim işin can alıcı noktasına.
Küçük Ekip Mi Kurumsal Yapı Mı?
Aslında, Açık konuşayım.
Eğer beş kişilik bir startup’sanız ve sadece POC yapıyorsanız ARO size pahalı gelebilir.
Container Apps" data-glossary-term="Azure Container Apps">Azure Container Apps ya da direkt AKS sizi daha hızlı başlatır.
Ama bazı şartlarda tablo değişiyor:
- 50+ geliştiriciniz varsa;
- düzenlemeye tabi bir sektördeyseniz (finans, sağlık ya da kamu gibi); — ciddi fark yaratıyor
- birkaç bölgede iş yükünüz varsa;
- Zaten OpenShift bilen ekibiniz varsa (RHCSA veya RHCE sertifikalı insanlar).
Böyle olunca ARO’nun yönetilen yapısı gerçekten rahatlatıyor.
Maliyet tarafında da kaba hesap yapılabilir; Azure pricing calculator’a göre 3 master + 3 worker (D8s_v5) olan bir küme aylık yaklaşık 2500-3000 USD bandından başlıyor.
TL bazında bakınca evet kayda değer bir rakam.
Ama buna karşılık self-managed kümeyi üç SRE ile döndürmenin toplam maliyetini düşününce iş bazen tersine dönüyor.
Peki Nasıl Başlanır?
İnanın, Diyelim ki ikna oldunuz ve “tamam Aşkın bey biz de ARO deneyeceğiz” diyorsunuz.
O zaman gerçek hayattan kısa bir başlangıç planı şöyle olabilir:
# 1. Önce gerekli provider'ları register et
az provider register --namespace Microsoft.RedHatOpenShift
az provider register --namespace Microsoft.Compute
az provider register --namespace Microsoft.Storage
az provider register --namespace Microsoft.Authorization
# 2. Pull secret'ı Red Hat'tan al (console.redhat.com)
# 3. Network için VNet ve subnet'leri hazırla
az network vnet create --resource-group aro-rg \
--name aro-vnet --address-prefixes 10.0.0.0/22
# 4. Kümeyi oluştur (bu adım 35-45 dakika sürer)
az aro create --resource-group aro-rg \
--name my-aro-cluster \
--vnet aro-vnet \
--master-subnet master-subnet \
--worker-subnet worker-subnet \
--pull-secret @pull-secret.txtBurada en sık yapılan hata pull secret’ı yanlış formatta vermek oluyor.
JSON dosyası bekleniyor; base64 değil.
Ben ilk denediğimde yarım saat bununla uğraşmıştım doğrusu.
Hata mesajı da pek yol göstermiyor; sadece “invalid pull secret” deyip bırakıyor.
Eğer sadece deneme yapmak istiyorsanız Red Hat’in OpenShift Sandbox’ını veya CodeReady Containers’ı tercih edin.
Neyse Ki OpenShift AI Tarafı Var!
model serving,
pipeline orchestration hepsi içinde.
Azure AI Foundry ile entegrasyon işe henüz tam oturmuş değil;
bazı yerleri elle bağlamak gerekiyor.
Mesela embedding modelini Foundry’de tutup inference’ı ARO’da yapmak istiyorsanız,
arada bir gateway katmanı kurmanız lazım.
Bu konuda Foundry Hosted Agents ile MAF’ı Prod’a Taşımak: Benim Notlarım
yazımda daha detaylı notlar paylaşmıştım,
ona da bakabilirsiniz.
Neyi Beğenmedim?
Ama hep övgü yazmak istemiyorum çünkü dürüst olayım,
ARO’nun sorunları da var.
Bunları söylemezsem eksik kalır:
Birincisi:
Cluster oluşturma süresi hâlâ uzun.
35-45 dakika,
bazen tam bir saate yaklaşıyor.
AKS tarafında bu iş genelde
5-10 dakika içinde bitiyor.
“Zaten production ortamını bir kere kurarsın” diyebilirsiniz;
doğru,
ama dev/test ortamlarını sürekli yıkıp kuran ekipler için sınır bozucu olabiliyor.
İkinci olarak:
Maliyet şeffaflığı pek iç açıcı değil. Azure Cost Management,
ARO için ayrıntılı breakdown göstermiyor;
çoğu zaman tek satırda “ARO cluster” görüyorsunuz. Hangi namespace ne kadar tüketmiş,
hangi workload ne harcamış,
bunları ek araç olmadan görmek zor.
İçincisi:
Türkiye’de henüz bölge yok.
Avrupa tarafında en yakın seçenekler North Europe (Dublin) veya West Europe (Amsterdam).
Latency hassas iş yükleriniz varsa bunu hesaba katmanız gerekiyor.
Bunu Azure’ın Avrupa Yatırımları: Egemen Bulut ve AI Genişlemesi
yazısında da konuşmuştum.
Sıkça Sorulan Sorular
Azure Red Hat OpenShift ile AKS arasında ne fark var?
AKS, Microsoft’un yönettiği saf Kubernetes hizmeti. ARO işe Red Hat OpenShift’in Azure üzerinde joint-operated (yanı Microsoft + Red Hat birlikte destekliyor) versiyonu. Aslında ikisi arasındaki fark oldukça belirgin — ARO; built-in CI/CD, developer console, RBAC genişletmeleri, ek güvenlik özellikleri. Enterprise destek paketi sunuyor. Bence OpenShift ekosistemindeyseniz ARO çok daha mantıklı, vanilla Kubernetes yeterliyse AKS’e bakın.
ARO’da OpenAI veya Foundry modellerini nasıl kullanabilirim?
Modeller Azure tarafında çalışıyor, ARO’daki uygulamalarınız bunlara REST API üzerinden erişiyor. Managed identity ile authentication yapabilir, private endpoint ile trafiği VNet içinde tutabilirsiniz. Bir de şunu söyleyeyim — OpenShift AI tarafında kendi modellerinizi de serve edebiliyorsunuz. Yanı ikisini birlikte kullanan hibrit bir mimarı de gayet mümkün.
KVKK ve BDDK uyumluluğu için ARO uygun mu?
Bunu yaşayan biri olarak söyleyeyim, Açıkçası burada dikkatli olmak lazım. Veriniz Türkiye’de kalmak zorundaysa, henüz — itiraz edebilirsiniz tabi — Türkiye’de Azure bölgesi olmadığı için saf ARO tek başına yeterli olmayabilir. Ancak Azure Local + ARO hibrit yapısı veya West Europe gibi yakın bölgelerle BCRA/SCC çerçevesinde uyumluluk sağlanabiliyor. Her durumda hukuk ve compliance ekibinizle mutlaka konuşun — bence bu adımı atlamak büyük risk.
Mevcut on-prem OpenShift kümemi ARO’ya nasıl taşırım?
Red Hat’in OADP (OpenShift API for Data Protection) aracı veya MTC (Migration Toolkit for Containers) ile workload migration yapabilirsiniz. Tipik bir geçiş şöyle gidiyor: önce hedef kümeyi provision ediyorsunuz, sonra image registry mirror, ardından namespace bazlı batch migration (ciddiyim). Tecrübeme göre stateful uygulamalar için PV (persistent volume) stratejisini önceden netleştirmek çok önemli — bunu es geçmeyin.
ARO’yu tek başıma yönetebilir mıyım, yoksa ekip mi lazım?
Küçük bir POC için tek kişi yetebilir (yanlış duymadınız). Ama production için en az 2-3 kişilik bir platform ekibi öneririm. Hani OpenShift kavramları — mesela Operators, Routes, BuildConfigs — vanilla Kubernetes’ten oldukça farklı. Öğrenme eğrisi gerçekten var. Ekipte RHCSA veya en azından OpenShift Foundations sertifikası olan biri olsun, bence bu şart.
Kaynaklar ve İleri Okuma
İnanın, Microsoft Azure Blog — Red Hat Summit 2026 Duyurusu
Azure Red Hat OpenShift Resmî Dokümantasyonu
Red Hat OpenShift Resmî Sayfası
ARO Üzerinde AI Workload’ları — Microsoft Learn
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder