Monolitik Mimariden Mikroservislere Kurumsal Geçiş Stratejileri

Monolitik bir sistem büyüdükçe ilk refleks çoğu zaman onu mikroservislere bölmek oluyor. Fakat on yıllık yazılım mimarisi deneyimimde gördüğüm en önemli nokta şu: Mikroservis, büyüyen her uygulamanın doğal sonraki adımı değildir. Doğru problem için güçlü bir mimari yaklaşım olabilir, yanlış problem içinse maliyeti hızla artırabilir.

Bu rehberde Monolitik Mimariden Mikroservislere Kurumsal Geçiş Stratejileri konusunu yalnızca servis bölmek açısından ele almayacağız. Organizasyon yapısından veri sahipliğine, Strangler Fig Pattern yaklaşımından API Gateway kullanımına, observability altyapısından rollback planına kadar gerçek bir kurumsal dönüşümün parçalarını birlikte inceleyeceğiz.

Özellikle monolitik mimariden mikroservis mimarisine nasıl geçilir, kurumsal monolith migration stratejileri nelerdir ve mikroservis geçişinde domain decomposition API gateway veri tabanı migration ve observability nasıl birlikte yönetilir sorularına uygulanabilir yanıtlar bulacaksınız.

Monolitik Mimari Nedir?

Monolitik mimaride uygulamanın temel işlevleri genellikle tek bir deploy edilebilir yapı içinde bulunur. Kullanıcı yönetimi, sipariş, ödeme veya raporlama gibi farklı alanlar aynı uygulamanın parçaları olabilir.

Monolitik Uygulamanın Temel Özellikleri

Tek repository, ortak runtime, merkezi veri tabanı ve beraber yapılan deployment sık görülen özelliklerdir. Bu yapı küçük ve orta ölçekli ürünlerde geliştirme hızını ciddi biçimde destekleyebilir.

Monolith ile Big Ball of Mud Aynı Şey midir?

Hayır. Monolit olmak kötü tasarım anlamına gelmez. Modülleri açık biçimde ayrılmış bir monolit, sınırları belirsiz ve bağımlılıkları kontrolsüz bir sistemden tamamen farklıdır.

İyi Tasarlanmış Modular Monolith

Modular monolith yaklaşımında tek deploy birimi korunurken iş alanları net modüllere ayrılır. Bu model, ileride yalnızca gerçekten ihtiyaç duyulan modülleri ayrı servislere dönüştürmeyi kolaylaştırır.

Monolitik Mimari Ne Zaman Hâlâ Doğru Seçimdir?

Takım küçükse, deployment sıklığı yeterliyse ve ölçekleme sorunu belirli bileşenlerde yoğunlaşmıyorsa monolitik yapı hâlâ iyi bir seçenek olabilir. Mikroservise geçmek yerine mevcut sınırları iyileştirmek daha ekonomik olabilir.

Mikroservis Mimarisi Nedir?

Mikroservis mimarisi, sistemi yalnızca küçük uygulamalara ayırmak değildir. Esas amaç, belirli bir iş yeteneğinin bağımsız geliştirilebildiği, dağıtılabildiği ve işletilebildiği servis sınırları oluşturmaktır.

Independently Deployable Service

Gerçek bir mikroservis başka servislerin release takvimine bağlı kalmadan production ortamına alınabilmelidir. Her değişiklikte beş farklı takımın onayı gerekiyorsa servis sınırı yeniden değerlendirilmelidir.

Business Capability Ownership

Servis teknik katmana değil, mümkün olduğunca anlamlı bir business capability alanına sahip olmalıdır. Örneğin yalnızca controller servisi veya yalnızca repository servisi oluşturmak sağlıklı bir ayrışma değildir.

Service-Owned Data

Bir servisin davranışının yanında verisinin sahipliği de açık olmalıdır. Başka servislerin aynı tablolara doğrudan yazması bağımsızlığı kısa sürede ortadan kaldırır.

Autonomous Teams

Mikroservis yaklaşımı teknik sınırlar kadar ekip sınırlarıyla da ilgilidir. Bir ekip kendi servisinin geliştirme, deployment ve operasyon sorumluluğunu büyük ölçüde yönetebilmelidir.

Distributed Communication

Servisler arasındaki iletişim artık process içi method çağrısı değildir. Network, timeout, retry, mesaj sıralaması ve kısmi hata durumları mimarinin doğal parçası hâline gelir.

Monolitten Mikroservislere Neden Geçilir?

Geçiş kararı popüler bir mimari modeli uygulamak için değil, ölçülebilen problemleri çözmek için verilmelidir.

Yavaş Release Cycle

Küçük bir değişiklik için bütün uygulamanın test edilmesi ve yayınlanması gerekiyorsa bağımsız servisler release süresini azaltabilir.

Takımlar Arasında Yüksek Koordinasyon

Aynı kod tabanında çok sayıda ekip çalıştığında küçük değişiklikler bile koordinasyon maliyeti yaratabilir. Domain bazlı sahiplik bu bağımlılığı azaltabilir.

Bağımsız Ölçekleme İhtiyacı

Sistemin yalnızca belirli bir bölümü yüksek trafik alıyorsa bütün uygulamayı ölçeklemek gereksiz kaynak kullanımına neden olabilir. Ayrı servis bu alanın bağımsız ölçeklenmesini sağlar.

Kritik Domain'lerde Değişim Hızı

Ürünün rekabet gücünü belirleyen bazı alanlarda değişim diğer modüllerden çok daha hızlı olabilir. Bu alanların bağımsızlaşması ürün ekiplerine daha kısa teslim döngüsü kazandırabilir.

Deploy Riskinin Büyümesi

Monolit büyüdükçe tek deployment içinde değişen bileşen sayısı artabilir. Doğru servis ayrımıyla hata etkisi daha küçük bir alanda tutulabilir.

Teknoloji ve Organizasyonel Coupling

Her takımın aynı teknoloji kararına, aynı release takvimine ve aynı kod tabanına bağlı olması zamanla hareket alanını azaltabilir. Mikroservisler doğru organizasyon modeliyle bu bağımlılığı sınırlayabilir.

Mikroservise Gerçekten İhtiyacınız Var mı?

Bu soru migration projesinin en değerli sorusudur. Bazen sorun mimaride değil, süreçlerde veya ekip yapısındadır.

Architecture Gerçekten Bottleneck mi?

Önce teslim süresini neyin yavaşlattığını ölçün. Kod bağımlılığı mı, test süresi mi, onay süreci mi yoksa altyapı mı? Mimari değişiklik ancak gerçek darboğazı hedefliyorsa anlamlıdır.

Organizational Bottleneck

Bir kararın birçok ekipten geçmesi gerekiyorsa servis bölmek tek başına sorunu çözmeyebilir. Yetki ve sahiplik modeli de değişmelidir.

Process Bottleneck

Manuel test, uzun onay akışları veya düzensiz release süreçleri varsa önce delivery sürecini iyileştirmek daha hızlı sonuç verebilir.

Deployment Bottleneck

Deployment işlemi zor ve riskliyse CI/CD altyapısını geliştirmek, mikroservise geçmeden önce önemli bir kazanım sağlayabilir.

Önce Daha Basit Problemleri Düzeltmek

Bazen çözüm modülerleştirme, test otomasyonu, build iyileştirmesi veya database indekslemesidir. Büyük mimari değişiklik yalnızca gerekli olduğunda yapılmalıdır.

Microservice Premium Nedir?

Mikroservislerin sağladığı bağımsızlığın bir işletme maliyeti vardır. Bu ek maliyet, çoğu mimari ekip tarafından microservice premium olarak ifade edilir.

Distributed Systems Complexity

Process içi çağrılar network çağrılarına dönüştüğünde hata senaryoları artar. Timeout, retry ve mesaj teslim garantileri artık tasarım kararlarına girer.

Network Failures

Servis çalışıyor olsa bile ağ erişimi kesilebilir veya gecikebilir. Bu nedenle remote çağrıların başarısız olabileceği kabul edilerek tasarım yapılmalıdır.

Observability

Tek uygulamadaki logları incelemek yerine onlarca servisin metrics, logs ve traces verilerini ilişkilendirmek gerekir. Bu altyapı migration öncesinde düşünülmelidir.

Eventual Consistency

Dağıtık yapılarda bütün verilerin aynı anda güncel olması her zaman mümkün değildir. İş kuralları belirli gecikmeleri kabul edecek biçimde tasarlanmalıdır.

DevOps ve Platform Maliyeti

Servis sayısı arttıkça deployment pipeline, monitoring, secrets management ve runtime yönetimi için güçlü bir platform yaklaşımı gerekir.

Security Maliyeti

Servisler arası kimlik doğrulama, yetkilendirme ve network politikaları yeni güvenlik ihtiyaçları oluşturur. Güvenlik modeli merkezi düşünülmeli, uygulama ekiplerinin üzerine dağınık biçimde bırakılmamalıdır.

Hangi Ölçekte Bu Maliyet Gerekçelidir?

Bağımsız ekiplerin, farklı ölçekleme ihtiyaçlarının ve yüksek release frekansının sağladığı değer operasyon maliyetinden büyükse mikroservis yaklaşımı anlam kazanmaya başlar.

Mikroservise Geçmeden Önce Ölçülmesi Gereken Metrikler

Başlangıç metrikleri olmadan migration başarısını ölçmek zordur. Önce mevcut sistemin fotoğrafını çıkarın.

Lead Time for Changes

Bir değişikliğin geliştirmeden production ortamına ulaşmasına kadar geçen süreyi ölçün. Migration sonrasında aynı metriği karşılaştırın.

Deployment Frequency

Takımların ne kadar sık güvenli deployment yapabildiği önemli bir göstergedir.

Change Failure Rate

Release sonrasında rollback veya acil düzeltme gerektiren değişikliklerin oranı takip edilmelidir.

Mean Time to Recovery

Production sorunu ortaya çıktığında sistemin sağlıklı duruma dönme süresi operasyonel olgunluğu gösterir.

Build Süresi

Uzun build süreleri geliştirici geri bildirim döngüsünü yavaşlatır. Servis ayrımı bu süreyi düşürüyorsa ölçülebilir kazanım oluşur.

Test Süresi

Bütün sistem testinin saatler sürmesi release frekansını sınırlayabilir. Test stratejisi servis sınırlarıyla birlikte yeniden tasarlanmalıdır.

Cross-Team Coordination Sayısı

Bir özelliğin production ortamına çıkması için kaç ekip arasında koordinasyon gerektiğini ölçmek, organizasyonel coupling hakkında güçlü bir sinyal verir.

Mikroservis Migration Business Case'i

Kurumsal dönüşüm teknik ekiplerin tek başına yürüteceği bir proje değildir. Beklenen iş sonucunun açık olması gerekir.

Beklenen Business Outcome

Daha hızlı teslimat, daha yüksek availability veya belirli operasyon maliyetlerinin azaltılması gibi sonuçlar açık biçimde tanımlanmalıdır.

Cost of Delay

Mevcut mimari nedeniyle özelliklerin gecikmesinin kuruma ne kadara mal olduğu hesaplanmalıdır.

Migration TCO

Geliştirme süresi, altyapı, platform ekibi, monitoring, eğitim ve bakım giderleri toplam maliyet hesabına dahil edilmelidir.

Dual-Run Cost

Geçiş boyunca monolit ve yeni servislerin beraber çalışacağı dönem için çift işletim maliyeti hesaba katılmalıdır.

Beklenen ROI

Dönüşümün sağladığı hız, operasyonel verim ve ölçekleme avantajları maliyetle karşılaştırılmalıdır.

Başarı Kriterleri

Başarı servis sayısıyla değil, ölçülebilir sonuçlarla değerlendirilmelidir. Örneğin deployment süresinin azalması veya belirli domain için bağımsız release yapılabilmesi anlamlı kriterlerdir.

Modular Monolith Mikroservislerden Önce Düşünülmeli mi?

Çoğu kurum için evet. Modular monolith, kontrolsüz bir monolit ile dağıtık servisler arasında güçlü bir ara aşama olabilir.

Modular Monolith Nedir?

Uygulama tek deploy birimi olarak kalır ancak domain sınırları kod içinde açık biçimde ayrılır.

Explicit Module Boundaries

Bir modül başka modülün iç sınıflarına doğrudan erişmemelidir. İletişim tanımlı sınırlar üzerinden yapılmalıdır.

Internal API

Modüller arasındaki kontratlar internal API yaklaşımıyla açık hâle getirilebilir.

Database Ownership

Tek fiziksel veri tabanı kullanılsa bile hangi tabloların hangi modüle ait olduğu belirlenebilir.

Modular Monolith Ara Hedefi

Monoliti önce modülerleştirmek, servis çıkarma kararını daha güvenli hâle getirir. Çünkü gerçek domain sınırları uygulama içinde test edilmiş olur.

Hangi Modüller Gerçekten Microservice Olmalı?

Bağımsız değişim, farklı ölçekleme, ayrı ekip sahipliği veya yüksek business value sağlayan modüller güçlü adaylardır.

Big-Bang Migration Neden Risklidir?

Bütün sistemi tek seferde yeniden yazmak cazip görünebilir. Kurumsal sistemlerde bilinmeyen iş kuralları nedeniyle risk hızla büyür.

Uzun Feature Freeze

Yeniden yazım süresince mevcut ürüne özellik eklemek zorlaşabilir. İş birimleri aylarca beklemek zorunda kalabilir.

Büyük Cutover

Bütün trafiğin tek gecede yeni sisteme yönlendirilmesi hata etkisini büyütür.

Gizli Business Rule'lar

Yıllar içinde oluşmuş bazı kurallar dokümantasyonda değil, mevcut kodda veya operasyon alışkanlıklarında bulunabilir.

Rollback Problemi

Veri modeli tamamen değişmişse eski sisteme geri dönmek yalnızca önceki uygulama sürümünü açmak kadar kolay değildir.

Geciken Business Value

Big bang yaklaşımında yatırımın değeri genellikle projenin sonunda görülür. Kademeli geçişte ise her tamamlanan capability üretime alınabilir.

Incremental Migration Nedir?

Incremental migration, monoliti kontrollü parçalar hâlinde dönüştürmeyi hedefler.

Küçük Migration Slices

Her aşama belirli bir capability veya kullanıcı akışını kapsamalıdır.

Continuous Delivery

Yeni servislerin sık ve güvenli biçimde production ortamına çıkarılması dönüşüm süresini kısaltır.

Monolith + Microservices Coexistence

Geçiş döneminde eski ve yeni sistemin beraber çalışması normaldir. Ama bu beraberliğin geçici olduğu ve nasıl sona ereceği planlanmalıdır.

Her Adımda Business Value

Her migration diliminin ölçülebilir bir iş sonucu üretmesi projenin finansal sürdürülebilirliğini artırır.

Strangler Fig Pattern

Strangler Fig Pattern ile monolitik sistem mikroservislere nasıl dönüştürülür sorusunun temel yanıtı, eski sistemi bir anda değiştirmek yerine trafiği adım adım yeni yapılara taşımaktır.

Transform

Önce seçilen capability için yeni servis geliştirilir ve gerekli entegrasyon katmanı hazırlanır.

Coexist

Yeni servis ve monolit belirli bir süre beraber çalışır. Trafik kontrollü biçimde iki yapı arasında yönlendirilir.

Eliminate

Yeni servis kararlı hâle geldiğinde monolitte aynı işi yapan eski kod ve veri erişimleri kaldırılır.

Neden Big-Bang'den Daha Düşük Risklidir?

Değişim küçük adımlara bölündüğü için hata etkisi sınırlanır ve gerektiğinde trafik eski sisteme döndürülebilir.

Strangler Façade Mimarisi

Strangler yaklaşımında consumer ile sistem arasına yönlendirme yapabilen bir katman koymak geçişi kolaylaştırır.

Consumer

Web uygulaması, mobil istemci veya harici sistem yeni ve eski servis ayrıntılarını bilmek zorunda kalmamalıdır.

API Gateway / Reverse Proxy

API Gateway veya reverse proxy gelen isteği monolite ya da yeni mikroservise yönlendirebilir.

Legacy Monolith

Henüz taşınmamış capability alanları çalışmaya devam eder.

New Microservices

Taşınan capability alanları bağımsız servisler üzerinden sunulur.

Routing Policy

Yönlendirme endpoint, kullanıcı grubu, tenant, feature flag veya trafik yüzdesine göre yapılabilir.

Legacy'yi Consumer'dan Gizlemek

Consumer'ın eski veya yeni backend yapısını bilmemesi migration sürecinde istemci değişikliklerini azaltır.

Strangler Fig Ne Zaman Uygun Değildir?

Çok Küçük Uygulamalar

Küçük bir uygulamada geçiş altyapısının maliyeti sağlayacağı faydadan yüksek olabilir.

Request Routing Yapılamayan Sistemler

İşlem sınırlarının yönlendirilemediği bazı legacy yapılarda farklı migration yaklaşımı gerekebilir.

Çok Kısa Kalan Sistem Ömrü

Sistem yakın zamanda tamamen kapatılacaksa kapsamlı dönüşüm yatırımı anlamlı olmayabilir.

Coexistence Maliyetinin Çok Yüksek Olması

İki sistemi aynı anda çalıştırmanın veri veya altyapı maliyeti kabul edilemez seviyedeyse farklı cutover modeli değerlendirilebilir.

Monoliti Nasıl Analiz Etmelisiniz?

Servis sınırları kod dosyalarına bakılarak belirlenmemelidir. Teknik ve iş bağımlılıklarını birlikte görmek gerekir.

Code Dependency Graph

Modüllerin ve paketlerin birbirine hangi yönde bağımlı olduğunu gösterir.

Database Dependency Graph

Hangi modüllerin hangi tabloları okuduğu ve yazdığı ortaya çıkarılmalıdır.

Runtime Call Graph

Production ortamındaki gerçek çağrı zincirleri statik kod analizinde görünmeyen bağımlılıkları gösterebilir.

Business Process Map

Kullanıcının veya operasyon ekibinin tamamladığı iş akışları domain sınırlarını anlamaya yardımcı olur.

Team Ownership Map

Hangi ekiplerin hangi kod ve business capability alanlarından sorumlu olduğu haritalanmalıdır.

Change Frequency Map

Sık birlikte değişen kod parçaları güçlü bir cohesion sinyali verir.

Business Capability Mapping

Business Capability Nedir?

Bir kurumun iş sonucunu üretmek için sahip olduğu yetenektir. Sipariş yönetimi veya müşteri kimliği buna örnek olabilir.

Technical Layer Yerine Business Capability

Servisleri frontend, backend veya database gibi teknik katmanlara bölmek yerine iş yetenekleri etrafında sınırlandırmak daha sağlıklı sonuç verir.

Value Stream Analizi

Bir müşteri talebinin baştan sona nasıl değere dönüştüğünü incelemek servis sınırlarını görünür hâle getirir.

Product Ownership

Her capability için ürün ve teknik sahipliğin açık olması bağımsız karar alma sürecini destekler.

Domain-Driven Design ile Service Boundary Bulmak

Domain Driven Design, teknik yapıyı iş diline yaklaştırarak servis sınırlarını belirlemede güçlü bir çerçeve sunar.

Domain

Domain, yazılımın çözmeye çalıştığı iş alanının bütünüdür.

Subdomain

Domain daha yönetilebilir alt alanlara ayrılabilir.

Core Domain

Kuruma esas rekabet avantajını sağlayan iş alanıdır ve genellikle en fazla tasarım odağını hak eder.

Supporting Domain

Core domain'i destekleyen ancak tek başına temel rekabet avantajı oluşturmayan alandır.

Generic Domain

Birçok kurumda benzer biçimde çözülebilen genel iş ihtiyaçlarını ifade eder.

Bounded Context

Belirli bir domain modelinin geçerli olduğu açık sınırdır. Mikroservis adayı belirlerken en değerli kavramlardan biridir.

Aggregate

Tutarlılık kurallarının birlikte korunduğu domain nesneleri grubudur. Transaction sınırlarını anlamaya yardımcı olur.

Context Map

Farklı bounded context alanlarının birbirleriyle nasıl ilişki kurduğunu görünür hâle getirir.

Event Storming ile Monolit Decomposition

Event Storming oturumları teknik ekip, ürün ekibi ve domain uzmanlarını aynı süreç üzerinde buluşturabilir.

Domain Events

İş açısından önemli ve geçmiş zamanda ifade edilen olaylar belirlenir. Örneğin sipariş oluşturuldu gibi.

Commands

Bir domain event meydana gelmeden önce hangi komutun verildiği incelenir.

Actors

Komutu hangi kullanıcı, sistem veya operasyon rolünün başlattığı belirlenir.

Aggregates

Kuralları uygulayan ve state değişimini yöneten domain yapıları tanımlanır.

Policies

Bir event sonrasında hangi otomatik kararların veya yeni komutların oluştuğu modellenir.

Bounded Context Candidates

Birbirine yakın event, command ve policy grupları olası servis sınırları için güçlü adaylar oluşturabilir.

Service Boundary Karar Matrisi

Business Cohesion

Aynı iş sonucuna hizmet eden davranışların beraber kalması tercih edilir.

Technical Coupling

Çok yoğun teknik bağımlılık varsa servis ayrımı yüksek iletişim maliyeti oluşturabilir.

Data Coupling

Aynı veriye sürekli transaction seviyesinde ihtiyaç duyan alanların erken ayrılması risklidir.

Change Frequency

Sık birlikte değişen bileşenler çoğu zaman aynı boundary içinde kalmalıdır.

Scaling Requirement

Belirli capability diğerlerinden çok daha farklı ölçekleniyorsa bağımsız servis güçlü bir seçenek olabilir.

Team Ownership

Servis sınırının sorumluluğunu üstlenebilecek net bir ekip bulunmalıdır.

Transaction Boundary

Güçlü ACID transaction ihtiyacı aynı servis içinde kalması gereken davranışları gösterebilir.

“Go Macro First, then Micro”

Neden İlk Servisler Daha Büyük Olmalı?

İlk aşamada biraz daha geniş servis sınırları yönetim maliyetini azaltır ve domain hakkında öğrenme alanı bırakır.

Nano-Service Anti-Pattern

Çok küçük servisler network çağrısını, deployment sayısını ve operasyon yükünü gereksiz artırabilir.

Operasyonel Olgunluk Arttıkça Servisleri Bölmek

Platform yetenekleri geliştikçe gerçekten bağımsız değişim ihtiyacı gösteren servisler daha küçük alanlara ayrılabilir.

Service Size İçin Doğru Metrik

Kod satırı sayısı yerine bağımsız iş sorumluluğu ve değişim nedeni değerlendirilmelidir.

İlk Microservice Nasıl Seçilir?

Fairly Decoupled Capability

İlk servis, monolitin geri kalanından makul ölçüde ayrılabilen bir capability olmalıdır.

Düşük Dependency

Çok sayıda tabloya ve modüle bağlı bir alan ilk deneme için uygun değildir.

Yüksek Learning Value

Seçilen servis CI/CD, monitoring, güvenlik ve data ownership süreçlerini gerçek ortamda test etmeyi sağlamalıdır.

Yönetilebilir Business Risk

İlk servis kritik olmalı ancak olası bir hatanın işletmeyi durduracağı kadar yüksek risk taşımamalıdır.

Gerçek Production Traffic

Sadece demo trafik alan servisler operasyonel öğrenme sağlamaz. Gerçek kullanıcı trafiği kontrollü biçimde servise yönlendirilmelidir.

İlk Microservice İçin Walking Skeleton

Repository

Kod sahipliği ve geliştirme akışı açık bir repository düzeniyle başlamalıdır.

CI/CD

Build, test ve deployment süreçleri otomatik olmalıdır.

Deployment

Servisin production ortamına güvenli biçimde çıkarılabildiği kanıtlanmalıdır.

API

Servis kontratı açıkça tanımlanmalı ve versiyonlama yaklaşımı belirlenmelidir.

Security

Authentication, authorization ve secret yönetimi başlangıçtan itibaren dahil edilmelidir.

Database

Servisin hangi verinin sahibi olduğu açık biçimde belirlenmelidir.

Telemetry

Metrics, logs ve traces olmadan servis production ortamına hazır kabul edilmemelidir.

Production Traffic

Walking skeleton gerçek trafik alarak uçtan uca platform kabiliyetini doğrulamalıdır.

Yeni Service'in Monolite Bağımlılığını Azaltmak

Data Dependency

Yeni servisin monolit tablolarına doğrudan erişmesi mümkün olduğunca engellenmelidir.

Logic Dependency

İş kurallarının önemli bölümü hâlâ monolitte çalışıyorsa servis yalnızca uzak bir proxy hâline gelebilir.

Release Dependency

Yeni servis değiştiğinde monolit de aynı anda deploy edilmek zorundaysa bağımsızlık henüz oluşmamıştır.

API Dependency

Gereksiz sayıda monolit API çağrısı chatty communication üretir.

Dependency Direction'ı Tersine Çevirmek

Mümkün olduğunda yeni servis eski yapıya bağımlı olmak yerine legacy sistemin yeni servisin sağladığı kontratı kullanacağı model hedeflenmelidir.

Anti-Corruption Layer

Legacy Domain Model

Legacy sistemde yıllar içinde oluşmuş kavramlar yeni modelle birebir uyuşmayabilir.

Modern Domain Model

Yeni servis kendi iş dilini ve veri modelini açık biçimde korumalıdır.

Translation Layer

İki model arasındaki dönüşüm ayrı bir katmanda gerçekleştirilir.

Legacy Kavramların Yeni Service'e Sızmasını Önlemek

Anti Corruption Layer, yeni servisin eski sistemdeki isimlendirme ve model kararlarına kalıcı biçimde bağlanmasını önler.

Sticky Capability'leri Erken Çözmek

Shared Session

Ortak session state servislerin bağımsızlaşmasını zorlaştırabilir. Merkezi session bağımlılığı erken aşamada ele alınmalıdır.

Shared User Context

Kullanıcı bilgisi her servisin legacy sistemden sorguladığı bir bağımlılık hâline gelmemelidir.

Global Configuration

Bütün servislerin tek config kaynağına güçlü biçimde bağlanması operasyonel bağımsızlığı azaltabilir.

Shared Authorization

Yetkilendirme politikalarının sahipliği ve servisler tarafından nasıl uygulanacağı açık olmalıdır.

Çok Sayıda Modülün Bağımlı Olduğu Domain Kavramları

Müşteri, ürün veya kimlik gibi merkezi kavramlar çok sayıda bağımlılık taşıyabilir. Bunları erken analiz etmek ileride oluşacak blokajları azaltır.

Database Monolitini Parçalamak

Mikroservis dönüşümünün en zor bölümlerinden biri çoğu zaman kod değil veridir.

Shared Database Problemi

Servislerin aynı tablolara doğrudan erişmesi bağımsız deployment ve veri sahipliğini bozar.

Table Ownership

Her tablonun hangi servis veya modüle ait olduğu açıkça belirlenmelidir.

Schema Ownership

Fiziksel database ayrılmadan önce schema seviyesinde sahiplik uygulanabilir.

Database per Service

Her servis kendi verisini kendi kontratı üzerinden yönetir. Bu model mutlaka ayrı fiziksel sunucu anlamına gelmez.

Data Access Sadece Service API Üzerinden

Başka servisler veriye doğrudan SQL ile erişmek yerine servis API veya event kontratlarını kullanmalıdır.

Database per Service Tam Olarak Ne Demektir?

Private Tables per Service

Aynı database içinde farklı servisler kendi tablolarına sahip olabilir.

Schema per Service

Servis başına ayrı schema, logical ownership sağlamak için kullanılabilir.

Database Server per Service

Yüksek izolasyon gereken durumlarda fiziksel database ayrımı tercih edilebilir.

Polyglot Persistence

Her servis kendi erişim modeline uygun veri teknolojisini seçebilir ancak bunun işletme maliyeti dikkate alınmalıdır.

Physical Database ile Logical Ownership Farkı

Asıl hedef fiziksel ayrım değil, veri üzerindeki değişiklik yetkisinin tek bir servis tarafından yönetilmesidir.

Shared Database'den Kademeli Çıkış

Önce Ownership Belirlemek

Hangi tablo ve kolonların hangi capability alanına ait olduğu belirlenmeden migration başlamamalıdır.

Direct DB Access'i Kapatmak

Yeni doğrudan erişimlerin önüne geçmek teknik borcun büyümesini durdurur.

API Oluşturmak

Verinin sahibi olan servis kontrollü erişim için API veya event kontratı sunar.

Read Path'i Taşımak

Önce okuma trafiğinin yeni servise taşınması düşük riskli bir başlangıç olabilir.

Write Path'i Taşımak

Yazma sahipliği kontrollü biçimde yeni servise geçirilir.

Eski Tabloları Retire Etmek

Consumer sayısı sıfıra ulaştığında legacy tablolar arşivleme ve audit politikalarına uygun biçimde kapatılır.

Veri Migration Stratejileri

Offline ETL

Sistem durdurulabiliyorsa veri belirli bir bakım penceresinde taşınabilir.

Online Migration

Kesintinin kabul edilmediği sistemlerde eski ve yeni veri modeli geçiş boyunca beraber çalışabilir.

Change Data Capture

Database değişiklikleri log seviyesinden yakalanarak yeni veri deposuna aktarılabilir.

Event-Based Replication

Domain event'leri kullanılarak servisler ihtiyaç duydukları verinin kendi kopyasını oluşturabilir.

Backfill

Mevcut geçmiş veri yeni sisteme toplu biçimde aktarılır.

Reconciliation

Eski ve yeni sistemdeki kayıtların tutarlılığı periyodik karşılaştırmalarla doğrulanmalıdır.

Dual Write Problemi

Database + Database

Aynı işlem sırasında iki database'e yazmak, ikinci yazmanın başarısız olması durumunda tutarsızlık oluşturabilir.

Database + Message Broker

Database işlemi başarılı olup mesaj gönderimi başarısız olduğunda event kaybolabilir.

Partial Failure

Dağıtık sistemde işlemin bazı parçalarının başarılı, bazılarının başarısız olması normal bir hata senaryosudur.

Retry

Geçici hatalar yeniden deneme ile çözülebilir ancak kontrolsüz retry yeni sorunlara yol açabilir.

Idempotency

Aynı işlemin birden fazla kez çalıştırılması sonucu değiştirmemelidir.

Transactional Outbox

Business Transaction

İş verisi ve yayınlanacak event bilgisi aynı local transaction içinde kaydedilir.

Outbox Record

Gönderilecek mesaj ayrı bir outbox tablosuna yazılır.

Message Relay

Arka plandaki süreç outbox kayıtlarını message broker'a iletir.

At-Least-Once Delivery

Mesaj birden fazla kez teslim edilebileceği için consumer tarafı buna göre tasarlanmalıdır.

Idempotent Consumer

Consumer aynı mesajı tekrar aldığında ikinci kez iş etkisi oluşturmamalıdır.

Distributed Transaction Problemi

Monolitik ACID Transaction

Monolitte tek database transaction ile çözülen işlem mikroservislerde birden fazla servis sınırına yayılabilir.

Local Transactions

Her servis yalnızca kendi verisi üzerinde local transaction yönetmelidir.

Eventual Consistency

Servislerin state bilgileri belirli bir süre farklı olabilir ancak sonunda beklenen tutarlı duruma ulaşmalıdır.

Compensation

İşlemin sonraki adımı başarısız olursa daha önce tamamlanan adımın iş etkisini geri alan operasyon uygulanabilir.

Saga Pattern

Choreography

Servisler event'lere tepki vererek süreci merkezi koordinatör olmadan ilerletir.

Orchestration

Merkezi bir orchestrator hangi servisin hangi adımı gerçekleştireceğini yönetir.

Compensating Transactions

Başarılı adımlar gerektiğinde karşıt işlemlerle telafi edilir.

Saga Ne Zaman Kullanılmalı?

Tek bir business transaction birden fazla servis sahipliğindeki veriyi değiştirmek zorundaysa değerlendirilebilir.

Saga Complexity Riski

Basit işlemleri gereksiz yere Saga ile çözmek bakım ve hata ayıklama maliyetini artırır.

Synchronous ve Asynchronous Communication

REST / gRPC

Anlık yanıt gereken request response akışlarında REST veya gRPC uygun olabilir.

Events

Bir iş olayının birçok consumer tarafından bağımsız işlenmesi gerekiyorsa event yaklaşımı güçlüdür.

Message Queue

İş yükünü asenkron işlemek ve producer ile consumer hızını ayırmak için message queue kullanılabilir.

Request/Response Ne Zaman Doğru?

Kullanıcının işlemin sonucuna hemen ihtiyaç duyduğu kısa çağrılar için doğru seçim olabilir.

Event Ne Zaman Doğru?

Producer'ın consumer sonucunu beklemesi gerekmiyorsa ve gevşek bağımlılık isteniyorsa event tercih edilebilir.

Distributed Monolith Anti-Pattern

Çok Uzun Sync Call Chain

Bir kullanıcı isteğinin peş peşe birçok servisi çağırması latency ve hata olasılığını artırır.

Shared Database

Farklı servisler aynı tablolara doğrudan yazıyorsa fiziksel ayrışma bağımsızlık sağlamaz.

Coordinated Deployment

Bir servis release edildiğinde diğer servislerin de aynı anda deploy edilmesi gerekiyorsa servisler pratikte birlikte hareket ediyor demektir.

Chatty Services

Bir işlemi tamamlamak için çok sayıda küçük network çağrısı gerekiyorsa boundary yanlış belirlenmiş olabilir.

Shared Business Logic

İş kurallarının birçok serviste kopyalanması değişiklik yönetimini zorlaştırır.

Ortak Release Takvimi

Tüm servislerin tek release takvimine bağlı olması mikroservislerin temel avantajlarından birini ortadan kaldırır.

Service-to-Service Resilience

Timeout

Her remote çağrının makul bir timeout değeri olmalıdır. Sonsuz bekleme zincirleme kaynak tüketimine yol açabilir.

Retry

Yalnızca geçici ve yeniden denenebilir hatalarda kullanılmalıdır.

Exponential Backoff

Retry aralığını giderek artırmak problem yaşayan servisin daha fazla yük altında kalmasını önleyebilir.

Circuit Breaker

Sürekli hata veren dependency için çağrıları geçici olarak durdurur.

Bulkhead

Bir dependency probleminden kaynaklanan kaynak tüketiminin bütün servisi etkilemesini sınırlar.

Rate Limiting

Servisin kaldırabileceği trafik seviyesini korumaya yardımcı olur.

Idempotency

Retry Edilebilir Operasyonlar

Network hatası nedeniyle client aynı isteği tekrar gönderebilir. Operasyon buna hazır olmalıdır.

Idempotency Key

Client tarafından gönderilen benzersiz anahtar tekrar eden işlemlerin tespit edilmesini sağlar.

Payment Örneği

Aynı ödeme isteğinin iki kez ulaşması müşteriden iki kez tahsilat yapılmasına neden olmamalıdır.

Order Creation Örneği

Aynı sipariş oluşturma isteği tekrarlandığında ikinci sipariş yerine önceki sonuç döndürülebilir.

API Contract Yönetimi

OpenAPI

HTTP API kontratları OpenAPI ile makine tarafından okunabilir biçimde tanımlanabilir.

Protobuf

gRPC tabanlı iletişimde güçlü tip ve schema yönetimi sağlar.

AsyncAPI

Event ve message tabanlı kontratların dokümantasyonu için kullanılabilir.

Schema Registry

Event schema sürümlerinin merkezi olarak yönetilmesini ve uyumluluk kontrollerini sağlar.

Breaking Change Policy

Bir provider değişikliğinin consumer'ları kırmaması için kurum genelinde açık politika tanımlanmalıdır.

API Versioning ve Backward Compatibility

Additive Changes

Mevcut alanları kaldırmak yerine yeni alan eklemek çoğu durumda daha güvenli değişiklik modelidir.

Deprecation

Eski kontratın ne zaman kaldırılacağı consumer'lara önceden bildirilmelidir.

Consumer Inventory

Bir API'nin kimler tarafından kullanıldığını bilmeden güvenli deprecation yapmak zordur.

Sunset Policy

Eski versiyonların ne kadar süre destekleneceği açık bir takvimle yönetilmelidir.

Consumer-Driven Contract Testing

Provider Contract

Provider'ın sunduğu API davranışı otomatik testlerle doğrulanır.

Consumer Expectations

Consumer'ın gerçekten kullandığı alan ve davranışlar kontrata yansıtılır.

CI Compatibility Check

Breaking change production ortamına çıkmadan CI aşamasında yakalanabilir.

Independent Deployment

Contract testleri servislerin birbirini beklemeden güvenli release yapabilmesini destekler.

Event Contract Governance

Event Schema

Event payload yapısı açık ve versiyonlanabilir olmalıdır.

Event Ownership

Event'in sahibi onu üreten domain servisidir.

Schema Evolution

Yeni alanlar consumer uyumluluğunu bozmayacak şekilde eklenmelidir.

Consumer Compatibility

Schema değişikliği öncesinde mevcut consumer'ların etkisi değerlendirilmelidir.

Event Deprecation

Kullanılmayan event tipleri takip edilmeli ve kontrollü biçimde kaldırılmalıdır.

Platform Engineering Mikroservis Geçişinde Neden Gereklidir?

Cognitive Load

Her ürün ekibinin container, monitoring ve deployment altyapısını sıfırdan öğrenmesi beklenmemelidir.

Self-Service Infrastructure

Ekiplerin standart altyapıyı merkezi destek beklemeden oluşturabilmesi delivery hızını artırır.

Golden Paths

Yaygın senaryolar için güvenli ve kolay kullanılan varsayılan geliştirme yolları sağlanmalıdır.

Standard Service Templates

Yeni servisler logging, health check ve security gibi temel ihtiyaçlarla hazır başlamalıdır.

Central Governance

Merkezi ekip standartları belirlerken ürün ekiplerinin domain kararlarını gereksiz biçimde yavaşlatmamalıdır.

Microservice Golden Path

Create Repository

Standart repository şablonu birkaç adımda oluşturulabilmelidir.

Build

Build işlemi ortak pipeline üzerinden tekrarlanabilir olmalıdır.

Test

Minimum test kalite eşiği otomatik biçimde uygulanmalıdır.

Security Scan

Dependency ve container kontrolleri pipeline'ın doğal parçası olmalıdır.

Deploy

Servis standart yöntemle development, staging ve production ortamlarına taşınabilmelidir.

Observe

Servis yayınlandığı anda metrics, logs ve traces görünür olmalıdır.

Roll Back

Güvenli geri dönüş yöntemi servisin ilk production release'inden önce test edilmelidir.

Yeni Service Template'inde Neler Olmalı?

CI/CD Pipeline

Build, test ve deployment adımlarını otomatikleştirmelidir.

Container Configuration

Resource limit, health check ve güvenli runtime ayarları standartlaştırılabilir.

Health Endpoints

Liveness ve readiness bilgileri operasyon altyapısına sunulmalıdır.

Metrics

Temel latency, error ve throughput metrikleri varsayılan olarak üretilmelidir.

Distributed Tracing

Request akışının servisler boyunca izlenebilmesi için trace context taşınmalıdır.

Structured Logging

Loglar makine tarafından sorgulanabilir ortak alanlara sahip olmalıdır.

Security Baseline

Authentication, secret yönetimi ve minimum erişim kuralları template içinde hazır bulunmalıdır.

Kubernetes Mikroservis İçin Zorunlu mudur?

Hayır. Mikroservis bir deployment platformu değil, mimari yaklaşımdır.

Managed Container Platforms

Daha düşük operasyon yükü isteyen ekipler yönetilen container platformlarını değerlendirebilir.

Kubernetes

Yüksek servis sayısı ve gelişmiş orchestration ihtiyacında güçlü olabilir ancak yönetim maliyeti dikkate alınmalıdır.

Serverless

Event tabanlı veya değişken trafikli bazı servisler için uygun olabilir.

VM-Based Services

Operasyon ekibinin mevcut yetkinlikleri uygunsa sanal makineler üzerinde servis çalıştırmak da geçerli bir seçenektir.

Operational Complexity'e Göre Platform Seçimi

Platform, moda olan teknolojiye göre değil kurumun ölçeği, ekip yetkinliği ve operasyon ihtiyacına göre seçilmelidir.

API Gateway'in Rolü

External Routing

Dış istemci trafiğini doğru backend servisine yönlendirir.

Authentication

Kimlik doğrulama için merkezi giriş noktası sağlayabilir.

Rate Limiting

İstemci veya endpoint bazlı trafik sınırları uygulayabilir.

Legacy ve Modern Traffic Routing

Migration sırasında bazı endpoint'leri monolite, bazılarını yeni servislere yönlendirmek için kullanılabilir.

Strangler Façade

Consumer ile legacy sistem arasına yerleşerek kademeli trafik geçişini mümkün kılar.

Yüksek trafikli sistemlerde backend ölçekleme yaklaşımını daha ayrıntılı incelemek isterseniz Diyarbakır Yazılım Topluluğu tarafından hazırlanan https://www.diyarbakiryazilim.com.tr/posts/yuksek-trafikli-sitelerde-olceklenebilir-backend-tasarimi içeriğine de göz atabilirsiniz.

Service Mesh Ne Zaman Gerekir?

mTLS

Servisler arasındaki bağlantının karşılıklı sertifika doğrulamasıyla korunması gerekiyorsa mesh katkı sağlayabilir.

Retry

Network seviyesindeki bazı retry politikaları ortak biçimde yönetilebilir.

Circuit Breaking

Servis bağımlılıklarına yönelik koruma politikaları merkezi uygulanabilir.

Traffic Management

Canary veya sürüm bazlı trafik yönlendirme senaryolarını destekleyebilir.

Telemetry

Servisler arası network iletişimi için ortak gözlem verileri üretebilir.

Mesh Complexity Budget

Service mesh ek bir platform katmanıdır. Gerçek ihtiyaç oluşmadan eklenmesi önerilmez.

Mikroservis Security Modeli

Zero Trust

Network içinde bulunmak tek başına güvenilirlik anlamına gelmemelidir.

Workload Identity

Her servis kendi doğrulanabilir kimliğine sahip olmalıdır.

Service-to-Service Authentication

Servisler birbirlerini güvenli biçimde doğrulayabilmelidir.

Authorization

Kimliği doğrulanan servisin hangi işlemleri yapabileceği ayrıca kontrol edilmelidir.

Secrets Management

Parola, API key ve sertifikalar kod içinde tutulmamalıdır.

Network Policies

Servislerin yalnızca ihtiyaç duydukları hedeflerle iletişim kurabilmesi tercih edilmelidir.

Observability Geçişten Önce Kurulmalı

Servisleri ayırdıktan sonra gözlem altyapısı kurmaya çalışmak hata araştırmasını gereksiz yere zorlaştırır.

Metrics

Latency, error rate, throughput ve resource kullanımı takip edilmelidir.

Logs

Log formatı servisler arasında ortak olmalı ve merkezi sorgulanabilmelidir.

Traces

Bir request'in farklı servislerde hangi adımlardan geçtiği takip edilebilmelidir.

Common Service Naming

Servis isimleri deployment, log ve monitoring sistemlerinde aynı standardı kullanmalıdır.

Correlation ID

Bir iş akışına ait log kayıtlarını servisler arasında ilişkilendirmeye yardımcı olur.

Context Propagation

Trace ve correlation bilgileri bütün servis çağrılarında taşınmalıdır.

Distributed Tracing

Trace

Bir request'in sistem boyunca yaptığı yolculuğun tamamını temsil eder.

Span

Trace içindeki tek bir operasyonu veya servis çağrısını temsil eder.

Parent Child Relationship

Span ilişkileri çağrı sırasını ve hangi operasyonun hangisini başlattığını gösterir.

Cross-Service Context Propagation

Trace bilgisinin HTTP header veya mesaj metadata alanlarında taşınması gerekir.

OpenTelemetry

Metrics, logs ve traces üretimi için vendor bağımsız standart sağlayabilir.

Service SLO'ları

Availability

Servisin beklenen zaman diliminde erişilebilir olma hedefidir.

P95/P99 Latency

Ortalama latency tek başına yeterli değildir. Kuyruk uçlarındaki kullanıcı deneyimi de izlenmelidir.

Error Rate

Başarısız request oranı SLO kapsamında tanımlanmalıdır.

Throughput

Servisin belirli sürede işleyebildiği request veya event sayısı takip edilmelidir.

Dependency SLO'ları

Bir servisin kendi hedefi bağımlı olduğu servislerin performansından etkilenir.

Error Budget

Kabul edilebilir hata payı release hızı ile reliability arasında dengeli karar verilmesini sağlayabilir.

Monolit ve Microservice Performansını Karşılaştırmak

Baseline

Migration öncesindeki latency ve throughput değerleri kaydedilmelidir.

Network Overhead

Process içi çağrının network çağrısına dönüşmesi doğal ek süre oluşturur.

Serialization

Request ve response verisinin encode edilmesi işlem maliyetine eklenir.

Database Calls

Servis ayrımı yanlış yapılırsa tek işlem için database çağrı sayısı artabilir.

Distributed Latency

Birden fazla remote dependency toplam yanıt süresini etkiler.

P99 Tail Latency

Özellikle yüksek trafikli sistemlerde en yavaş küçük yüzdelik dilim kullanıcı deneyimini ciddi biçimde etkileyebilir.

Mikroservis Test Stratejisi

Unit Testing

Domain kuralları hızlı ve izole testlerle doğrulanmalıdır.

Component Testing

Servis kendi database veya adapter katmanlarıyla birlikte test edilebilir.

Contract Testing

Servisler arası API beklentilerinin uyumluluğunu doğrular.

Integration Testing

Gerçek dependency kombinasyonlarının doğru çalıştığını kontrol eder.

E2E Testing

Kritik kullanıcı akışları uçtan uca doğrulanır ancak bütün test stratejisi yalnızca E2E testlere dayanmamalıdır.

Performance Testing

Yeni servis production trafik profiline benzer yük altında ölçülmelidir.

Chaos Testing

Olgun sistemlerde dependency kesintisi veya latency artışı gibi senaryolar kontrollü biçimde test edilebilir.

Migration Safety Net

Characterization Tests

Legacy sistemin mevcut davranışını belgeleyen testler dönüşüm sırasında referans oluşturur.

Legacy Behavior Baseline

Yeni sistemin hangi davranışı koruması gerektiği ölçülebilir hâle getirilmelidir.

Response Comparison

Aynı request eski ve yeni sisteme gönderilerek sonuçlar karşılaştırılabilir.

Data Reconciliation

Veri farklılıkları otomatik raporlarla takip edilmelidir.

Regression Tests

Migration dilimleri mevcut iş akışlarının bozulmadığını doğrulamalıdır.

Shadow Traffic ile Microservice Doğrulama

Production Request Copy

Gerçek production request'lerinin kopyası yeni servise gönderilebilir.

Side Effect'leri Kapatmak

Shadow isteklerin ödeme, e posta veya veri yazımı gibi gerçek etkiler oluşturmaması gerekir.

Response Diff

Legacy ve yeni servis sonuçları otomatik karşılaştırılabilir.

Performance Comparison

Yeni servisin gerçek trafik altında latency ve resource kullanımı ölçülebilir.

Dark Launch

Production Deployment

Yeni servis production altyapısında çalışır ancak kullanıcı trafiği almaz.

Traffic = 0

Servisin ortam ve entegrasyon hazırlığı gerçek kullanıcı etkisi olmadan doğrulanabilir.

Internal Testing

İç kullanıcılar veya test ekipleri production ortamındaki yeni servisi kontrollü biçimde deneyebilir.

Feature Flag

Yeni davranış kullanıcı grubu veya koşula göre açılabilir.

Canary Migration

%1 Traffic

İlk küçük trafik grubu hata oranını düşük riskle ölçmeye yarar.

%5 Traffic

Temel metrikler sağlıklıysa trafik kontrollü olarak artırılır.

%20 Traffic

Daha yüksek gerçek yük altında performans ve dependency davranışı gözlenir.

%50 Traffic

Sistemin yarı trafik seviyesinde stabilitesi doğrulanır.

%100 Traffic

Başarı kriterleri sağlandığında capability tamamen yeni servise taşınır.

Her Aşamada Success Criteria

Error rate, latency, veri tutarlılığı ve business metric eşikleri önceden tanımlanmalıdır.

Cohort Bazlı Geçiş

Internal Users

İlk kullanıcı grubu kurum içinden seçilerek geri bildirim alınabilir.

Tenant

Çok kiracılı sistemlerde belirli tenant'lar yeni servise geçirilebilir.

Region

Trafik belirli coğrafi bölgeye göre ayrılabilir.

Customer Segment

Belirli müşteri segmentleri kontrollü migration grubu olarak kullanılabilir.

User ID

Deterministik routing ile aynı kullanıcı sürekli aynı backend'e yönlendirilebilir.

Feature Flags Migration Altyapısında Nasıl Kullanılır?

Traffic Routing

Yeni servis kullanıcı veya tenant bazında aktive edilebilir.

Kill Switch

Problem durumunda yeni davranış deployment beklenmeden kapatılabilir.

Controlled Release

Feature rollout yüzdelik veya segment bazlı ilerletilebilir.

Flag Cleanup

Migration tamamlandıktan sonra geçici flag'ler kaldırılmalıdır.

Rollback Stratejisi

Traffic Rollback

API Gateway veya routing katmanında trafik eski sisteme geri yönlendirilebilir.

Application Rollback

Yeni servis bir önceki sağlıklı sürüme döndürülebilir.

Data Rollback

En zor bölümdür. Migration öncesinde geri dönüşte verinin nasıl ele alınacağı tanımlanmalıdır.

Event Compatibility

Eski sürüm yeni event şemasını okuyamıyorsa application rollback tek başına güvenli olmayabilir.

Emergency Runbook

Kimin hangi adımı hangi sırayla uygulayacağı önceden belgelenmelidir.

Expand-and-Contract Database Değişiklikleri

Expand

Önce yeni schema mevcut consumer'ları bozmadan eklenir.

Backward-Compatible Deployment

Uygulama eski ve yeni schema ile belirli bir dönem uyumlu çalışır.

Backfill

Eski kayıtlar yeni yapıya aktarılır.

Consumer Migration

Consumer'lar adım adım yeni alanları kullanmaya başlar.

Contract

Eski alanların kullanımı sıfıra ulaştığında gereksiz schema kaldırılır.

Zero-Downtime Mikroservis Migration

Coexistence

Eski ve yeni sistem belirli süre beraber çalışmalıdır.

Backward Compatibility

Deployment sırası geçici versiyon farklılıklarında sistemi bozmamalıdır.

Traffic Shifting

Trafik küçük oranlarla yeni servise taşınmalıdır.

Data Consistency

Geçiş boyunca iki sistem arasındaki veri farkları izlenmelidir.

Rollback

Her migration aşamasının uygulanabilir geri dönüş planı bulunmalıdır.

Organizasyon Yapısını Mikroservislere Hazırlamak

Conway's Law

Sistem mimarisi zamanla ekiplerin iletişim yapısını yansıtır. Servis sınırları ile ekip sınırlarının uyumu önemlidir.

Domain-Aligned Teams

Ekipler teknik katmanlar yerine belirli domain veya capability alanlarından sorumlu olabilir.

Product Teams

Ürünün yaşam döngüsünü uzun süre yöneten ekipler servis sahipliği için güçlü model oluşturur.

Platform Team

Ortak geliştirme ve deployment altyapısını ürün ekiplerine self service biçimde sunabilir.

SRE

Reliability hedeflerinin belirlenmesi ve operasyon modellerinin geliştirilmesinde destek sağlar.

Security

Güvenlik ekipleri merkezi standartlar ve otomatik kontroller üzerinden geliştirme sürecine entegre olmalıdır.

Service Ownership Modeli

Code Owner

Servisin kod değişikliklerinden sorumlu ekip açık olmalıdır.

Data Owner

Servisin yönettiği verinin sahibi tanımlanmalıdır.

Runtime Owner

Production ortamındaki çalışma durumundan kimin sorumlu olduğu bilinmelidir.

SLO Owner

Reliability hedeflerinin takibi belirli bir sahiplik altında olmalıdır.

On-Call Owner

Production alarmında müdahale edecek ekip net olmalıdır.

Documentation Owner

API, runbook ve mimari dokümantasyonun güncelliği sahiplenilmelidir.

“You Build It, You Run It” Modeli

Avantajları

Geliştiren ekibin production sonuçlarını görmesi daha kaliteli teknik kararları teşvik edebilir.

Cognitive Load Riski

Her operasyon görevini ürün ekibine bırakmak geliştiricilerin odağını dağıtabilir.

Platform Team ile Desteklemek

Platform ekibi ortak operasyon işlerini standartlaştırarak ürün ekiplerinin yükünü azaltabilir.

Kuruma Göre Hibrit Ownership

Her şirketin ekip kapasitesi farklıdır. On call ve platform sorumlulukları hibrit biçimde paylaşılabilir.

Service Catalog Neden Gereklidir?

Service Name

Her servisin kurum içinde benzersiz ve anlaşılır bir adı bulunmalıdır.

Owner

Sorumlu ekip kolayca bulunabilmelidir.

Repository

Kaynak kod konumu catalog üzerinden erişilebilir olmalıdır.

API

Servisin sunduğu kontratlara erişim sağlanmalıdır.

Dependencies

Servisin hangi diğer servislere bağımlı olduğu görünür olmalıdır.

SLO

Reliability hedefleri catalog kaydında tutulabilir.

Runbook

Yaygın incident senaryolarında uygulanacak adımlar kolay bulunmalıdır.

Migration Governance

Architecture Principles

Servis sınırları, sahiplik ve iletişim modelleri için temel prensipler kurum genelinde paylaşılmalıdır.

ADR

Önemli mimari kararların nedeni Architecture Decision Record ile kalıcı hâle getirilebilir.

API Standards

İsimlendirme, hata modeli ve versiyonlama için ortak kurallar belirlenmelidir.

Data Standards

Veri sahipliği, retention ve event modellerine ilişkin standartlar oluşturulmalıdır.

Security Baselines

Her servisin karşılaması gereken minimum güvenlik kontrolleri otomatikleştirilmelidir.

Service Template Standards

Yeni servislerin ortak operasyon kabiliyetleriyle başlaması sağlanmalıdır.

Architecture Fitness Functions

Forbidden Dependencies

Yasak bağımlılıklar CI aşamasında otomatik kontrol edilebilir.

Service Ownership

Owner bilgisi bulunmayan servislerin release edilmesini önleyen kontroller uygulanabilir.

API Compatibility

Breaking change otomatik kontrat testleriyle engellenebilir.

Security Checks

Dependency ve container kontrolleri pipeline içinde zorunlu tutulabilir.

Performance Thresholds

Latency veya resource kullanımındaki kabul edilemez gerilemeler release öncesinde yakalanabilir.

Mikroservis Maliyetlerini Yönetmek

Compute

Her servisin minimum resource rezervasyonu toplam altyapı maliyetini artırabilir.

Database

Servis başına veri altyapısı işletim ve lisans maliyeti oluşturabilir.

Network

Servisler arası yoğun trafik veri transfer maliyetini artırabilir.

Observability

Log, metric ve trace hacmi servis sayısıyla birlikte büyür.

API Gateway

Gateway katmanının altyapı ve operasyon maliyeti bütçeye dahil edilmelidir.

Service Mesh

Mesh kullanımı ek compute, network ve platform yönetim maliyeti oluşturabilir.

Platform Engineering

Platform ekibi maliyet gibi görünse de standartlaşma ve self service ile toplam geliştirme verimliliğini artırabilir.

Mikroservis FinOps

Cost per Service

Her servisin aylık altyapı maliyeti görünür hâle getirilmelidir.

Cost per Transaction

Belirli iş işleminin teknoloji maliyetini ölçmek optimizasyon kararlarını kolaylaştırır.

Idle Resources

Düşük trafik alan servislerin sürekli yüksek kaynakla çalışması gereksiz gider oluşturabilir.

Over-Provisioning

Resource taleplerini gerçek kullanım verilerine göre ayarlamak gerekir.

Service Consolidation Candidates

Bağımsızlığı az, maliyeti yüksek servisler yeniden birleştirme adayı olabilir.

Bir Microservice'i Yeniden Monolite Birleştirmek Hata mıdır?

Hayır. Mimari kalıcı bir sözleşme değildir. Yeni veriler yanlış sınırı gösterebilir.

Yanlış Boundary

İki servis sürekli beraber değişiyorsa aslında tek capability olabilirler.

Çok Yüksek Communication Cost

Servisler arasında sürekli veri alışverişi gerekiyorsa ayrımın maliyeti faydasından yüksek olabilir.

Çok Düşük Independent Change

Bir servis neredeyse hiçbir zaman bağımsız release edilmiyorsa ayrı servis olmasının değeri sorgulanmalıdır.

Service Consolidation Bir Başarısızlık Değildir

Doğru ölçümlere dayanarak servisleri birleştirmek mimari öğrenmenin doğal sonucudur.

Migration Dashboard

Migrated Capabilities

Kaç capability alanının yeni mimariye geçtiği takip edilmelidir.

Remaining Monolith Traffic

Toplam trafiğin ne kadarının hâlâ monolite ulaştığı ölçülmelidir.

Remaining Legacy Writes

Legacy database'e devam eden yazma işlemleri decommission önündeki önemli engellerden biridir.

Active Microservices

Production ortamındaki aktif servis sayısı gözlenebilir ancak tek başına başarı metriği olarak kullanılmamalıdır.

Migration Errors

Yeni routing ve data migration kaynaklı hata oranları ayrı takip edilmelidir.

Infrastructure Cost

Dual run dönemindeki maliyet artışı dashboard içinde görünür olmalıdır.

Monolit Ne Zaman Kapatılabilir?

Traffic = 0

Monolite yönlendirilen production trafiği kalmamalıdır.

Writes = 0

Legacy veri deposuna aktif yazma işlemi bulunmamalıdır.

Consumers = 0

Legacy API veya batch çıktılarını kullanan consumer kalmadığı doğrulanmalıdır.

Data Migration Tamamlandı

Gerekli geçmiş verinin tamamı yeni sahiplerine aktarılmış olmalıdır.

Rollback Window Kapandı

Yeni yapının yeterli süre kararlı çalıştığı doğrulandıktan sonra geri dönüş ihtiyacı kapatılabilir.

Audit Requirements Karşılandı

Yasal veya kurumsal kayıt saklama gereksinimleri tamamlanmalıdır.

Monolith Decommission Checklist

APIs

Legacy endpoint consumer'larının kalmadığı doğrulanmalıdır.

Scheduled Jobs

Eski cron ve batch görevleri kontrol edilmelidir.

Database

Aktif read ve write bağlantılarının sona erdiği doğrulanmalıdır.

Integrations

Harici sistem bağlantıları yeni servislere taşınmalıdır.

DNS

Eski endpoint kayıtları kontrollü biçimde kapatılmalıdır.

Infrastructure

Kullanılmayan compute kaynakları kaldırılmalıdır.

Licenses

Legacy sistem için gereksiz hâle gelen lisanslar sonlandırılabilir.

Backups

Yasal ve operasyonel ihtiyaçlara göre son yedekler güvenli biçimde saklanmalıdır.

Monitoring

Legacy sistem için oluşturulan alarm ve dashboard'lar kullanım dışı bırakılmalıdır.

Örnek Kurumsal Geçiş Roadmap'i

Faz 0: Mikroservise İhtiyaç Olduğunu Kanıtla

Önce mevcut mimarinin gerçekten business outcome önünde engel oluşturduğunu metriklerle gösterin.

Faz 1: Baseline ve Monolith Discovery

Code, runtime, database ve ekip bağımlılıklarını çıkarın.

Faz 2: Domain/Capability Mapping

Business capability ve bounded context adaylarını belirleyin.

Faz 3: Modularization

Monolit içindeki sınırları mümkün olduğunca netleştirin.

Faz 4: Platform Foundation

CI/CD, observability, security ve service template altyapısını oluşturun.

Faz 5: Walking Skeleton Microservice

Gerçek production trafiği alabilen ilk servisi uçtan uca hazırlayın.

Faz 6: Strangler Migration

Seçilen capability trafiğini aşamalı olarak yeni servise yönlendirin.

Faz 7: Data Ownership Extraction

Veri sahipliğini yeni servise taşıyın ve direct database erişimlerini kaldırın.

Faz 8: Scale-out

İlk deneyimden elde edilen standartları diğer uygun domain alanlarına uygulayın.

Faz 9: Legacy Decommission

Trafik, write ve consumer değerleri sıfıra ulaştığında monoliti kontrollü olarak kapatın.

Örnek Kurumsal Hedef Mimari

API Gateway

External routing ve geçiş yönetimi için merkezi giriş noktası sağlar.

Modular Monolith Core

Henüz mikroservise ayrılmasına gerek olmayan capability alanları modüler yapı içinde kalabilir.

Domain Microservices

Bağımsız değişim veya ölçekleme ihtiyacı bulunan domain alanları servis olarak çalışır.

Event Bus

Asenkron domain event iletişimi için ortak altyapı sunar.

Service-Owned Data

Her servis kendi veri değişikliklerinin tek sahibi olur.

Platform Layer

Build, deploy, secret ve runtime işlemlerini standartlaştırır.

Observability Layer

Metrics, logs ve traces verilerini ortak görünümde toplar.

Identity/Security Layer

Kimlik, yetki ve servis güvenliği için ortak mekanizmalar sağlar.

Service Catalog

Servislerin sahiplik ve bağımlılık bilgilerini görünür kılar.

Benzer yazılım mimarisi ve geliştirme çalışmalarını görmek için Diyarbakır Yazılım Topluluğu proje sayfasını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz.

Mikroservise Geçişte Sık Yapılan Hatalar

Mikroservis Sayısını Hedef Yapmak

Yüz servis oluşturmak başarı değildir. Amaç iş teslim hızını ve sistemin yönetilebilirliğini iyileştirmektir.

Business Domain Yerine Technical Layer'a Göre Bölmek

Controller servisi, database servisi veya ortak logic servisi gibi ayrımlar dağıtık bağımlılıkları artırabilir.

Çok Küçük Servislerle Başlamak

İlk aşamada yüzlerce küçük servis operasyon yükünü gereksiz biçimde büyütebilir.

Shared Database'i Kalıcı Bırakmak

Shared database geçici migration adımı olabilir ancak kalıcı model hâline geldiğinde servis bağımsızlığını azaltır.

Sync Call Chain Oluşturmak

Her servisin sonraki servisi senkron çağırdığı uzun zincirler yüksek latency ve düşük reliability üretir.

Platform Hazırlığı Olmadan Service Üretmek

Deployment ve monitoring altyapısı hazır değilse servis sayısındaki artış operasyon ekibini zorlar.

Distributed Tracing'i Sonraya Bırakmak

İlk production sorununda request'in hangi serviste bozulduğunu anlamak zorlaşır.

Rollback'i Yalnız Kod Rollback'i Sanmak

Database schema ve event kontratı değiştiğinde eski application sürümüne dönmek tek başına çözüm değildir.

Legacy Responsibility'yi Kaldırmamak

Yeni servis açıldıktan sonra monolitteki eski kod ve veri yolu kaldırılmazsa iki sistem sürekli beraber yaşamaya devam eder.

Takım Yapısını Değiştirmeden Mimariyi Değiştirmek

Servisler ayrılırken ekipler hâlâ teknik katmanlar etrafında organizeyse koordinasyon problemi devam edebilir.

Mikroservis Migration Definition of Done

Business Capability Bağımsız mı?

Servis anlamlı bir iş yeteneğini kendi sınırları içinde yönetebilmelidir.

Service Bağımsız Deploy Edilebiliyor mu?

Başka servislerin eş zamanlı release edilmesine ihtiyaç duyulmamalıdır.

Verisinin Sahibi mi?

Servis kendi domain verisinin değişikliklerini kontrol etmelidir.

API Contract'ı Tanımlı mı?

Consumer ile provider arasındaki beklenti açık ve versiyonlanabilir olmalıdır.

SLO'su Var mı?

Availability ve latency hedefleri ölçülebilir biçimde tanımlanmalıdır.

Metrics/Logs/Traces Var mı?

Production davranışı üç temel telemetry kaynağı üzerinden izlenebilmelidir.

Security Baseline Karşılanıyor mu?

Servis kurumun minimum güvenlik gereksinimlerini karşılamalıdır.

Rollback Test Edildi mi?

Geri dönüş planı yalnızca dokümanda değil gerçek ortamda doğrulanmalıdır.

Legacy Dependency Kaldırıldı mı?

Monolit bağlantısı devam ediyorsa migration henüz tamamlanmış sayılmamalıdır.

Team Ownership Açık mı?

Servisin geliştirme ve production sorumlusu kolayca belirlenebilmelidir.

Sık Sorulan Sorular

Monolitten mikroservislere neden geçilir?

Bağımsız deployment, farklı ölçekleme ihtiyacı, ekip koordinasyonunun azaltılması ve belirli domain alanlarında değişim hızının artırılması gibi ölçülebilir nedenlerle geçiş yapılabilir.

Her monolit mikroservislere bölünmeli mi?

Hayır. İyi tasarlanmış bir modular monolith birçok ürün için daha düşük maliyetli ve daha kolay yönetilebilir olabilir.

Mikroservis geçişine nereden başlanmalı?

Önce metrikler çıkarılmalı, domain sınırları incelenmeli ve düşük bağımlılığa sahip ilk capability seçilmelidir.

Strangler Fig Pattern nedir?

Legacy sistemin işlevlerini kademeli olarak yeni servislere taşıyan ve trafiği adım adım yönlendiren migration yaklaşımıdır.

Modular monolith mi microservices mi?

Bağımsız ölçekleme ve ekip özerkliği güçlü bir ihtiyaç değilse modular monolith daha ekonomik olabilir. Mikroservisler operasyon maliyetini karşılayacak fayda oluştuğunda seçilmelidir.

Microservice boundary nasıl belirlenir?

Business capability, bounded context, veri sahipliği, değişim sıklığı, transaction sınırı ve ekip sahipliği birlikte değerlendirilmelidir.

Bir microservice ne kadar küçük olmalıdır?

Boyut kod satırıyla ölçülmemelidir. Servis tek ve anlamlı bir iş sorumluluğuna sahip olacak kadar odaklı olmalıdır.

Database per service gerekli midir?

Logical data ownership gereklidir. Bunun için her servisin mutlaka ayrı fiziksel database sunucusu kullanması şart değildir.

Shared database mikroservislerde kullanılabilir mi?

Migration sırasında geçici olarak kullanılabilir ancak servislerin aynı tablolara doğrudan yazdığı kalıcı model bağımsızlığı azaltır.

Saga Pattern nedir?

Birden fazla servis içeren iş işleminde local transaction ve telafi adımlarını koordine etmeye yarayan yaklaşımdır.

Transactional Outbox ne işe yarar?

Business verisi ile yayınlanacak event bilgisini aynı local transaction içinde kaydederek mesaj kaybı riskini azaltır.

Monolit ve mikroservis aynı anda çalışabilir mi?

Evet. Kademeli migration süreçlerinde iki yapının beraber çalışması beklenen bir durumdur.

Zero-downtime migration nasıl yapılır?

Backward compatible değişiklikler, kontrollü trafik geçişi, veri reconciliation, feature flags ve uygulanabilir rollback mekanizmaları birlikte kullanılmalıdır.

Kubernetes mikroservisler için gerekli midir?

Hayır. Managed container platformları, serverless veya VM tabanlı çözümler de kullanılabilir.

Service mesh ne zaman gereklidir?

Servis sayısı ve network politikaları arttığında mTLS, traffic management ve telemetry ihtiyaçlarını ortaklaştırmak için değerlendirilebilir.

Distributed monolith nedir?

Servislerin fiziksel olarak ayrıldığı ancak shared database, ortak deployment ve yoğun senkron çağrılar nedeniyle bağımsız davranamadığı yapıdır.

Mikroservis migration ne kadar sürer?

Sabit bir süre yoktur. Sistem büyüklüğü, domain sayısı, veri bağımlılıkları, ekip sayısı ve platform hazırlığı süreyi belirler. Kurumsal sistemlerde dönüşümü tek proje tarihi yerine aşamalı capability migration programı olarak ele almak daha sağlıklıdır.

Monolit ne zaman tamamen kapatılmalıdır?

Production trafiği, write işlemleri ve consumer sayısı sıfıra ulaştığında, veri migration tamamlandığında ve rollback dönemi güvenle kapandığında decommission yapılabilir.

Monolitik mimariden mikroservislere geçiş ne zaman gereklidir ve kuruma hangi avantajları sağlar?

Mevcut mimari deployment sıklığını, ekip bağımsızlığını veya ölçeklemeyi ölçülebilir biçimde engellemeye başladığında geçiş değerlendirilebilir. Doğru uygulandığında farklı ekiplerin bağımsız release yapması, yalnızca ihtiyaç duyulan capability alanlarının ölçeklenmesi ve hata etkisinin daha dar sınırda tutulması gibi avantajlar sağlayabilir.

Monolitik bir uygulamada hangi bileşenlerin önce mikroservise dönüştürüleceğine nasıl karar verilir?

İlk adayın nispeten düşük teknik ve veri bağımlılığına, açık business capability sınırına, gerçek production kullanımına ve yönetilebilir risk seviyesine sahip olması tercih edilir. Ben ilk servis seçiminde yalnızca kolay ayrılan parçayı değil, kuruma platform ve operasyon açısından gerçek öğrenme sağlayacak alanı seçmeyi daha değerli buluyorum.

Strangler Fig Pattern ile monolitik sistemden mikroservislere kademeli geçiş nasıl yapılır?

Önce seçilen capability için yeni servis oluşturulur. Ardından API Gateway veya reverse proxy üzerinden küçük bir trafik grubu yeni servise yönlendirilir. Veri ve davranış doğrulandıktan sonra trafik artırılır. Son aşamada legacy implementation ve eski veri erişimleri kaldırılır.

Mikroservislere geçiş sırasında veri bütünlüğü, servisler arası iletişim ve iş sürekliliği nasıl korunur?

Veri sahipliği açıkça belirlenmeli, dual write yerine uygun durumlarda Transactional Outbox veya event tabanlı aktarım kullanılmalı, servis kontratları versiyonlanmalı ve idempotency uygulanmalıdır. İş sürekliliği açısından canary release, feature flag, reconciliation ve rollback planlarının birlikte tasarlanması gerekir.

Yakınımda monolitik mimariden mikroservislere kurumsal geçiş danışmanlığı veren yazılım firması nasıl bulabilirim?

Aradığınız ekibin yalnızca mikroservis geliştirdiğini söylemesine değil, domain analizi, veri migration, CI/CD, observability, güvenlik ve legacy decommission süreçlerini birlikte ele alabilmesine bakın. Diyarbakır ve çevresinde kurumsal monolith mikroservis dönüşümü ve yazılım modernizasyon hizmeti ya da mikroservis dönüşümü ve yazılım mimarisi danışmanlığı yakınımda araması yapıyorsanız Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi edinebilirsiniz.

Sonuç

Monolitik Mimariden Mikroservislere Kurumsal Geçiş Stratejileri yalnızca uygulamayı daha küçük parçalara ayırma işi değildir. Başarılı bir dönüşüm, domain sınırlarının doğru belirlenmesi, veri sahipliğinin servislerle uyumlu hâle getirilmesi, deployment bağımsızlığının sağlanması ve ekiplerin gerçek sorumluluk sahibi olmasıyla mümkün olur.

Benim sahada en fazla önem verdiğim nokta, migration başlamadan önce başarı ölçütünün açık olmasıdır. Daha çok servis üretmek değil, daha güvenli deployment yapmak, değişikliği daha hızlı kullanıcıya ulaştırmak ve kritik domain alanlarını daha bağımsız yönetmek hedeflenmelidir.

Monolitik Mimariden Mikroservislere Kurumsal Geçiş Stratejileri kapsamında sisteminiz için hangi yolun uygun olduğunu değerlendirmek, modular monolith ile mikroservis seçeneklerini karşılaştırmak veya kademeli migration planı oluşturmak istiyorsanız Diyarbakır Yazılım Topluluğu ile iletişime geçebilirsiniz.

https://www.diyarbakiryazilim.com.tr