Mikroservislerden Serverless’e: Modern Bulut Mimarilerinde Geçiş Rehberi

Bulut tabanlı sistemler hızla evriliyor: monolitik uygulamalardan mikroservislere geçiş yaşayan ekipler şimdi ölçeklenebilirlik, maliyet ve operasyonel karmaşıklık dengesi nedeniyle serverless yaklaşımları da değerlendiriyor. Bu makalede mimari kararlar, göç stratejileri, uygulama örnekleri ve operasyonel dikkat noktaları üzerinde pratik bir rehber sunuyorum. Hedef kitle çalışan yazılımcılar; örnekler Node.js ve Docker üzerine odaklıdır ama prensipler genel olarak uygulanabilir.

Neden mikroservisler ve neden serverless?

Mikroservis mimarisi, büyük monolitik uygulamaları işlevsel olarak ayrıştırarak bağımsız geliştirme, sürümleme ve ölçekleme sağlar. Avantajları; ekip bağımsızlığı, daha hızlı teslimat, farklı teknolojilerle çalışma esnekliği ve ince ayarlı ölçeklemedir. Ancak servis sayısı arttıkça dağıtık sistem zorlukları (ağ gecikmesi, tutarlılık, dağıtık izleme) ortaya çıkar.

Serverless (FaaS) ise altyapı yönetimini sağlayıcıya devrederek geliştiricileri sadece kod yazmaya odaklar. Otomatik ölçeklenme ve kullanım başına faturalama önemli artılardır. Dezavantajlar arasında soğuk başlangıçlar, çalışma zamanı sınırlamaları ve daha karmaşık uzun süreli işler için uygun olmaması sayılabilir. Bu iki yaklaşımı birbirinin alternatifi değil, birbirini tamamlayıcı olarak görmek genellikle en sağlıklısıdır.

Geçiş stratejileri: Monolitikten mikroservise, mikroservisten serverless'e

Geçiş planlı yapılmalıdır. Monolitikten mikroservise geçişte sık kullanılan stratejiler: Strangling pattern (parçaları yavaşça dışarı taşımak), modül bazlı ayrıştırma ve API gateway aracılığıyla yönlendirme. Küçük adımlarla ilerleyin; her taşımada otomatik testler ve geri dönüş planı olsun.

Mikroservisten serverless'e geçişte hangi servislerin uygun olduğuna karar verin: kısa ömürlü, olay-temelli ve talebe göre ani ölçeklenme gerektiren iş yükleri serverless için iyi adaydır. Durumsal, uzun süreli veya yüksek ve stabil CPU/IO gerektiren işlerde container tabanlı çözümler çoğunlukla daha verimlidir.

Tasarım ilkeleri ve yaygın mimari bileşenler

Karmaşık dağıtık sistemlerde birkaç temel ilke hayati önem taşır: idempotent işlem tasarımı, sınırlandırılmış veri sahipliği (bounded contexts), asenkron iletişim ve güçlü izleme/loglama. Servisler arası senkron iletişim için REST veya gRPC, asenkron iletişim için ise mesaj kuyrukları (RabbitMQ, Apache Kafka vb.) veya bulut sağlayıcı olay servisleri tercih edilir.

Ek olarak, konfigürasyon yönetimi (Consul, Kubernetes ConfigMaps), service discovery, circuit breaker ve rate limiting gibi yapılar sistem kararlılığı için gereklidir. Servis mesh (örn. Istio, Linkerd) mikroservislerde gözlemlenebilirlik ve güvenlik katmanları eklemek için sık kullanılır; ancak operasyon yükünü arttırabileceğini unutmayın.

Pratik örnekler: Docker, Kubernetes ve Serverless fonksiyonu

Aşağıda basit bir Node.js HTTP servisinin Dockerfile ve Kubernetes Deployment örneğini, ardından aynı işlevi yapan bir serverless fonksiyon örneğini bulacaksınız. Bu örnekler, gerçek sistemlerde daha fazla yapılandırma ve güvenlik gerektirecektir.

<!-- Dockerfile -->
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

<!-- basit index.js -->
const http = require('http');
const port = process.env.PORT || 3000;
http.createServer((req, res) => {
  res.end('Merhaba dünya');
}).listen(port);

<!-- Kubernetes deployment.yaml -->
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: your-registry/demo:latest
        ports:
        - containerPort: 3000
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"

<!-- AWS Lambda (Node.js) basit handler örneği -->
exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: 'Merhaba dünya (serverless)'
  };
};

Operasyon ve gözlemlenebilirlik

Dağıtık sistemlerde izleme, loglama ve tracing olmazsa olmazdır. Merkezi log toplama (ELK/EFK), metrik toplama (Prometheus + Grafana) ve dağıtık tracing (OpenTelemetry, Jaeger) kurmak başlangıçta zaman alır ama sorun çözme süresini dramatik şekilde kısaltır.

CI/CD boru hatları her servisin bağımsız olarak test edilip deploy edilmesini sağlamalı; canary veya blue/green dağıtımlar sayesinde hatalı sürümler hızlıca geri alınabilmelidir. Güvenlik için kimlik doğrulama ve yetkilendirmeyi merkezi hale getirin (OAuth2/OpenID Connect, JWT) ve servisler arası trafiği şifreleyin.

Geçişte sık yapılan hatalar ve nasıl önlenir

Aşağıdaki hatalar yaygındır: çok küçük mikroservislere bölünerek operasyonel yükü arttırmak, dağıtık işlemleri doğru yönetememek (saga/deseni eksikliği), yeterli otomasyon ve test olmadan büyük kesintilere sebep olmak. Bu hataları azaltmak için net bir bounded context analizi, güçlü entegrasyon testleri ve kademeli geçiş stratejileri benimseyin.

• Kavram kargaşası: Her şeyi serverless yapmak çözüm değildir; uygunluğu iş yüküne göre değerlendirin.
• Gözlemlenebilirlik eksikliği: Production'a çıkmadan önce izleme ve tracing kurun.
• Veri tutarlılığı: Dağıtık veritabanı modelleri ve transaction desenlerini planlayın.

Sık Sorulan Sorular

Mikroservise geçiş ne kadar sürer?

Projenin büyüklüğüne, ekip deneyimine ve kapsamına bağlıdır. Basit bir modülün ayrıştırılması birkaç hafta sürebilirken tamamen dağıtık bir mimariye geçiş aylar veya yıllar alabilir. Önemli olan küçük, geri alınabilir adımlar atmaktır.

Serverless her senaryo için uygun mu?

Hayır. Serverless kısa yaşayan, olay-temelli ve ani ölçeklenme beklenen iş yükleri için uygundur. Uzun süreli CPU yoğun işler, sürekli yüksek kaynak gereksinimi olan uygulamalar veya özel runtime gereksinimleri için container veya VM tabanlı çözümler daha uygundur.

Maliyetleri nasıl kontrol ederim?

Mikroservislerde maliyetler izleme, kaynak limitleri ve ölçeklendirme ile yönetilir. Serverless’te ise fonksiyonun çağrı sayısı, süre ve bellek tüketimi maliyeti belirler. Her iki ortamda da metrik temelli izleme ve maliyet alarmı kurun; soğuk başlangıçları ve gereksiz çağrıları en aza indirgeyin.

Sonuç

Mikroservisler ve serverless, modern bulut mimarilerinde güçlü seçeneklerdir; doğru seçim iş yükü karakteristiğine, ekip deneyimine ve operasyonel yetkinliğe bağlıdır. Geçişleri küçük adımlarla planlayın, gözlemlenebilirlik ve otomasyona yatırım yapın. Her iki yaklaşımı hibrit şekilde kullanmak (mikroservis + serverless) birçok durumda en iyi dengeyi sunar. Eğitim bağlantıları ve örnek uygulamalar makale sayfasına eklenecektir.