The 7 Things I Know About Cyber Security After 25 Years | April 2024
Do I Need A Service Mesh.pptx
1.
2. Do You Need A Service Mesh
Rick Nelson
RVP Professional Services, NGINX
3. Why Microservices?
• Best practices for extending existing applications
Why might you need a Service Mesh?
• Alternatives – how to tell when you’re ready
The Landscape
• Istio and others
Summary
• Next steps
1
2
3
4
Agenda
8. Microservices
8
"An approach to developing a
single application as a suite of
small services, each running in its
own process and communicating
with lightweight mechanisms,
often an HTTP resource API”.
Martin Fowler, 12-Factor App
9. In practice
9
• Use the “Strangler Pattern” to extend your
Monolith to using Microservices:
1. Add small pieces of functionality in Microservices.
2. Repeat as needed
• Organize team structure around service
ownership.
• Adopt DevOps mentality – automate when
possible.
11. Evolution in Action
11
You have New Use Cases
New applications are needed
New datasources and business processes are added
How do we add the new
use cases without
large-scale rewrites?
12. Evolution in Action
12
Implement Hybrid/Strangler Pattern
1. Implement connector microservices to
provide API abstractions for external
dependencies
18. Why do I need a Service Mesh?
(and do I need one now?)
2
19. Modern Apps Require a Modern Architecture
From Monolithic ... ... to Dynamic
Three-tier, J2EE-style architectures
Complex protocols (HTML, SOAP)
Persistent deployments
Fixed, static Infrastructure
Big-bang releases
Silo’ed teams (Dev, Test, Ops)
Microservices
Lightweight (REST, JSON)
Containers, VMs, Functions
Infrastructure as Code
Continuous delivery
DevOps Culture
20. Operating a distributed application is hard
Static, Predictable Monolith: Dynamic, Distributed App:
Fast, reliable function calls
Local debugging
Local profiling
Calendared, big-bang upgrades
‘Integration hell’ contained in dev
Slow, unreliable API calls
Distributed fault finding
Distributed tracing
In-place dynamic updates
‘Continuous integration’ live in prod
21. Why do I need a Service Mesh?
21
• In most cases, you do not need a service mesh
(at least, not
yet)
• Your applications will go through a maturity journey:
1. Pre- or early-production applications, mature ‘mode 1’ applications
2. Single simple, business-critical production applications
3. Multiple complex, distributed applications
This is where you may
need a service mesh
22. Maturity Journey – Step 1
22
• Pre- and Early-Production Applications, Established Apps
◦ My applications are simple and well understood
◦ I don’t make disruptive changes in production
• Kubernetes provides the capabilities you need:
◦ Service Discovery and Scaling
◦ Load Balancing and Health Checks
◦ Access Control
◦ Ingress Load Balancing
For example, legacy
‘monolithic’ or 3-tier apps that
have been containerized
Many production
applications start and
finish here
23. Maturity Journey – Step 1
23
Rely on Kubernetes for:
• DNS-based Service Discovery
• Scaling and reconfiguration
• KubeProxy-based load balancing
• Health Checks
• Network Policies for Access Control
Use a third-party Ingress Router
Many production
applications start and
finish here
Simple Ingress Router,
Kubernetes Networking
24. What is an Ingress Controller?
24
Kubernetes
Master
API Server
Scheduler
Controller-
Manager
etcd
Kubernetes Node
Kubelet
Kubeproxy
Kubernetes Node
Kubelet
Kubeproxy
Kubernetes Node
Kubelet
Kubeproxy
Internal
Network
Why do
you need
an Ingress
Controller?
25. Ingress Resource apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-ingress
spec:
tls:
- hosts:
- hello.example.com
secretName: hello-secret
rules:
- host: hello.example.com
http:
paths:
- path: /
backend:
serviceName: hello-svc
servicePort: 80
25
• Ingress:
◦ Built-in Kubernetes resource
◦ Configuration for an edge load
balancer (or ADC)
• Ingress features:
◦ L7 routing based on the host
header and URI
◦ TLS termination
26. Maturity Journey – Step 2
26
• More complex, business-critical applications
◦ Applications have multiple, distributed components
◦ Changes in production are frequent
◦ Users need more control and visibility over the app
• Individual services can be enhanced with:
◦ Mutual TLS for encryption and authentication
◦ Metrics and Tracing (Prometheus, OpenTracing etc)
◦ Proxies for load balancing, rate limiting,
access control, traffic management
Most production apps
running in containers
over the last ~3 years
have taken this
approach
27. Maturity Journey – Step 2
27
Enhance applications with:
• Prometheus metrics
• OpenTracing tracers
• mTLS or SPIFFE ssl
Use per-service proxies for specific
services
Use central router-mesh proxy load
balancer
Ingress Router, Per-Service Load Balancer,
Router-mesh Load Balancer
P O
T S
Most production apps
running in containers
over the last ~3 years
have taken this
approach
28. But… this approach gets expensive to
manage
28
The operational complexity and cost of developing bespoke
libraries across languages, frameworks, and runtimes is
prohibitive for most organizations, especially those with
heterogenous applications and polyglot programming
languages.
IDC Market Perspective:
Vendors Stake Out Positions in Emerging Istio Service Mesh Landscape
29. Maturity Journey – Step 3
29
• Multiple interdependent applications
◦ Diverse application stacks (challenging to extend consistently)
◦ Frequent, hard-to-control changes (need rapid troubleshooting)
• Service Mesh provides enhancements, invisibly
◦ Intercepts all network traffic for each service
◦ Injects security (mutual TLS)
◦ Generates metrics and traces
◦ Can support L7 policies e.g. authentication,
rate limiting, traffic management
A service mesh provides
standard functionality and
services in an invisible,
universal fashion
30. Maturity Journey – Step 3
30
Embed proxy into every container
Proxy intercepts all traffic and applies
advanced functionality
Proxy implements L7 policies
Requires a comprehensive control
plane
A service mesh provides
standard functionality and
services in an invisible,
universal fashion
Every container has an embedded proxy
31. A Service Mesh sounds great….?
31
• Service Mesh implementations are new and not yet
mature. Implementations are changing rapidly and some
may be obsoleted quickly.
• Service Mesh has a cost, adding complexity, resource
requirements and latency (network hops). ROI is not clear
Don’t let the lack of a stable, mature service mesh
delay your container and microservice initiatives
32. Find the balance
32
Cost
to
operate
Complexity, Interdependencies, Speed of Change
Single simple app Many complex, interdependent apps
Using native Kubernetes
and other services
Using
service mesh
As service meshes mature,
their cost will go down
39. Summary
39
• There is a tipping point,
before which, a service
mesh is not advised
• As service meshes become
easier to deploy and more
mature, the tipping point gets
closer
• Service Mesh technology is
changing rapidly – it’s very
early to place a bet
Cost
to
operate
Complexity, Interdependencies, Speed of Change
Single simple app Many complex, interdependent apps
Using native Kubernetes
and other services
Using
service mesh
As service meshes
mature, their cost will go
down
40. Recommendations
40
• Investigating – too early to devote significant resources
• PoC – commercial Istio builds, open source Consul and
Linkerd
• Production – are you ready to build an F1 pit crew?
41. F5 and NGINX
41
Aspen Mesh provides an easy-to-
use distribution of Istio with added
enterprise features.
NGINX provides an advanced
Ingress Controller, Microservices
Proxy and innovative App Server:
42. F5 and NGINX
42
Aspen Mesh provides an easy-to-use distribution of Istio with
added enterprise features.
• Enterprise Service Mesh
• Validates Configuration
• Observability and Insights
• SaaS-based dashboard
• Tracing, Alerting
• Expert Support
43. F5 and NGINX
43
NGINX provides an advanced Ingress Controller, Microservices
Proxy and innovative App Server:
• K8s Ingress Controller
• NGINX Router
• Unit
• Future service mesh initiatives
