Service Mesh enables service to service communications in Micro services world.

1. Microservices Architecture
S e r v i c e M e s h
M a n a g i n g S e r v i c e - t o - S e r v i c e c o m m u n i c a t i o n s i n M i c r o s e r v i c e s w o r l d
“Microservices architecture describes a way to design software applications as suites of independently
deployable services.”
- Martin Fowler
Satya SYAM

2. AGENDA
S E R V I C E M E S H
Revisit the Microservice architecture
M I C R O S E R V I C E S A R C H I T E C T U R E
What problems Service Mesh solves?
S E R V I C E M E S H
What are the challenges of Microservice architecture
M I C R O S E R V I C E S C O N C E R N S
What are service mesh implementations?
30000 FT view of ISTIO
S E R V I C E M E S H I M P L E M E N T A T I O N S
Decision Tree & Key Takeaway
C O N C L U S I O N

3. M I C R O S E R V I C E S A R C H I T E C T U R E
Business Logic
Monolithic
Architecture
User Interface
Data Interface
User Interface
Microservice Microservice
Microservice
Microservice
Microservices Architecture
Database per service

4. M I C R O S E R V I C E S C O N C E R N S
Microservice
Operations
Code
Business Logic
• These are cross cutting concerns
applications to microservices and are
necessary to implement microservices.
• These operations code could be
common to most of the microservices
• Business functionality implemented as
part of the services
• The actual implementation of what
service is all about
• Developers should focus on this area
Operations
Code
Business
Logic
R O U T I N G
A B
• Traffic Control
• Resilience
• Discovery
S E C U R I T Y
A B
• Policy
• Certificates
• Authentication and Authorization
O B S E R V A B I L I T Y
A
B 1
B 2
B 3
• Metrics
• Logs
• Monitoring
• Tracing
O P E R A T I O N S C O D E
Source: solo.io
Source: Alibabacloud.com
Complexity with multiple tech stacks

5. S E R V I C E M E S H
The service mesh pattern is focusing on managing all service-
to-service communication (East to West) within a distributed
software system
C o n t e x t
The context for the pattern is twofold:
• Adaption of microservice architecture
pattern building applications by
composing multiple services that can
be independently deployable.
• Organization embracing cloud native
platform technologies such as
containers, orchestrators, and
proxies/gateways
I n t e n t
• Eliminating the need to compile into individual services a language-
specific communication library to handle service discovery, routings, and
application-level (Layer 7) non-functional communication requirements.
• Externalizing service communication configuration, including network
locations of external services, security credentials, and quality of service
target
• Decentralizing the enforcement of policy throughout a distributed system.
• Providing observability defaults and standardizing the collection of
associated data and manage monitoring (Providing passive and active
monitoring of other services)
Source: infoq.com

6. S E R V I C E M E S H - B E F O R E A N D A F T E R
Operations
Code
Business Logic
Microservice
Operations
Code
Business Logic
Microservice
Operations
Code
Business Logic
Microservice
B E F O R E
Operations
Code
Business Logic
Microservice
A F T E R
Operations
Code
Business Logic
Operations
Code
Business Logic
Microservice
Source: solo.io
Microservice

7. S E R V I C E M E S H - D E S I G N P A T T E R N S
S I D E C A R P A T T E R N
Deploy components of an application into a
separate process or container to provide
isolation and encapsulation. This pattern
can also enable applications to be
composed of heterogeneous components
and technologies.
Primary App
Core Function
Side Car
Peripheral Tasks
Logging
Configuration
Proxy
Platform Abstraction
H O S T
A M B A S S A D O R P A T T E R N
This pattern can be useful for offloading common
client connectivity tasks such as monitoring, logging,
routing, security (such as TLS), and manage resiliency
patterns in a language agnostic way. It is often used
with legacy applications, or other applications that are
difficult to modify, in order to extend their networking
capabilities. It can also enable a specialized team to
implement those features.
Primary App
Core Function
Ambassador
Peripheral Tasks
Retry
Circuit Breaking
Monitoring
Security
H O S T
Remote
Service
Deployed as a side car
Source: Microsoft

8. S E R V I C E M E S H - I M P L E M E N T A T I O N
S E R V I C E M E S H I N T E R F A C E
• Standard interface for service mesh, it’s a specification
allows the implementation-agnostic development of
tools based on service mesh features.
• Service Mesh users can change their service mesh
implementation with out need to change
configuration.
• Built by Microsoft, Buoyant, Hashicorp to built
common standard.

9. S E R V I C E M E S H - I M P L E M E N T A T I O N
O R C H E S T R A T I O N - S I M P L I F I E D
Traffic Control
Enforce routing rules & policies
Resiliency - Circuit Breaker, Retries
Monitoring - Record metrics
Observability - Record traces
Security - Mutual TLS! Encryption
1
2
3
4
5
P R O X Y
Service A wants to call Service B
Service Mesh Intercepts request transparently forwards
to local Proxy
Proxy has destinations defined to load balance
request to destination proxy
If allowed, destination proxy forwards request to
Service B
Service B response to the caller

10. S E R V I C E M E S H - I M P L E M E N T A T I O N
I S T I O – 3 0 0 0 0 F T V I E W
D A T A P L A N E
Data plane is the delivery system of service mesh. It is made of proxies
responsible for forwarding requests.
All necessary configuration to forward requests are received from
control plane (Service registrations, intentions, config entries etc.)
Requests get routed to services within the mesh.
Information of availability, health of the services of each node is sent
back to control plane.
C O N T R O L P L A N E
Control plane is central hub of activity for the mesh.
Security policies (policies for traffic flow) resides in control plane.
It manages resiliency to remove unhealthy services are removed from
the mesh.
I S T I O
D A T A P L A N E
Envoy
I S T I O
C O N T R O L P L A N E
Pilot
Citadel
Gallery
Data
Plane
Control
Plane

11. S E R V I C E M E S H - I M P L E M E N T A T I O N
I S T I O - F E A T U R E S
S e c u r e
C o m m u n i c a t i o n
• mTLS
• Certificate Management
• Authentication
• Authorization
C o m m u n i c a t i o n
P r o t o c o l s
• TCP
• HTTP/1.X
• HTTP/2
• gRPC
R e s i l i e n c e
• Circuit Breaking
• Retry and time out
• Fault Injection
• Rate Limiting
C h a o s M o n k e y
T e s t i n g
• Testing
O b s e r v a b i l i t y
• Monitoring
• Distributed Tracing
Multi Cluster Supported
Supported in both Kubernetes + VM + Cloud
T r a f f i c
M a n a g e m e n t
• Blue/Green Deployment
• Load Balancing
• Percentage based traffic splits /
Canary Deployment
M o n i t o r i n g
F e a t u r e s
• Access Logs
• Metrics Generation
• Integrated
• Prometheus
• Graphana
• Dashboards
• Compatible tracing backends
S M I
C o m p a t i b i l i t y
• Traffic Access Control
• Traffic Specs
• Traffic Split
• Traffic Metrics
P l a t f o r m &
E x t e n s i b i l i t y
• Cloud integrations
• Mesh Expansion
• Multi Cluster Mesh

12. C O N C L U S I O N - D E C I S I O N T R E E &
T A K E A W A Y
▪ Service Mesh is clearly in early adaption phase with organizations
exploring opportunities to explore.
▪ It has lot of benefits, taking out all necessary cross cutting concerns out
and abstracting from the micro service itself
▪ Its code is independent. Irrespective of any programming language
cross cutting concerns are the same and implemented.
▪ Configuration process and parameterization are the same in all the
services.
▪ Service Mesh pattern aligns itself closely to DEVOPS principles
D r i v i n g
F a c t o r s
Service landscape and requirements
Running in multiple clusters
Policies and restrictions
Robust rollout strategies
T a k e A w a y

13. R E F E R E N C E S
https://istio.io/latest/docs/setup/getting-started/
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/service-mesh-communication-infrastructure
https://www.solo.io/
https://cloud.google.com/learn/what-is-istio