The document discusses the transition from monolithic to microservices architecture and the role of service meshes in modern applications. It outlines the necessity of microservices for dynamic, distributed apps, and the challenges of operating such applications, highlighting the maturity journey of applications regarding the need for a service mesh. The summary emphasizes that while service meshes add complexity and are not yet mature, they provide essential functionalities for managing interdependent applications as technologies evolve.

1. NGINX Microservices
and Service Mesh

2. Agenda
1. Why Microservices?
◦ Best practices for extending existing applications
2. Why might we need a Service Mesh?
◦ Alternatives – how to tell when you’re ready
3. The Landscape
◦ Istio and others
4. Summary
◦ Next steps

3. Why Microservices?
1

4. 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

5. Architectural
Changes: Monolith

6. Architectural
Changes: Monolith
to Microservices

7. Microservices
"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

8. In practice
• Use the “Strangler Approach” 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.
Holiday Photos

9. Evolution in Action
Existing Monolith Application
Desktop or Web
Client
Your Existing Application

10. Evolution in Action
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?

11. Evolution in Action
11
Implement Hybrid/Strangler Pattern
1. Implement connector microservices to provide
API abstractions for external dependencies

12. Evolution in Action
2. Implement business-logic microservices for each
business process
Implement Hybrid/Strangler Pattern

13. Evolution in Action
13
3. Implement presentation-layer microservices that
are accessed externally
Implement Hybrid/Strangler Pattern

14. Evolution in Action
14
4. Use NGINX Ingress Controller for external-
internal connectivity
Implement Hybrid/Strangler Pattern

15. Evolution in Action
15
5. Use NGINX Router Mesh for internal connectivity
Implement Hybrid/Strangler Pattern

16. Evolution
16
Successful Hybrid/Strangler Implementation

17. Why do I need a Service Mesh?
(and do I need one now?)
2

18. 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

19. 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
More things can go wrong, it’s harder to find the faults, everything happens live

20. Why do I need a Service Mesh?
• 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

21. Maturity Journey – Step 1
• 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

22. Maturity Journey – Step 1
Simple Ingress Router, Kubernetes Networking
Many production applications
start and finish here
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

23. What is an Ingress Controller?
Kubernetes
Master
API Server
Scheduler
Controller-
Manager
etcd
Kubernetes Node
Kubelet
Kubeproxy
Kubernetes Node
Kubelet
Kubeproxy
Kubernetes Node
Kubelet
Kubeproxy
InternalNetwork
Why do
you need
an Ingress
Controller?

24. Ingress Resource
• 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
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. Maturity Journey – Step 2
• 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

26. Maturity Journey – Step 2
Ingress Router, Per-Service Load Balancer,
Router-mesh Load Balancer
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
Most production apps running
in containers over the last ~3
years have taken this
approach
P O
T S

27. But… this approach gets expensive to manage
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

28. Maturity Journey – Step 3
• 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

29. Maturity Journey – Step 3
Every container has an embedded proxy
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

30. A Service Mesh sounds great….?
• 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

31. Find the balanceCosttooperate
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

32. Service Mesh Landscape
3

33. Istio is seen as the market leader… but…
“In Istio, we see Google’s expertise in marketing perhaps taken too far.
“Istio … is convincing the market that the battle for service mesh
superiority is a foregone conclusion–in spite of widespread reports that
Istio is currently difficult to operate and not ready for production
workloads.”
Eric Brewer, VP Infrastructure, Google. April 26, 2019
https://softwareengineeringdaily.com/2019/04/26/cloud-with-eric-brewer/

34. Current Landscape
• Pure-play Service Meshes
◦ Istio, Linkerd, Consul Connect
• Cloud Platform Service Meshes
◦ Amazon App Mesh, GCP Traffic Director
• Meta-Meshes
◦ SMI, Solo.io SuperGloo, …

35. Hype CycleVisibility
Time
Technology Trigger
Peak of Inflated Expectations
Trough of Disillusionment
Slope of
Enlightenment
Plateau of Productivity

36. Summary
4

37. SummaryCosttooperate
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
• 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

38. Recommendations
• 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?

39. F5 and NGINX
Aspen Mesh provides an easy-
to-use distribution of Istio with
added enterprise features.
• Enterprise Service Mesh
• Observability and Insights
• Expert Support
NGINX provides an advanced
Ingress Controller,
Microservices Proxy and
innovative App Server:
• K8s Ingress Controller
• NGINX Router
• Future service mesh
iniatives