Ortalıkta dolaşan bir meme var: Duşta bitkin çökmüş Tony Soprano, kortizol ibresi kırmızıda — altında yazı: "700 mikroservis işletmek". Hemen altında aynı adam, purosunu keyifle tüttürüyor, kortizol yeşilde: "1 büyük monolit işletmek". Mühendisler paylaşıp duruyor; çünkü bütün iyi altyapı meme'leri gibi bu da şaka kılığına girmiş bir postmortem. Biz müşterilerimiz için iki tür ortamı da işletiyoruz — ve gece 3'te ikisi tarafından da uyandırılan taraf olduk — o yüzden işin ciddi versiyonu şöyle: 700 servislik faturanın içinde gerçekte ne var, sektör neden sessizce konsolidasyona döndü, meme neyi es geçiyor ve bu enflasyonu üretimi kırmadan nasıl geri sararsınız.

RFC'ye kimsenin yazmadığı servis-başına fatura

Eklediğiniz her mikroservis, API'sı olan bir kod parçasından ibaret değildir; ayakta duran bir operasyon yükümlülüğüdür: bir deploy hattı, bir dashboard, bir alarm seti, log yönlendirmesi, IAM rolleri ve secret'lar, bağımlılık yamaları, bir maliyet kalemi ve birinin nöbet zihninde bir yuva. Bu yük servis sayısıyla kabaca doğrusal büyür — ama etkileşimler öyle değil. Servis sınırları ağ çağrısıdır; ağ çağrıları başarısız olur, zaman aşımına düşer, retry eder ve büyütür. Arıza modları kutu sayısıyla değil, bağlantıların karesiyle çoğalır.

Bunu ilk hissettiğiniz yer olay müdahalesidir. Monolitte kötü bir istek size tek bir stack trace verir. Aynı hata 12 servise yayıldığında dağıtık bir cinayet soruşturmasına dönüşür: request ID'leri log sistemleri arasında eşleştir, gecikmenin patladığı sıçramayı bul, ufak bir sorunu kesintiye çeviren retry fırtınasını keşfet. Ciddi bir tracing disiplini olmadan (metrik, log ve trace) çözüm süresi servis sayınızla ölçeklenir. Meme'in üst panelindeki kortizol budur — birimi uykudur.

Bir de düz anlamıyla fatura var: servis başına compute payı (her pod kendi tepe yüküne göre boyutlanır), servisler arası veri transferi ve load balancer sıçramaları, her dev/staging ortamının N kopyası ve parçalar ayrı olduğu için var olan platform takımyıldızı (service mesh, registry, CI kapasitesi). Maliyet denetimlerinde en büyük kalemin tek bir kaynak değil, mimarinin kendisi olduğunu düzenli olarak görüyoruz.

Şirketler 700'e nasıl geliyor

Neredeyse hiçbir zaman kararla; her zaman varsayılanla. Mikroservis, 2015-2022 döneminin prestij mimarisiydi — konferans güdümlü, CV dostu ve Netflix ile Amazon'un ona gerçekten ihtiyaç duyması sayesinde kutsanmış. Ekipler servisleri varlık sınırlarından böldü ("user-service, order-service, invoice-service…"), organizasyonun mimariye büyüyeceğini varsaydı ve her yeni özelliği yeni bir repo yaptı; çünkü desen buydu. Orta ölçekli şirketlerdeki sonuç: ekip sayısının on katı servis sayısı. Mühendis başına yirmi servis bir mimari değildir; fazladan adımları ve pager sorunu olan dağıtık bir monolittir.

Düzeltme gerçek — ve kamuya açık

Sektör birkaç yıldır bunu geri sarıyor, bazen yüksek sesle: en bilinen örnek, Amazon'un kendi Prime Video ekibinin, dağıtık bir izleme hattını fiilen monolite konsolide ederek o iş yükünün altyapı maliyetini yaklaşık %90 düşürdüğünü kamuya yazması. "Modüler monolit" — tek deployable, sıkı iç modül sınırları — teselli ödülünden saygın varsayılana terfi etti; ki bu tam olarak mikroservis benimseme rehberimizde savunduğumuz pozisyon: çoğu ekip oradan başlamalı ve servisi ancak somut bir şey (bağımsız ölçekleme, ekip özerkliği, farklı runtime) bölünmeyi zorladığında çıkarmalı.

Meme'in atladığı gerçek

Dürüstlük, üst paneli biraz savunmayı gerektiriyor. Puro içen monolit sahibi deploy gününe kadar rahattır: tek deployable tek patlama yarıçapı demektir; ekip büyüdükçe büyüyen deploy korkusu, ekipler arası merge çekişmesi ve tek sıcak yol yüzünden tüm uygulamayı ölçekleme. Monolitler de kendi tarzlarında çürür — modül sınırları aşınır, her şey her şeyi import eder ve elinizde suçlayacak ağ bile olmayan iki dünyanın en kötüsü kalır. Meme'in gerçek dersi "tek büyük monolit" değil; servis sayısının streste ödenen bir maliyet olduğu ve organizasyonunuzun gerçekten ihtiyaç duyduğundan fazlasını satın almamanız gerektiğidir. Savunulabilir pratik kural: servis sayınız ekip sayınıza benzemeli — her servis uçtan uca tek bir ekibin malı — artı bağımsız ölçekleme ya da uyumluluk ihtiyacı olan nadir gerçek istisnalar.

Konsolidasyon playbook'u (güvenle geri sarmak)

  • 1. Envanter ve harita. Her servisi sahibi, istek hacmi, deploy sıklığı ve altyapı maliyetiyle listeleyin; sonra trace'lerden çağrı grafiğini çıkarın. Kimsenin sahibini söyleyemediği servisler ilk adaylarınızdır — ve olacaklar.
  • 2. Birleştirme adaylarını belirtiden seçin. Güvenilir sinyaller: hep birlikte deploy olan servisler (itiraf eden bir dağıtık monolit), trafiği çoğunlukla birbirinden ibaret geveze ikililer, dakikada bir istek alan minik utility servisleri ve zaten tek ekibin sahip olduğu kümeler.
  • 3. Çamura değil, modüle birleştirin. Kodu, eski servis sınırlarını modül sınırı olarak koruyarak modüler monolite taşıyın — aynı arayüzler, ama artık ağ sıçraması yerine fonksiyon çağrısı. Tasarım disiplinini tutar, arıza modlarını (ve mesh konfigürasyonunu) silersiniz.
  • 4. Hakkını vereni tutun. Gerçekten bağımsız ölçekleme profilleri, izolasyon/uyumluluk sınırları, farklı runtime'lar ya da sert ekip-özerkliği ihtiyaçları — o servisler kalır. Konsolidasyon budamadır, yıkım değil.
  • 5. Sonucu ölçün. Haftalık nöbet çağrısı, deploy süresi, p95 gecikme ve altyapı faturası — önce ve sonra. Yürüttüğümüz konsolidasyonlarda ilk ikisi en hızlı oynar; yakışıyor da, çünkü onlar kortizol metrikleridir.

Sık sorulan sorular

Kaç mikroservisimiz olmalı?
Savunulabilir pratik kural: ekip sayınız mertebesinde — her servis uçtan uca tek ekibin malı — artı gerçekten bağımsız ölçekleme, izolasyon ya da runtime ihtiyacı olan nadir istisnalar. Mühendis başına yirmi servis mimari değil, enflasyondur.

2026'da mikroservisler öldü mü?
Hayır. Gerçek ölçekte — çok ekip, bağımsız ölçekleme alanları — hâlâ doğru araç. Biten şey mikroservisin varsayılan olması; modüler monolit artık saygın başlangıç noktası, servis çıkarma ise kanıtlanmış ihtiyaca bağlı.

Mikroservisleri kesintisiz birleştirebilir miyiz?
Evet — tersine strangler deseni: kodu aynı arayüzlerin arkasında konsolide deployable'a taşıyın, trafiği kademeli kaydırın, eski servis sessizleşince emekli edin. Sıkıcı ve kademeli olması işin özü.

Kubernetes mikroservis gerektirir mi?
Hayır. Modüler monolit Kubernetes'te gayet iyi çalışır — mesh'i ve servisler arası ağ yükünün çoğunu attığınız için çoğu zaman daha ucuz ve güvenilir. Gerçek hayatta Kubernetes rehberimize bakın.

Özet

Meme komik, çünkü fatura gerçek: işlettiğiniz her servis operasyon, olay ve uykuyla ödenen bir kiradır. Bu kirayı yalnızca size bir şey satın aldığı yerde ödeyin — bağımsız ölçekleme, ekip özerkliği, izolasyon — kalanını iyi sınırlı modüllere konsolide edin. Hedef hiçbir zaman 700 servis ya da 1 servis değildi; kortizol ibresi gerçek ihtiyacınızla örtüşen bir mimariydi.

Enflasyon vergisi ödediğinizden mi şüpheleniyorsunuz? Maliyet Denetimimiz (€5.000 sabit) faturanızın mimari-şekilli kısmını rakamlandırır; pager'ı zaten yönetilen operasyon taşır. Ücretsiz sağlık taraması, konsolidasyonun yol haritanıza girip girmeyeceğini hızla söyler.

Etiketler: #Mikroservis #Monolit #Mimari #DevOps #BulutMaliyeti