API / APIGEE Gateway Interview Questions
What are the deployment models available in Apigee?
Apigee offers three deployment models to accommodate different infrastructure requirements, data residency rules, and latency constraints.
| Model | Management plane | Runtime plane | Best for |
|---|---|---|---|
| Apigee (SaaS / cloud-native) | Google-managed | Google-managed | Cloud-first; simplest to operate; no infrastructure to maintain |
| Apigee hybrid | Google-managed | Customer-managed (own DC, AWS, Azure, GKE) | Data residency; latency to on-prem backends; regulatory compliance |
| Apigee Adapter for Envoy | Google-managed (central Apigee control) | Envoy sidecar inside service mesh | East-West traffic; service-to-service security within Kubernetes |
Apigee (SaaS): the fully cloud-native version where both the management and runtime planes are managed by Google. Ideal for cloud-first organisations that want to minimise operational overhead.
Apigee hybrid: the management plane (the UI, analytics storage, and policy configuration) stays in Google Cloud, while the runtime plane (the message processors that actually execute policy and proxy traffic) is deployed in the customer's own environment -- on-premises, AWS, Azure, or any Kubernetes cluster. Under the hood, the runtime uses a Kubernetes cluster for scalability and high availability.
Apigee Adapter for Envoy: an advanced model for managing East-West (service-to-service) traffic within a microservices architecture. Apigee acts as the central policy authority while Envoy sidecars enforce those policies locally in the service mesh, providing fast, decentralised security checks without routing each request through a central gateway.
More Related questions...
