Τι είναι ένα service mesh και γιατί θα το χρησιμοποιούσατε;

Question

Accepted Answer

Ένα **service mesh** (Istio, Linkerd) μεταφέρει cross-cutting networking concerns — retries, timeouts, mTLS, traffic routing, observability — **έξω από τον κώδικα της εφαρμογής** και σε ένα δικτυακό στρώμα υποδομής **sidecar proxies**.

## Πώς λειτουργεί

Κάθε instance υπηρεσίας τρέχει δίπλα σε ένα **sidecar proxy** (π.χ. Envoy). Όλη η κίνηση ρέει μέσα από τα proxies, που αποτελούν το **data plane**; ένα **control plane** τα διαμορφώνει.

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

## Τι παρέχει

- **mTLS** μεταξύ υπηρεσιών αυτόματα (χωρίς αλλαγές εφαρμογής).
- **Ανθεκτικότητα** — retries, timeouts, circuit breaking στο proxy.
- **Διαχείριση κίνησης** — canary, A/B, weighted routing.
- **Παρατηρησιμότητα** — ενιαία metrics, traces, logs.

## Παράδειγμα πολιτικής

```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
```

## Ανταλλαγές

Ένα mesh προσθέτει latency (επιπλέον hops), επιβάρυνση πόρων (ένα proxy ανά pod) και πραγματική λειτουργική πολυπλοκότητα.

## Γιατί είναι σημαντικό

Ένα mesh τυποποιεί την ανθεκτικότητα, την ασφάλεια και την παρατηρησιμότητα σε κάθε υπηρεσία χωρίς κάθε ομάδα να χρειάζεται να τις εφαρμόσει ξανά σε διαφορετικές γλώσσες.

Αλλά είναι βαρύ: υιοθετήστε το μόνο όταν έχετε αρκετές υπηρεσίες ώστε η διπλασιασμένη δικτυακή λογική να υπερκαλύπτει το λειτουργικό κόστος του mesh.