Service Mesh nedir ve neden kullanırsınız?

Question

Accepted Answer

Bir **service mesh** (Istio, Linkerd), hizmetler arasındaki ağ problemlerini — yeniden denemeler, zaman aşımları, mTLS, traffic yönlendirme, observability — **uygulama kodunun dışına** çıkartıp **sidecar proxy** ların ağ altyapısı katmanına taşır.

## Nasıl çalışır

Her hizmet örneği bir **sidecar proxy** (ör. Envoy) ile yan yana çalışır. Tüm traffic proxy'ler aracılığıyla akar, bu da **data plane**'i oluşturur; **control plane** bunları yapılandırır.

```text
┌─────────────────┐        ┌─────────────────┐
│ Service A       │        │ Service B       │
│  app  ⇄ [proxy] │◀──────▶│ [proxy] ⇄  app  │
└─────────────────┘  mTLS  └─────────────────┘
        ▲ configured by ▲
        └──── Control Plane (Istio/Linkerd) ────┘
```

## Ne sağlar

- **mTLS** hizmetler arasında otomatik olarak (sıfır uygulama değişikliği).
- **Esneklik** — yeniden denemeler, zaman aşımları, proxy'de devre kesme.
- **Traffic yönetimi** — canary, A/B, ağırlıklı yönlendirme.
- **Observability** — tek biçimli metrikler, traces, loglar.

## Örnek politika

```yaml
# shift 10% of traffic to v2 (canary), no code change
route:
  - destination: { host: orders, subset: v1 }
    weight: 90
  - destination: { host: orders, subset: v2 }
    weight: 10
```

## Takas

Bir mesh gecikme ekler (ekstra atlamalar), kaynak yükü (pod başına bir proxy) ve gerçek operasyonel karmaşıklık.

## Neden önemli

Bir mesh, her hizmet arasında esneklik, güvenlik ve observability'i standartlaştırır ve her ekibin ağ mantığını farklı dillerde yeniden uygulaması gerekmez.

Ama ağır: yalnızca yinelenen ağ mantığı mesh'in operasyonel maliyetinden daha fazla olduğunda yeterli sayıda hizmetiniz olduğunda bunu benimseyin.