Microservices

Başlangıç: Monolithic (Tek Parça) Uygulamalar

“Eskiden uygulamalar tek parça halinde yazılırdı.”

Şöyle düşün:

• Veritabanı
• İş kuralları (business logic)
• Kullanıcı arayüzü

👉 Hepsi tek bir kodun içindeydi.

Bu yaklaşım:

• Küçük projelerde çok hızlı ve basit
• Başlangıç için ideal

Ama zamanla:

• Kodlar birbirine dolaşır
• Küçük bir değişiklik her yeri etkiler
• Büyüdükçe:
  • Bakımı zor
  • Güncellemesi riskli
  • Ölçeklemesi pahalı olur

“Her şey birbirine dolanınca sistemi geliştirmek ve büyütmek zorlaşır.”

---

Çözüm 1: Multi-Tier (Katmanlı Mimari)

Sonra yazılımcılar şöyle dedi:

“Tamam, her şeyi tek yerde tutmayalım.”

Ve katmanlı mimari geldi:

En yaygın model: 3 Katmanlı Mimari

1. Presentation Layer
   • Kullanıcı arayüzü
   • Web, mobil, ekranlar
2. Business Logic Layer
   • İş kuralları
   • Hesaplamalar
   • Süreçler
3. Data Layer
   • Veritabanı
   • CRUD işlemleri

Bu neyi çözdü?

• Kod daha düzenli
• Sorumluluklar ayrıldı

Ama…

⚠️ Hâlâ merkezi bir yapı

• Uygulama büyüdükçe yine zor
• Büyük sistemlerde yeterli değil

---

Büyük Problem: Çok Büyük ve Karmaşık Sistemler

Video burada örnek veriyor:

• Amazon
• Google
• Büyük web & mobil sistemler

Bu tarz sistemlerde:

• Milyonlarca kullanıcı
• Sürekli yeni özellik
• Sürekli güncelleme

❌ Tek bir büyük uygulama artık çalışmaz.

---

Asıl Kırılma Noktası: Microservices

“Karmaşıklığı yönetmenin en iyi yolu: parçalamak.”

İşte Microservices tam burada ortaya çıkıyor.

Microservice nedir?

• Her biri:
  • Tek bir iş yapar
  • Kendi mantığı vardır
  • Kendi verisini yönetebilir
• Diğer servislerden bağımsızdır

Örnek:

• User Service
• Order Service
• Payment Service
• Notification Service

Her biri:

• Ayrı geliştirilir
• Ayrı deploy edilir
• Ayrı ölçeklenir

“Her microservice bir iş fonksiyonunu uçtan uca yönetir.”

---

Microservice’ler Nasıl Konuşur?

Microservice’ler doğrudan birbirinin içine girmez.

İletişim:

• HTTP (REST)
• Message Queue
• Event’ler

Bu sayede:

• Gevşek bağlı (loosely coupled)
• Bir servis çökse bile:
  • Tüm sistem çökmez (teoride)

---

Takımlar Açısından Büyük Avantaj

“Farklı takımlar, farklı microservice’ler üzerinde bağımsız çalışabilir.”

Bu ne sağlar?

• Ekipler birbirini beklemez
• Daha hızlı geliştirme
• Daha az çatışma

Teoride:

• Farklı diller
• Farklı teknolojiler
• Farklı altyapılar

Pratikte:

• Şirketler genelde standart setler belirler
  (maliyet, bakım, operasyon için)

---

Ama… Yeni Bir Problem Doğuyor 😐

Sistem büyüdükçe:

• 10 → 100 → 1000 microservice

Yeni sorunlar:

• Bir servis çökünce zincirleme hata
• Hata kaynağını bulmak zor
• İzleme zor
• Yönetim zor

“Karmaşıklık tekrar geri gelir.”

---

Bu Karmaşıklık Nasıl Yönetiliyor?

Bu yüzden ekosistem doğuyor:

• Docker
  • Servisleri paketler
• Kubernetes
  • Servisleri yönetir
  • Restart, scale, health check
• CI / CD
  • Otomatik build & deploy
• Message Brokers
  • RabbitMQ, Kafka vb.
  • Asenkron iletişim
• Monitoring
  • Performans takibi
• Logging & Auditing
  • Ne oldu, nerede oldu, neden oldu?

---

❗ “Microservices sihirli bir çözüm değildir.”

• Küçük uygulamalar:
  • Monolith daha mantıklı
• Az kullanıcı
• Az değişiklik

Çünkü:

• Dağıtık sistemler zordur
• Yönetimi pahalıdır
• Operasyonel yük getirir

---

🎯 Tek Cümlelik Özet

Microservices, büyüyen ve hızla değişen büyük sistemler için güçlü ama zor bir mimaridir. Küçük projelerde gereksiz karmaşıklık yaratır.

Kaynakça:

• https://stock.adobe.com/tr/images/blocks-hexagon-arrow-up-icon-vector-microservice-architecture-logistics-supply-chain-logo/296637990