Geçen ay Ankara’daki bir üretici müşterimizle FinOps masasına oturduk. Tabloda Azure faturası vardı, üç sayfa. Üst yönetim “bu rakamlar nasıl bu kadar büyüdü, biz aynı işi aynı yükle yapıyorduk” diye soruyordu. Cevap aslında basitti: ekip son altı ayda RAG denemeleri için sekiz farklı GPU SKU’sunu açıp kapatmıştı, biri unutulmuştu, gece 24 saat boş çalışıyordu. Aylık 11.400 TL kaynayıp gitmiş.
2026’nın bulut hikâyesi tam olarak böyle. Yeni teknoloji eskisinin üstüne yığılıyor; ama hâlâ aynı eski şeyleri yanlış yapmaya devam ediyoruz. Bu yazıda, 2026’da Türkiye’deki orta ölçek ve kurumsal işletmeleri gerçekten ilgilendirecek dokuz başlığı, sahada gözlemlediğimiz örneklerle, kaçınılması gereken hatalarla ve hangi metrikleri takip etmek gerektiğiyle birlikte aktarıyorum. Vendor pazarlamasından arınmış, bizzat fatura ödediğimiz için bildiğimiz hâliyle.
1. Yapay Zekâ Artık Bir Katman Değil, Mimarinin Kendisi
2024 yılında AI demek “OpenAI API çağrısı” demekti. 2025 boyunca copilot furyası bütün ürünlere yapıştırdı. 2026 farklı: AI artık uygulamanın bir özelliği değil, uygulamayı şekillendiren mimarinin kendisi. Microsoft Foundry, Azure AI Search, Cosmos DB ve Functions birlikte çalışırken artık şöyle düşünüyoruz: kullanıcı bir cümle yazar, sistem bu cümleyi anlar, hangi servise gideceğine kendisi karar verir, çağırır, dönen sonucu özetler ve sunar. Klasik request-response akışı yerine intent-driven bir akış var.
Pratikte ne anlama geliyor? Bir sigorta şirketi için yaptığımız son projede, eski portal şu işi yapıyordu: müşteri menüden poliçe seçer, formu doldurur, gönderir. Yeni mimaride müşteri bir kutuya “İstanbul’da daire alıyorum, deprem dahil zorunlu sigorta lazım, 700 bin TL bedel” yazıyor. Arka planda bir orchestrator agent bu cümleyi alıyor, tool calling ile poliçe motoruna gidiyor, vergiyi hesaplıyor, müşteri kayıtlarına bakıp KKB skorunu istiyor, sonucu özetliyor. Klasik anlamda 14 ekran olan iş, üç soruya iniyor.
Bu mimarinin Azure tarafındaki üç temel taşı şunlar:
- Azure AI Foundry (eski adıyla AI Studio): Model seçimi, prompt yönetimi, fine-tune ve deployment — hepsi tek panelde. GPT-5, Llama 3.3, Phi-4 ve sektöre özel modeller burada.
- Azure AI Search + Cosmos DB: RAG için vektör veri tabanı katmanı. Cosmos DB’nin yeni vector index özelliği sayesinde ayrı bir vektör veri tabanı kurmadan yapabiliyorsunuz.
- Azure Functions + Durable Functions: Agent orchestration için stateless ve stateful workflow’lar. Bir agent’ın “düşünme adımlarını” durable olarak kaydedip 30 dakika sonra kaldığı yerden devam ettirebiliyorsunuz.
Şimdi gelelim acı kısma. Maliyet. Aynı sigorta projesinde Power BI raporunu açtığımızda gördüğümüz şuydu: GPT-4o ile saniyede 12 kullanıcı = aylık 86.000 TL. GPT-4o-mini ile aynı kullanıcı sayısı = aylık 14.000 TL. Tool calling doğruluk farkı yüzde dört. Bunu öğrendikten sonra prompt’u yeniden yazdık, mini modele geçtik. Aradaki yüzde dört doğruluk farkını da bir verification step ile kapattık (önce mini cevaplar, kritik yanıtlarda 4o doğrular).
Saha notu: Bir LLM uygulamasını üretime alırken ilk üç ay için token başına maliyet metriği kurun. Application Insights üzerinde “kullanıcı başına aylık token tüketimi” panelini açın. Aksi halde fatura geldiğinde geç olur.
RAG Mimarisinin Tipik Hataları
Sahada en sık gördüğümüz üç hata:
- Yanlış chunk boyutu. Belgeyi 8000 token’a bölüp atınca model “evet okudum” diyor ama gerçekte sadece ilk paragrafı kullanıyor. 500–800 token arası, 50 token overlap ile başlayın, sonra ölçün.
- Embedding modelini sonradan değiştirmek. Bir kez seçin, dokümante edin, değiştirmek isterseniz tüm vektörleri yeniden oluşturun. Yarısı eski, yarısı yeni embedding ile aramada saçma sonuçlar gelir.
- Reranking yapmamak. Top-K=10 ile gelen sonuçları doğrudan modele basmak yerine bir cross-encoder ile yeniden sıralayın. Doğruluk anlamlı şekilde artar, maliyet ihmal edilebilir.
# Azure OpenAI ile basit bir RAG cağrısı (Python)
from openai import AzureOpenAI
client = AzureOpenAI(
azure_endpoint="https://cs-foundry.openai.azure.com/",
api_version="2025-04-01-preview",
)
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "Sadece verilen baglama göre cevap ver."},
{"role": "user", "content": f"Baglam:n{context}nnSoru: {soru}"},
],
temperature=0.2,
max_tokens=500,
)
print(resp.choices[0].message.content)
2. FinOps: Artık Bir Tercih Değil, Bir Disiplin
Yıl başında bir e-ticaret müşterimiz bizi aradı: “Bulut faturamız son üç çeyrekte yüzde 180 arttı, gelirimiz aynı kaldı.” İki günlük bir audit sonunda bulduklarımız klasikti ama hâlâ herkesi vurmaya devam ediyor:
- Test ortamında unutulmuş üç adet D8s_v5 VM (aylık 7.800 TL)
- Geliştirme aboneliğinde gece dahi açık kalan AKS cluster (aylık 12.300 TL)
- Premium SSD’ye taşınmış ama trafiği düşmüş veritabanları (aylık 4.500 TL fazla)
- Reserved Instance dururken on-demand kullanılan compute (aylık ~9.000 TL kayıp)
FinOps Foundation’ın 2026 raporuna göre orta ölçekli işletmelerin bulut harcamalarının ortalama yüzde 32’si boşa gidiyor. Türkiye’de döviz kurunun stresi düşünüldüğünde bu rakam çok daha can yakıcı. Üstelik FinOps artık “ay sonu raporu hazırlayan finans personeli” demek değil. Kodun parçası hâline geliyor:
# Azure Pipelines: deploy öncesi maliyet tahmini
- task: AzureCLI@2
displayName: "Cost estimate via Infracost"
inputs:
azureSubscription: "$(subscription)"
scriptType: "bash"
scriptLocation: "inlineScript"
inlineScript: |
infracost breakdown --path . --format json --out-file estimate.json
THRESHOLD=500
MONTHLY=$(jq '.totalMonthlyCost | tonumber' estimate.json)
if (( $(echo "$MONTHLY > $THRESHOLD" | bc -l) )); then
echo "##vso[task.logissue type=error]Cost $MONTHLY USD exceeds limit"
exit 1
fi
Bu pipeline parçası bizim için altın değerinde. Bir pull request bulut maliyetini önemli ölçüde artıracaksa, kod merge olmadan önce uyarı veriyor. Geliştirici “neden bu kadar pahalı?” diye soruyor, mimar müdahale ediyor, gerekirse SKU küçültülüyor. Üç ay önce uygulamaya başladığımız bir bankada, ilk altı haftada 41.000 TL’lik gereksiz harcamayı kaynağında engelledi.
FinOps Olgunluk Modeli (Türkiye Versiyonu)
| Seviye | Belirti | Eylem |
|---|---|---|
| Crawl | “Fatura geldi, bakalım…” | Cost Management’i aç, budget alert kur |
| Walk | Aylık raporlar var, tag politikası başlamış | Reserved Instance/Savings Plan analizi yap |
| Run | FinOps takımı kuruldu, showback başladı | Pipeline’a maliyet kapısı ekle, chargeback‘e geç |
Türkiye’de gözlemlediğimiz: kuruluşların büyük çoğunluğu hâlâ “Crawl” seviyesinde. “Walk” seviyesine geçmek altı ayda mümkün ama kararlı bir sponsor (CFO veya CTO) gerektiriyor. Aksi halde herkes kendi bildiği gibi provision ediyor, fatura sürpriz olmaya devam ediyor.
3. Sovereign Cloud ve Veri Egemenliği: Türkiye İçin Acil Gündem
KVKK Kurulu’nun 2025 sonunda yayınladığı yorumlayıcı kararla birlikte, finansal hizmetler ve sağlık sektöründe veri ikametgâhı (data residency) artık tartışma konusu değil, uyum zorunluluğu. BDDK kararıyla bankaların kritik iş yüklerinin Türkiye’de tutulması hâlihazırda yıllardır geçerli. 2026’da bu hassasiyet yatay bir şekilde tüm sektörlere yayılıyor.
Pratikte üç seçeneğiniz var:
- Türkiye’de fiziksel veri merkezi olan hyperscaler. Şu an için Microsoft Azure’un İstanbul bölgesi, AWS’nin yeni İstanbul bölgesi (2026 başında genel kullanıma açıldı) ve Google Cloud’un yakında açacağı İstanbul bölgesi.
- Yerli bulut sağlayıcısı. Burası CloudSpark gibi servis sağlayıcıların güçlü olduğu alan. KVKK uyumlu, Türk şirket, faturanız TL.
- Hibrit yaklaşım. Hassas veri Türkiye’de (kendi DC’nizde veya yerli bulutta), hesaplama bulutta. Azure Arc ile yönetim katmanı tek panele toplanıyor.
Geçen üç ayda iki müşteri için bu üçüncü modeli kurduk. Birinde hasta verileri Türkiye’de bir Virtuozzo Hybrid Infrastructure kümesinde, AI inferans Azure West Europe’da. Veriyi göndermiyoruz; soruyu modelin yanına getiriyoruz. Bant genişliği maliyeti düşüyor, regülasyon uyumu sağlanıyor, performans tatmin edici.
Dikkat: “Veriyi şifreleyip yurt dışına gönderiyoruz, sorun yok” yaklaşımı KVKK için hâlâ yurt dışına aktarımdır. Şifreleme kuralı aşmıyor. Hukukçunuza danışmadan mimari karar vermeyin.
4. Platform Engineering ve Internal Developer Platform
Üç yıl önce DevOps ekiplerimiz mutluydu: Terraform yazıyoruz, Helm chart hazırlıyoruz, Kubernetes manifest’leri itiyoruz. 2026’ya geldiğimizde geliştiriciler artık bu kadar derinlikten yoruldu. “Ben sadece bir API yazıp deploy etmek istiyorum, neden 14 farklı YAML dosyasını öğrenmek zorundayım?” sorusu meşrulaştı.
Çözüm: Platform Engineering. Bir platform ekibi, iç müşteri olarak gördüğü geliştirici takımları için Internal Developer Platform (IDP) kuruyor. Geliştirici tek bir komutla — veya bir formdan — tam anlamıyla yapılandırılmış, politika uyumlu bir ortam oluşturuyor. Altyapının tüm karmaşıklığı arka tarafta gizli.
Azure ekosisteminde bu yaklaşım Azure Developer CLI (azd) + Azure Deployment Environments ile geliyor. Bir geliştiricinin bakış açısından yeni bir mikroservis ortamı kurmak şu kadar:
azd env new my-payment-api
azd env set REGION turkeycentral
azd up
Arka tarafta neler oluyor? Bir resource group oluşturuluyor, ağ yapılandırılıyor, AKS namespace açılıyor, Key Vault bağlanıyor, Application Insights bağlanıyor, ortam değişkenleri set ediliyor, CI/CD pipeline tanımlanıyor, security scan’ler aktif hâle geliyor. Geliştirici bunların hiçbirini görmek zorunda değil; ama hepsi standart, güvenli ve denetlenebilir şekilde yapılıyor.
Backstage ile Birleşik Geliştirici Portalı
Spotify’ın açık kaynak hâle getirdiği Backstage, son iki yılda kurumsal IDP’lerin defakto front-end’i hâline geldi. Türkiye’de bizim de pilot yaptığımız bir bankada, Backstage üzerinden geliştirici şu adımlarla yeni bir mikroservis ayağa kaldırıyor:
- “Yeni Servis Oluştur” butonuna tıklar.
- Şablon seçer (Java Spring Boot, .NET 9, Node.js, Python FastAPI).
- Servis adı, takım, SLA seviyesi gibi metadata’yı girer.
- Backstage arka planda GitHub repo açar, bir scaffold kod basar, AKS namespace oluşturur, Argo CD pipeline’ı kurar, Backstage Software Catalog’a kayıt eder.
- Beş dakika sonra geliştirici “merhaba dünya” endpoint’ine HTTP isteği atabiliyor.
Bu yaklaşımın getirisi sadece hız değil. Asıl getiri standardizasyon. Eskiden her takım kendi bildiği gibi yapardı; biri OpenTelemetry, diğeri sadece log; biri Helm, diğeri kustomize. Şimdi hepsi aynı şablondan üretildiği için izleme, güvenlik ve maliyet kontrolü tutarlı.
5. Edge Computing ve Bulutun Süreklilik Çağı
Veri her geçen gün üretildiği yere daha yakın işlenmek istiyor. Otonom forklift, perakende mağaza analitiği, akıllı şehir sensörleri, yeni nesil kamera sistemleri — hepsinin ortak ihtiyacı: düşük gecikme ve bant genişliği tasarrufu.
İstanbul Hadımköy’deki bir lojistik depo için yaptığımız çözümü anlatayım. 64 adet kamera, gerçek zamanlı paket sayma ve hasar tespit yapıyor. Klasik mimari ile her kareyi buluta gönderseydik aylık trafik faturası yaklaşık 18.000 TL’yi buluyordu. Bunun yerine depodaki bir Azure Stack Edge kutusunda Onnx modelini koştuk. Yalnızca anomali tespit edilen kareler buluta gidiyor; trafik fatura kaleminde ay sonu 1.700 TL görünüyor.
Bulut ile edge arasındaki sınır eriyor. Microsoft “adaptive cloud” diyor; AWS “edge to cloud continuum” diyor. Sonuçta teknik olarak şunu anlıyoruz:
- Bir kontrol düzlemi var (genellikle bulutta — Azure Arc, AWS Outposts kontrolcüsü).
- Bir veri düzlemi var (edge cihazda — gerçek iş yükü orada koşuyor).
- İkisi arasında declarative bir konfigürasyon akışı var (GitOps).
Bu mimaride en zor kısım gözden kaçar: edge cihazların yaşam döngüsü. Sahaya 200 cihaz koyduğunuzda bir tanesi bozulduğunda, içine girip yapılandırmak istemezsiniz. Zero-touch provisioning, otomatik image update ve uzaktan attestation şart.
6. Sürdürülebilirlik: Yeşil Bulut Artık Pazarlamadan Fazlası
Avrupa’da CSRD (Corporate Sustainability Reporting Directive) kapsamında 50.000+ şirket karbon raporlamaya başladı. Türkiye’de bu ölçekte zorunluluk yok ama tedarik zinciri etkisi belirgin: Avrupalı müşteri “tedarikçim olarak senin de Scope 3 verini istiyorum” diyor. Cevap veremeyenler ihale dışı kalıyor.
Bulut bu hikâyenin önemli parçası. Hyperscaler’lar Scope 2 (elektrik) için karbon emisyon dashboard’u sunuyor. Microsoft Sustainability Manager, AWS Customer Carbon Footprint Tool ve Google Carbon Sense bunu yapıyor. Üç önerim var:
- Bölge seçimi karbon hesabını değiştirir. Microsoft’un Norveç bölgesi neredeyse sıfır karbon, Doğu ABD ortalama, Hindistan kömür yoğun. Latency izin veriyorsa karbon seviyesini de hesaba katın.
- Saatlik tüketim profili önemli. Batch işleri gece 02:00–06:00’a kaydırın; bu saatlerde rüzgâr+güneş üretim payı yüksek olduğu için karbon yoğunluğu düşer.
- Boşta kapasite = boşa karbon. FinOps’la sürdürülebilirlik aynı madalyonun iki yüzü. Boşa giden VM hem para yakıyor hem CO₂ üretiyor.
7. Zero Trust: Artık Buzzword Değil, Operasyonel Zorunluluk
2025’in ikinci yarısında Türkiye’de yaşanan büyük veri sızıntılarının ortak özelliği basitti: bir kullanıcının VPN şifresi ele geçti, içeri girdi, ağda lateral movement ile her yere ulaştı. Klasik castle-and-moat güvenlik anlayışının çöküşü.
Zero Trust beş ana prensip etrafında dönüyor:
- Hiçbir kullanıcı veya cihaz varsayılan olarak güvenilir değildir.
- Her erişim talebi ayrı ayrı doğrulanır.
- En az ayrıcalık ilkesi her zaman uygulanır.
- Mikrosegmentasyon ile patlama yarıçapı sınırlandırılır.
- Şüpheli davranış sürekli izlenir.
Microsoft tarafında bu mimarinin parçaları net:
- Microsoft Entra ID (eski Azure AD): kimlik kontrolü, conditional access, identity protection.
- Microsoft Defender for Cloud: cloud security posture management (CSPM) ve workload protection.
- Microsoft Sentinel: SIEM/SOAR, kullanıcı ve varlık davranış analitiği.
- Microsoft Intune: cihaz uyumluluğu ve mobile device management.
Bir hayat sigortası firması için kurduğumuz Zero Trust mimarisinde, bir VPN yerine Entra Private Access kullandık. Kullanıcı uygulamaya bağlanırken sadece o uygulamayı görüyor; ağın geri kalanı yok hükmünde. Yan ürün olarak VPN konsantratörü maliyetini de sıfırladık.
# Conditional Access policy: Türkiye disindan yüksek riskli giris engellensin
az ad signed-in-user show
az conditional-access policy create
--display-name "Block-Risky-NonTR"
--conditions '{"signInRiskLevels":["high"],"locations":{"excludeLocations":["TR-only"]}}'
--grant-controls '{"operator":"OR","builtInControls":["block"]}'
8. Multi-Cloud: Romantizm Bitti, Pragmatizm Başladı
2022–2023 multi-cloud büyük bir vaaddi: vendor lock-in’den kurtulun, fiyat baskısı yapın, en iyi servisleri her bulutdan çekin. 2026’da gerçekçi resim şu: multi-cloud yönetilmesi pahalı. Yine de bazı senaryolarda kaçınılmaz.
Şu durumlarda multi-cloud mantıklı:
- Müşteri zorluyor (banka tedarikçisi olarak hem AWS hem Azure’da hizmet vermek zorundasınız).
- Belli bir servis sadece bir bulutda var (BigQuery’in alternatifi pratikte yok).
- Coğrafi yayılım gerekiyor ve tek hyperscaler yetersiz.
- Yedeklilik için aktif-aktif disaster recovery kuruyorsunuz.
Bu durumlarda bile her bulutda aynı şeyi yapmaya çalışmayın. Ortak bir soyutlama katmanı (Kubernetes, Terraform, GitHub Actions) üzerinde her bulutun güçlü tarafını kullanın. Bizim önerdiğimiz desen: kontrol düzlemi tek (örneğin Azure Arc + ArgoCD), iş yükleri farklı bulutlarda.
9. Serverless ve Event-Driven Mimarinin Olgunlaşması
Functions, beş yıl önce “küçük scriptler için” damgalandı. 2026’da büyük üretim sistemleri Functions üzerine kuruluyor. Sebep: Durable Functions, Function Flex Plan ve cold start optimizasyonları birleşince serverless artık enterprise kabul ediyor.
Olay-tetikli (event-driven) mimari için Azure’da kombinasyon şu:
| Bileşen | Görev | Tipik kullanım |
|---|---|---|
| Event Grid | Olay dağıtımı | Kaynak değişikliği bildirimleri |
| Service Bus | Mesajlaşma | Sıralı, garantili işleme |
| Event Hubs | Yüksek hacimli stream | Telemetri, log akışı |
| Functions | İş mantığı yürütme | Reaksiyoner kod |
| Durable Functions | Stateful workflow | Onay süreçleri, saga |
Bir e-fatura işleme sistemi için bu modeli üretime aldık. Günde 850.000 fatura işliyor, ortalama gecikme 4 saniye, ay sonu Functions faturası 6.200 TL. Eski monolitik sistemin Azure VM’de bunu yapma maliyeti aylık 38.000 TL idi.
2026 İçin Pratik Yol Haritası
Bu trendlerin hangisinden başlamalısınız? Bizim önerimiz, sırasıyla:
- FinOps temelini at. Bütçe alarmları, tag politikası, aylık review. Beş hafta yeter, getirisi anında görünür.
- Zero Trust olgunluğunu ölç. Microsoft Secure Score’a bak, en zayıf üç başlığı kapat.
- Bir iş süreciyle AI denemesi yap. “Tüm şirketi değiştirelim” tuzağına düşme; tek bir somut sürece (müşteri desteği, fatura okuma, sözleşme analizi) odaklan.
- Veri ikametgâhı stratejini netleştir. Hangi veri hangi sınırın içinde kalacak, kâğıda dök, yöneticiyle imzala.
- Platform engineering’e ilk adım. En çok tekrar eden üç deployment şablonunu standartlaştır, Backstage düşünmeye başla.
Sık Sorulan Sorular
2026’da bulut maliyetleri artmaya devam edecek mi?
Evet ama eşit dağılmayan bir artış olacak. AI/GPU iş yükleri agresif şekilde pahalılaşacak; geleneksel compute ise küçülen marjlarla yavaş yavaş ucuzlayacak. Türkiye için döviz etkisi en belirleyici değişken olmaya devam edecek; bu yüzden Reserved Instance ve Savings Plan’lar artık tercih değil zorunluluk.
Yerli bulut sağlayıcıları ile hyperscaler arasında nasıl karar veririm?
Üç sorunun cevabını ver: (1) Verim sınırın hangi tarafında olmak zorunda? (2) Hangi servislere gerçekten ihtiyacım var, hyperscaler özel servisleri kritik mi? (3) Faturayı TL ile mi yoksa USD ile mi ödemek istiyorum? Yerli sağlayıcılar regülasyon, fatura ve destek tarafında güçlü; hyperscaler’lar AI ve özel servisler tarafında. Hibrit hâlâ en pragmatik cevap.
Küçük bir ekibim için Platform Engineering aşırıya kaçar mı?
5 kişilik bir ekipte tam Backstage kurulumu fazla. Ama “tek tıkla yeni servis” ilkesi her boyutta uygulanabilir. Üç adımlık bir scaffold script’i, standart bir Bicep modülü ve paylaşılan bir GitHub Actions workflow’u — bu da bir mini IDP‘dir ve büyük getirisi vardır.
RAG yerine fine-tuning yapsam daha iyi olmaz mı?
Çoğu zaman olmaz. Fine-tuning bir kez yapılır, veri sürekli güncellenirse modeli yeniden eğitmek zorunda kalırsın. RAG ise belge dağarcığını anlık günceller. Fine-tune’u sadece tarz/format öğretmek için kullan; bilgi için daima RAG.
Edge cihazlarımı uzaktan nasıl yönetirim?
Azure Arc en olgun seçenek. Cihaz sayısı az ise (10–20 cihaz) basit bir GitOps + SSH altyapısı yeter. Yüzlerce cihaza çıkıyorsanız Arc + Azure IoT Operations kombinasyonu gerek; merkezi politika dağıtımı, cihaz envanteri ve uzaktan komut yürütme tek yerden.
Saha Notu Olarak Kapanış
2026 bulut hikâyesinin merkezinde aslında teknoloji değil disiplin var. Her gün yeni bir servis çıkıyor, her hafta yeni bir buzzword. İşletme olarak bunlardan hangisinin sizin için anlamlı olduğunu sormak, küçük denemeler yapmak ve sonuçları ölçmek dışında kestirme yok. Vendor sunumları her zaman parlak, sahada işler her zaman karışık. Aradaki köprüyü kuran şey, ekibinizin disiplini.
Bizim ekip olarak son üç ayda öğrendiğimiz tek bir şey varsa o da şu: küçük başla, hızlı ölç, acımasızca kapat. Çalışmayan deneyi kapatmaktan utanma. Çalışanı ölçeklendirmekten korkma. 2026 için tek tavsiyem bu.
Bulut yolculuğunuzda kaybolduğunuzu hissederseniz CloudSpark ekibi olarak bir kahve eşliğinde dinlemekten mutluluk duyarız. Vendor değil, müşterek geçirilen 12 yıl deneyimle.
