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ı.

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)

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. Foundry Toolboxes: Ajan Araçlarını Toplamak Neden Şart Oldu? yazımızda bu konuya da değinmiştik.

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? Microsoft Agent Framework v1.0: Lokal’den Prod’a Geçiş yazımızda bu konuya da değinmiştik.

• 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.

Azure Container Apps ya da direkt AKS sizi daha hızlı başlatır.

Ama bazı şartlarda tablo değişiyor:

1. 50+ geliştiriciniz varsa;
2. düzenlemeye tabi bir sektördeyseniz (finans, sağlık ya da kamu gibi); — ciddi fark yaratıyor
3. birkaç bölgede iş yükünüz varsa;
4. 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. Kubernetes v1.36: Volume Group Snapshots Sonunda GA Oldu yazımızda bu konuya da değinmiştik.

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.txt

Burada 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.

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. Bu konuyla ilgili mssql-python’a Apache Arrow Desteği: SQL Server için Yeni Devir yazımıza da göz atmanızı tavsiye ederim.

İ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

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Copilot CLI’yi Telefondan Yönetmek: Benim Sahada Gördüğüm Etki19 May 2026

Azure MCP Server .mcpb Paketi: Kurulum Artık Çocuk Oyuncağı25 Nis 2026

langchain-azure-cosmosdb: Tek Veritabanıyla Agentic Uygulamalar3 May 2026

C# 15’te Union Types: Eksik Parça Nihayet Geldi4 Nis 2026