Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Download to read offline

Service mesh and the future of microservices at scale

Download to read offline

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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Service mesh and the future of microservices at scale

  1. 1. Service Mesh - An architectural pattern for modern application networking
  2. 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. 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. 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. 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. 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. 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. 8. High Level Service Mesh Architecture
  9. 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. 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. 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. 12. Is it enough ? Great, but...
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. Thank you

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.

Views

Total views

48

On Slideshare

0

From embeds

0

Number of embeds

0

Actions

Downloads

0

Shares

0

Comments

0

Likes

0

×