# Gateway या Mesh चुनना — API Gateway और Service Mesh

Source: https://www.geekswithgeeks.com/hi/api-gateway-service-mesh/o-tools

> लोकप्रिय विकल्पों की सुविधाओं, संचालन और लागत पर तुलना करें।

## कोई सार्वभौमिक विजेता नहीं

**Gateways** के लिए: **NGINX** और **HAProxy** तेज़, आज़माए हुए reverse proxies हैं जो files से configure होते हैं; **Kong** और **Apache APISIX** (NGINX/OpenResty पर बने) plugins, admin API और developer ecosystem जोड़ते हैं; **Envoy** programmable proxy है जो कई gateways और meshes को चलाता है; **Traefik** container और Kubernetes auto-discovery के लिए लोकप्रिय है; **managed gateways** (Amazon API Gateway, Azure API Management, Google Cloud API Gateway/Apigee) vendor lock-in और प्रति-अनुरोध लागत के बदले संचालन हटाते हैं। **Meshes** के लिए: **Istio** सबसे सुविधा-संपन्न (और जटिल) है, **Linkerd** सरलता और कम overhead को प्राथमिकता देता है, **Consul** मिश्रित VM और Kubernetes परिवेशों के लिए ठीक है, और **Cilium** networking व वैकल्पिक mesh सुविधाओं के लिए eBPF उपयोग करता है। टीम के कौशल, platform (Kubernetes हो या नहीं), अनुपालन आवश्यकताओं और आप कितना संचालन-काम उठा सकते हैं, इससे चुनें। Features और उत्पाद नाम जल्दी बदलते हैं, इसलिए मौजूदा दस्तावेज़ देखें।

## Tools, trade-offs, जाल

ज़रूरत पूरी करने वाला सबसे सरल tool चुनें और योजना बनाएँ कि उसे कैसे चलाएँगे, upgrade करेंगे और debug करेंगे।

![तीन सवाल: कौन-सा tool, कैसे चलाएँ, क्या बिगड़ सकता है।](assets/figures/api-gateway-service-mesh/section-6-map.svg) — चित्र 6.1 — कौन-सा tool, कैसे चलाएँ और क्या बिगड़ सकता है।

## निर्णय मार्गदर्शिका

विकल्प घटाने का शुरुआती बिंदु; छोटे proof of concept से पुष्टि करें।

```text
Need                                           Reasonable starting choice
Simple routing + TLS + rate limit, few services  NGINX / HAProxy / Traefik
Public API with keys, plans, portal, analytics   Kong / APISIX / managed API gateway
No ops team, all-in on one cloud                 managed cloud API gateway
Kubernetes, want mTLS + retries + canaries       Linkerd (simple) or Istio (feature-rich)
Mixed VMs + Kubernetes                           Consul
< ~10 services, one team                         probably no mesh at all
```

**Quiz:** Service mesh शायद कब अनावश्यक है?

- [ ] कई भाषाओं में सैकड़ों services हों
- [x] एक टीम के पास मुट्ठी भर services हों
- [ ] जब हर जगह mTLS अनिवार्य हो
- [ ] जब टीमों को एक-से retries और telemetry चाहिए

*Answer:* एक टीम के पास मुट्ठी भर services हों. Mesh जटिलता जोड़ता है जो बड़े पैमाने और बहुभाषी टीमों में फ़ायदा देती है।