As monolithic applications are broken down into self functioning units in the form of microservices, the paradigm of deployments for these applications have become truly distributed. While it provides the flexibility of operating /updating individual modules for easy maintenance, loose coupling and faster deployments, it also posses the challenge of managing them at scale. This gives rise to some very interesting use cases that were not possible earlier. Some examples of these are fault injection, circuit breakers, distributed tracing etc.

1. Service Mesh - An architectural pattern
for modern application networking

2. Application Architecture Evolution
Application architecture getting more distributed
Apps across
multiple
infrastructures
GEN 1
GEN 2
GEN 3
Monolith Apps - On-Prem
Virtual, across 2-3
clouds
Containerized, across
multiple public and
on-prem clouds
On-
Prem
MultiplePublic
andOn-Prem
Clouds
Controller
Controller

3. Generation 1: The Monolith Application Services
• A few, large appliances provide services
• All traffic funneled through appliances
• All kinds of weird contortions are necessary
for service insertion, IP addressing, etc.
• Still Missing: No automation, no uniform
object model, doesn’t scale, no single point of
management, proprietary, poor capacity
management/utilization,
no transparent security (encryption,
authentication, RBAC)
App3App3
App4App4
App2App2
App1App1
App5App5

4. Generation 2: The Distributed Fabric
• Distributed fabric of load balances provide services
• All traffic funneled through distributed fabric
• Advantages: Centrally managed, automation,
scales reasonably well, capacity management
App1App1
App2App2
App3App3
App4App4App5App5
Controller
LB
LB
LB
• Still missing: security - authentication,
authorization & RBAC, etc.

5. Monitor
Real Time Telemetry
Actionable Metrics
Analytics
Secure
Multi-tenancy, Policy Management
Application Firewall/
Front-End WAF
Discover
Load Balancing (N/S, E/W)
DNS(Service Naming)
IPAM (Service IP)
Deployment/Upgrades
Rapid Deployments/
Automation
Canary/Traffic Limit
(B/G Deployment)
Multi-Cloud Support
(GSLB)
Encryption (SSL, TLS)
Challenges

6. Application Architecture Evolution
Cloud/ResourceManager
Microservices Cluster
Network
Service Proxy/
Distributed Load Balancing
Visibility/
Application Perf Monitoring
Service Discovery
MicroSegmentation, WAF (L3-L7
Security, XSS, DDoS protection)
Servers – Physical/Virtual
Network
Firewall & Security
Visibility/Monitoring
Service Discovery (IPAM/
DNS)
Distributed LB/Traffic
Management
Cloud/Resource Manager
Service Schedulers / PaaS
Infrastructure Stack
KubeProxy, HAProxy, NGINX, Envoy
Prometheus, Grafana, ELK
KubeDNS, CoreDNS, Consul
IPTables, Cilium, CNI
Production Ready
Clusters
On-Prem H/W
Switches/
Routers
Cloud Infra

7. Service Mesh Is ….
Servers – Physical/Virtual
Network
Firewall & Security
Visibility/Monitoring
Service Discovery (IPAM/
DNS)
Distributed LB/Traffic
Management
Cloud/Resource Manager
Service Schedulers / PaaS
Infrastructure Stack
Simplification
Service Mesh
A centrally managed,
client-side load balancer,
firewall, and APM.

8. High Level Service Mesh Architecture

9. Easy rules configuration and traffic routing lets you
control the flow of traffic and API calls between
services.
It simplifies configuration of service-level properties:
- circuit breakers,
- timeouts,
- and retries.
Makes it a breeze to set up important tasks like
- A/B testing,
- canary rollouts,
- and staged rollouts with percentage-based
traffic splits.
Traffic Management

10. Security:
Security capabilities free developers to focus on security at the application level.
Mainly provides, the following :
- underlying secure communication channel,
- and manages authentication, authorization, and encryption of service communication at scale.
So in summary - Service communications are secured by default, letting you enforce policies
consistently across diverse protocols and runtimes – all with little or no application changes.
Observability:
Provides robust:
- tracing,
- monitoring,
- and logging give you deep insights into your service mesh deployment.
Security And Observability

11. Service Mesh - A Different Perspective
Operators
Tracing, AppMap, Metrics, App Logs
Security
End to End Authentication
and Authorization,
Traffic Encryption, RBAC,
Policy Enforcement
Developers
Granular CI/CD, Canary, B/G
Deployments,
Resiliency, Mirror, Intelligent Routing
and LB, Retries, Circuit Breaker,
Error Injection, Rate Limiters.

12. Is it enough ?
Great, but...

13. Ingress
Elastic
Ingress Security
Black/White lists, Rate limiters, DoS, WAF, TCP over TLS
SSO
App authentication
What’s still required ?
Multi-cluster
Stretch across clusters with isolation & security
Multi-environment
Extend Mesh to VM/baremetal
Multi-Cloud
Automated for all environments, regions
RBAC
Enterprise AD or LDAPIngress
Cluster 2, Region 2
Cluster 1, Region 1
Built-In Analytics Across
w/ Multi Cluster Support

14. Some Features Enterprises Look in an N/S LB.
• Elastic scale out/in and intelligent placement
• Edge LB, ingress and gateway for any environment
• Global LB for availability across regions
• iWAF
• iSSO authentication for SAML, OIDC, LDAP, Kerberos, etc. Enterprises need single sign-on (SSO) for authentication and
authorization, and role-based access control (RBAC) that integrates with enterprise active directory (AD) or LDAP.
● Full isolation and enterprise-grade security, including black/white (B/W) lists, rate limiters, denial of service (DoS) protection, web
firewall (WAF), TCP over TLS, zero trust security, and more.

15. K8S CLUSTER
Pod 1
Pod 2
Ingress Gateway Deployment Model
Tenant A Tenant B
K8S CLUSTER
Pod 1
Pod 2
Tenant A Tenant B

16. Why Multi Cluster - Use Cases
• High Availability across Clusters.
• Reduce dependency on Public Cloud Infrastructure.
• Multi-Tenancy - Tenant per Cluster.
• Shared Application Pattern.
• Stateful Apps - Not true hyper-converged way.
• Legacy Applications, still sitting on a different infrastructure.

17. Feature Requirements for a Multi-Cloud/Infrastructure Mesh
• Multi-Cluster
– Network plugin independent - direct pod reachability not required
– Network topology independent - agnostic of topologies within DC/Cloud
– Isolation - Expose just services that need to be exposed outside of cluster
– Secure - Pods and services aren’t exposed to outside
– Scalable - Doesn’t need larger and larger subnets
• Multi-Cloud
– Multi-cloud ready - works in any IaaS cloud/cluster environment, e.g., VMware, bare metal, OpenStack, AWS,
Azure, GCP
• Multi-Region
– Multi-region ready - works across regions with GSLB
• Legacy
– Seamlessly bridge services in and out of mesh

18. K8S CLUSTER 1
VM/BARE METAL
CLUSTER 3
AWS/Azure/
GCP
Pod 1
Pod 2
Pod 40
Multi Cluster Deployment Model 1 - Routable Clusters
Multi-CloudMulti-Cluster
Multi-cloud
" Same issues get more complex in this
scenario.
Multi-cluster
" Network plugin & topology Dependent
" Clusters & Services are NOT isolated, and
secure.
K8S CLUSTER 2
Pod 1
Pod 2

19. K8S CLUSTER 1
VM/BARE METAL
CLUSTER 3
AWS/Azure/
GCP
Pod 1
Pod 2
Pod 40
Multi Cluster Deployment Model 2 - Gateway Based.
Multi-CloudMulti-Cluster
Multi-cloud
" Public or Private cloud
" VMware, OpenStack, bare metal
" AWS, Azure, GCP
Multi-cluster
" Network plugin & topology independent
" Clusters & Services are isolated, secure,
scalable and available
K8S CLUSTER 2
Pod 1
Pod 2

20. K8S CLUSTER 1
VM/BARE METAL
CLUSTER 3
AWS/Azure/
GCP
Pod 1
Pod 2
Pod 40
Multi Cluster Deployment Model 3 - Federated Mesh
Multi-CloudMulti-Cluster
Multi-cloud
" Public or Private cloud
" VMware, OpenStack, bare metal
" AWS, Azure, GCP
Multi-cluster
" Network plugin & topology independent
" Clusters & Services are isolated, secure,
scalable and available
K8S CLUSTER 2
Pod 1
Pod 2

21. K8S CLUSTER 1
VM/BARE METAL
CLUSTER 3 AWS/Azure/
GCP
Pod 1
Pod 2
Pod 40
Multi Cluster Deployment Model - Master Controller
Multi-CloudMulti-Cluster
Multi-cloud
" Public or Private cloud
" VMware, OpenStack, bare metal
" AWS, Azure, GCP
Multi-cluster
" Network plugin & topology independent
" Clusters & Services are isolated, secure,
scalable and available
K8S CLUSTER 2
Pod 1
Pod 2

22. K8S CLUSTER 1
VM/BARE METAL
CLUSTER 3
AWS/Azure/
GCP
Pod 1
Pod 2
Pod 40
Multi Cluster/Cloud Deployment Pattern 5
Legacy
Bridge Service
Mesh to Legacy
K8S CLUSTER 2
Pod 1
Pod 2
Legacy
LEGACY CLUSTER 4
Legacy

23. Key Takeaways
1. Advanced Integrated Ingress Gateway
– L4-7 load balancing with SSL offload
– GSLB for inter/intra-cluster traffic management
– Web application firewall (WAF) for app security
2. Universal
– Multi-cloud: Single service mesh for clusters across
on-premises data centers and public clouds
– Multi-infra: Service mesh for VM, bare metal, and
containerized workloads
3. Real-Time Analytics w/ co-relation
– Application performance monitoring and tracing.
– Connection log analytics.
– Machine-learning-based insights & health analytics
4. Operational Simplicity
– No need to maintain separate Service Mesh
Instances - Centrally Managed Multi-Cluster Mesh.
– Fully integrated multi-tenancy, RBAC, DNS, IPAM

24. Thank you