Mikroservisler bir monolitin yükseltilmiş hâli değildir; bir takastır. Derleme zamanı bağımlılığını ağ çağrılarıyla, tek deployment'ı düzinelercesiyle, tek veritabanını dağıtık veri sahipliğiyle değiştirirsiniz. Bu takas belirli koşullarda karşılığını verir, geri kalan her yerde ağır bedel ödetir. On yıllık sektör deneyiminin — ve ekiplerin servisleri yeniden daha az sayıda deployable'da birleştirdiği güncel karşı akımın — ardından, 2026'daki dürüst soru "mikroservislere nasıl geçeriz?" değil, "onları bizim için değerli kılacak şey ne olurdu?" sorusudur.

Mikroservisler Size Gerçekte Ne Kazandırır

Bir uygulamayı bağımsız deploy edilebilir servislere bölmek dört şey kazandırır: bağımsız deployment (A ekibi, B ekibini beklemeden yayına çıkar), bağımsız ölçekleme (medya işleme servisi kırk replica ile koşarken faturalama ikisiyle boşta bekler), servis başına teknoloji seçimi ve arıza sınırlama — aşağıda önemli bir uyarıyla birlikte. Dikkat edin: bu faydaların her biri organizasyonel ve operasyonel bağımsızlıkla ilgilidir, ham performansla değil. Bir ağ sıçraması, her zaman bir fonksiyon çağrısından daha yavaş ve daha az güvenilirdir.

Mikroservisler Maliyetlerini Ne Zaman Hak Eder

  • Tek codebase'de çok fazla ekip. Deploy kuyrukları, release train'ler ve bitmeyen merge conflict'ler klasik sinyaldir. Conway yasası gerçektir: servis sınırları en iyi, ekip sınırlarını yansıttığında çalışır — mikroservislerin teknik olmaktan çok organizasyonel bir araç olmasının nedeni de budur.
  • Gerçekten farklı ölçekleme veya erişilebilirlik profilleri. Bir bileşen GPU node'lara ihtiyaç duyuyor ve trafiği 100 katına fırlıyor; gerisi öyle değil.
  • İzolasyon gereksinimleri. PCI veya regülasyona tabi veri işlemeyi küçük, denetlenebilir tek bir serviste tutmak uyumluluk kapsamını daraltır.
  • Kararlı, iyi anlaşılmış bir domain. Servis sınırlarını taşımak pahalıdır. Domain modeli hâlâ değişiyorsa, sınırları ağ sözleşmelerine dondurmak için henüz erkendir.

Bunların hiçbiri geçerli değilse — küçük bir ekip, evrilen bir ürün, standart CRUD iş yükleri — tüm maliyetleri üstlenir, faydaların hiçbirini alamazsınız. Minicik bir ekibin bir CRUD uygulaması için bir düzine servis işlettiğinde bunun nasıl sonuçlandığını belgeledik.

Çoğu Ekip Modüler Monolitle Başlamalı

Çoğu ekip için doğru başlangıç noktası modüler bir monolittir: tek deployable, katı modül sınırları, modül başına ayrı bir şema ve açıkça tanımlanmış süreç içi arayüzler üzerinden iletişim. Mikroservislerin tasarım disiplinini — bounded context'ler, net sözleşmeler, sahipli veri — dağıtık sistem vergisini ödemeden elde edersiniz. Bir modülün ileride kendi ölçekleme eğrisine veya release temposuna ihtiyacı olursa, dikiş yeri zaten hazırdır ve çıkarma işi büyük ölçüde mekaniktir. Sınırlar oturmadan bölmek, ekiplerin dağıtık monolitle baş başa kalmasının yoludur ve monoliti çok hızlı bölmek en sık gördüğümüz başarısızlık hikâyelerinden biridir.

Ayrıştırma Stratejileri

Teknik katmanlara veya veritabanı entity'lerine göre değil, iş yetkinliklerine (business capabilities) göre ayrıştırın. Domain-driven design'ın bounded context'leri buradaki pratik araçtır: bir servis, bir yetkinliğe uçtan uca sahip olmalıdır (fiyatlandırma, sipariş karşılama, kimlik) — böylece değişikliklerin çoğu tek serviste kalır. Entity bazlı bölmelerden kaçının: her istekte birbirini senkron çağırmak zorunda kalan bir "user service" ile "order service", bağımlılığı yalnızca ağın üzerine taşımıştır. Mevcut sistemler için strangler fig deseni işe yarar: monolitin önüne bir gateway koyun ve yetkinlikleri kademeli olarak soyarak taşıyın; her biri taşındıkça ilgili monolit kodunu emekliye ayırın.

Veri Sahipliği ve Dağıtık Transaction'lar

Her servis kendi veri deposuna sahiptir; başka hiçbir servis onu doğrudan okuyamaz veya yazamaz. Paylaşılan bir veritabanı, "mikroservisleri" dağıtık bir monolite çevirir. Bu kuralın bedeli, servisler arası tutarlılığın açık ve bilinçli bir çabaya dönüşmesidir: dağıtık transaction'lar saga pattern ile — başarısızlıkta telafi edici aksiyonları olan yerel transaction dizisi — ele alınır, güvenilir event yayınlama ise transactional outbox desenini kullanır. İşin izin verdiği yerlerde eventual consistency'yi kabul edin. Çekirdek bir iş akışı üç servis arasında gerçekten ACID garantisi gerektiriyorsa, bu genellikle two-phase commit'e ihtiyaç duyduğunuzun değil, sınırların yanlış olduğunun kanıtıdır.

Arıza İzolasyonu Tasarlanır, Bedava Gelmez

Arızalanan bir servis, sistemin geri kalanını kendiliğinden sağlam bırakmaz. Zincirleme arıza (cascading failure), en iyi belgelenmiş mikroservis arıza modlarından biridir: yavaşlayan bir downstream bağımlılık, tüm platform kilitlenene kadar upstream connection pool'ları ve thread pool'ları doldurur. İzolasyon mühendislikle kurulmalıdır — her uzak çağrıda timeout, circuit breaker'lar, bulkhead'ler, load shedding ve zarif bozulma (graceful degradation) — ve ardından fault-injection testleriyle doğrulanmalıdır. Mikroservislerin size varsayılan olarak dayanıklılık kazandırdığı yönündeki her iddia bir kırmızı bayrak sayılmalıdır.

Operasyonel Ön Koşullar

İlk servis çıkarılmadan önce platform altyapısı hazır olmalıdır: servis başına otomatik CI/CD; OpenTelemetry trace'leri, Prometheus metrikleri ve merkezî loglarla bütünleşik gözlemlenebilirlik (dağıtık tracing olmadan bir isteği on serviste debug etmek tahmin oyunudur); bir API gateway; servisler arası kimlik doğrulama (mTLS ya da servis sayısı ek yükünü haklı çıkardığında bir service mesh) ve kısmi arızalara hazır bir nöbet rotasyonu. DevOps danışmanlık ekibimiz bunları bir mikroservis migrasyonunun giriş kriterleri olarak ele alır, sonradan yapılacak işler olarak değil.

Özün Özü

Mikroservisler, yazılımı ölçeklemekten çok organizasyonları ölçeklemek için bir araçtır. Baskın sancı çok sayıda ekip arasındaki koordinasyon olduğunda ve operasyonel temel yerli yerindeyken benimseyin. O güne kadar, iyi modüllenmiş bir monolit daha hızlı yayına çıkar, işletmesi daha ucuza gelir ve tüm seçenekleri açık tutar.

Bunu production'da mı çalıştırıyorsunuz? AWS Yönetilen Hizmetler ekibimiz böyle ortamları 7/24 işletiyor — izleme, olay müdahalesi, yama ve maliyet kontrolü, ismen bildiğiniz kıdemli mühendislerle, aylık €3.000'den başlayan fiyatlarla.

Etiketler: #Mikroservisler #Mimari #DevOps #Ölçekleme