Mikroservis hevesinden gerçeğe
2015-2020 arasında mikroservisler "modern mimarinin tek doğrusu" olarak sunuldu. 2026'da gerçek daha nüanslı: doğru ölçek ve takım yapısında mantıklı, küçük takım veya basit domain için yıkıcı bir overhead. AIOR olarak müşteri tarafına teslim ettiğimiz uygulamaların yaklaşık %20'si mikroservis mimarisi kullanıyor; geri kalan %80 modular monolith veya küçük servis grubu.Mikroservis ne zaman gerçekten gerekli?
- Takım birden çok bağımsız grubun aynı sistemde çalışması gerekiyorsa.
- Farklı servislerin farklı scaling karakteristikleri varsa (örn. video processing CPU-yoğun, web API I/O-yoğun).
- Farklı domain'ler için farklı teknoloji yığını gerekiyorsa (ML modeli Python, web frontend Node.js, finansal hesap Java).
- Bağımsız deployment cycle'lara ihtiyaç var — bir grup günde 50 deploy ediyor, diğeri haftalık release yapıyor.
- Uyumluluk veya güvenlik gereksinimi belirli verileri izole tutmayı zorunlu kılıyor.
Mikroservisin maliyetleri
Bu maliyetleri ödemeye hazır değilseniz, mikroservise gitmeyin:- Distributed system complexity — network failures, partial successes, eventual consistency.
- Operational overhead — her servis için CI/CD, monitoring, logging, deployment ayrı.
- Service discovery, load balancing — yeni infrastructure katmanları.
- Distributed tracing — bir isteği takip etmek 5 servis arasında zor.
- Data consistency — distributed transaction'lar pahalı, eventual consistency genelde kabul edilir.
- Test complexity — integration testler için multi-service test ortamı gerekir.
AIOR'da müşteri tarafına teslim ettiğimiz mikroservis projelerinde bu maliyetleri başlangıçta açık şekilde belgeliyor, gerekirse karardan dönüyoruz.
Modular monolith — neden popüler
Mikroservisin alternatifi modular monolith: tek deployment unit ama içeride net domain boundary'leri olan modüller. AIOR'da yeni projelerin çoğunu modular monolith ile başlatıyoruz. Avantajlar:- Tek codebase, tek deploy.
- Cross-domain calls function call (network değil).
- Refactoring güvenli — compiler değişikliği yakalar.
- Transaction'lar yerel database'de tek seferde.
Bounded context'ler büyüyüp gerçekten ayrı çalışmaya başladığında, ilgili modülü servise ayırırız. Bu "stranger fig" pattern AIOR'ın varsayılan migration stratejisi.
Servis boundary'leri — yanlış çizilirse
Yanlış boundary'ler mikroservis projelerinin en sık hatası. AIOR olarak bu prensipleri uyguluyoruz:- Bounded context (DDD) ile uyumlu — domain dili sınırı belirler.
- Veri sahipliği net — bir servis bir entity için tek "source of truth".
- Stable interface — sık değişen API'lar coupling işaretidir.
- Conway's Law dikkate alın — takım yapısı servis sınırlarını şekillendirir.
Inter-service iletişim kalıpları
- Synchronous REST/gRPC — basit ama tight coupling. Cascading failures riski.
- Asynchronous messaging (Kafka, RabbitMQ, NATS) — loose coupling, resilient. AIOR'ın varsayılan tercihi.
- Event sourcing — state değil event'ler saklanır. Audit trail için güçlü ama complexity yüksek.
- CQRS — read/write modelleri ayrı. Yüksek-trafikli okuma için.
AIOR projelerinde sync REST ile async messaging hibrit standart — user-facing istekler sync, downstream işler async.
Observability gereği
Mikroservislerde observability seçeneksizdir. AIOR projelerinde:- Distributed tracing (OpenTelemetry, Jaeger) — her servis trace span'leri yayar.
- Centralized logging (Loki, ELK) — log'lar single search.
- Metrics (Prometheus + Grafana) — servis SLI/SLO izleme.
- Error tracking (Sentry) — hata bildirimi otomatik.
Deployment ve orchestration
Kubernetes mikroservislerin baskın deployment platformu. AIOR projelerinde Helm chart'lar ile uygulama tanımı, ArgoCD veya Flux ile GitOps deployment.Service mesh (Istio, Linkerd) ek complexity getirir; AIOR olarak Istio'yu sadece gerçekten gerektiğinde (mTLS, advanced routing, multi-cluster) öneriyoruz. Çoğu proje için Kubernetes-native özellikler yeterli.
Sonuç
Mikroservisler 2026'da hâlâ geçerli bir mimari pattern ama "default" değil. AIOR'da bir mikroservis projesi başlatmadan önce takım yapısı, ölçek, operasyon kapasitesi sorgulanır; gerçekten gerekli mi netleştirilir. Yanlış yerde mikroservis, doğru yerde monolith — ikisi de işe yarar. Sizin tarafınızda mikroservise geçiş kararı verirken en zorlayan faktör neydi — operasyon, takım, yoksa data consistency?From microservices hype to reality
Between 2015 and 2020, microservices were sold as "the only right modern architecture." In 2026 the truth is more nuanced: sensible at the right scale and team structure, devastating overhead for small teams or simple domains. About 20% of applications AIOR delivers to customers use microservice architecture; the remaining 80% are modular monoliths or small service clusters.When are microservices truly necessary?
- Multiple independent teams need to work on the same system.
- Different services have different scaling characteristics (e.g. video processing CPU-bound, web API I/O-bound).
- Different domains need different technology stacks (ML in Python, web frontend in Node.js, financial accounting in Java).
- Independent deployment cycles are needed — one team deploys 50× a day, another releases weekly.
- Compliance or security mandates isolating certain data.
The cost of microservices
If you're not ready to pay these costs, don't go microservice:- Distributed system complexity — network failures, partial successes, eventual consistency.
- Operational overhead — CI/CD, monitoring, logging, deployment per service.
- Service discovery, load balancing — new infrastructure layers.
- Distributed tracing — following a request across 5 services is hard.
- Data consistency — distributed transactions are expensive; eventual consistency is usually accepted.
- Test complexity — integration tests need multi-service test environments.
On microservice projects we deliver to customers, AIOR documents these costs explicitly up front and is willing to reverse the decision if needed.
Modular monolith — why it's popular
The alternative to microservices is the modular monolith: one deployment unit with clean domain boundaries internally. AIOR starts most new projects this way. Advantages:- Single codebase, single deploy.
- Cross-domain calls are function calls (not network).
- Refactoring is safe — the compiler catches changes.
- Transactions stay local to one database.
When bounded contexts grow and truly operate independently, we extract that module to a service. This "strangler fig" pattern is AIOR's default migration strategy.
Service boundaries — getting them wrong
Bad boundaries are the most common mistake on microservice projects. AIOR's principles:- Aligned with bounded context (DDD) — domain language defines the boundary.
- Clear data ownership — one service is the single source of truth for an entity.
- Stable interface — frequently changing APIs are a sign of coupling.
- Mind Conway's Law — team structure shapes service boundaries.
Inter-service communication patterns
- Synchronous REST/gRPC — simple but tight coupling; risk of cascading failures.
- Asynchronous messaging (Kafka, RabbitMQ, NATS) — loose coupling, resilient. AIOR's default.
- Event sourcing — store events, not state. Strong audit trail but high complexity.
- CQRS — separate read/write models. For high-traffic read paths.
Hybrid sync REST + async messaging is standard on AIOR projects — user-facing requests sync, downstream work async.
Observability is mandatory
Observability is non-negotiable in microservices. On AIOR projects:- Distributed tracing (OpenTelemetry, Jaeger) — every service emits trace spans.
- Centralised logging (Loki, ELK) — single search across logs.
- Metrics (Prometheus + Grafana) — service SLI/SLO monitoring.
- Error tracking (Sentry) — automatic error reporting.
Deployment and orchestration
Kubernetes is the dominant deployment platform for microservices. AIOR projects use Helm charts for app definition, ArgoCD or Flux for GitOps deployment.A service mesh (Istio, Linkerd) adds complexity; AIOR recommends Istio only when genuinely needed (mTLS, advanced routing, multi-cluster). For most projects, Kubernetes-native features suffice.
