One of the most complex challenges in realizing microservice architecture is not building the services themselves, but building and governing the communication between services. Most microservices developers have to take care of complex inter-service communication logic as part of their service development. Service Mesh has emerged as a solution to overcome the challenges that we have in microservices communication. Since most of the inter-service communication requirements are quite generic across all microservices implementations, we can think about offloading all such tasks to a different layer, so that we can keep the service code independent. This presentation will discuss the following: 1) Why we need a Service Mesh? 2) Fundamentals of Service Mesh 3) Introduction to Istio 4) What's new in Istio 1.0. 5) Seamless integration of Ballerina and Istio

1. Service Mesh in Practice
KASUN INDRASIRI
Director – Integration Architecture, WSO2
DAVID MUNRO
Product Manager – Istio, Google

2. Introduction to Service Mesh

3. Why Do We Need Service Mesh?
○ Microservices/cloud native applications are connected via network calls
○ Building inter-service communication is the hardest thing in realizing the
microservices architecture
○ Decentralized architecture → No central point of governance

4. From ESB to Smart Endpoints and Dumb Pipes
○ Centralized ESB layer provides integration and network communication
and governance capabilities
Virtual
Service 1
Service A
Virtual
Service 2
Virtual
Service 3
Service B Service C Service D
ESB
Consumers

5. From ESB to Smart Endpoints and Dumb Pipes
○ Microservices code has to take care of all network communication and
governance of services
Microservice
X
Microservice
P
Microservice
Y
Microservice
z
Microservice
Q
Microservice
R
Microservice
S
Java
Consumers
Node.js Go

6. Composition of a Microservice
○ Microservices comprise of the business logic and the network
communication logic
Business
Logic
Network Stack
Microservice A
Network Stack
Business
Logic
Network
Functions
Network
Functions
Microservice B

7. Key Components of a Service Mesh
Microservice A
Network Stack
Sidecar
Microservice B
Network Stack
Sidecar
Control Plane
HTTP1.x, HTTP2, gRPC,
TCP
Application Network Functions
Business
Logic
Primitive
Network
Functions
Data Plane

8. Key Functionalities
○ Resilient inter-service communications: Circuit breaker, retry, timeout, etc.
○ Routing
○ Service discovery
○ Observability
○ Security
○ Multi protocols support - HTTP/s, gRPC

9. Istio Overview

10. Securing service
traffic
Operational
agility
Uniform
observability
Istio Value
Proposition

11. Architectural
components
Pilot: Control plane to configure and
push service communication policies.
Envoy: Network proxy to intercept
communication and apply policies.
Mixer: Policy enforcement with a flexible
plugin model for providers for a policy.
Citadel: Service-to-service auth[n,z]
using mutual TLS, with built-in identity
and credential management.
Istio
Security
Pilot Mixer
Control Plane API
Service A Service B
proxy proxy
HTTP/1.1, HTTP/2,
gRPC or TCP --
with or without
mTLS
Config data
to Envoys
TLS certs to
Envoys
Policy checks,
telemetry

12. ○ Enable mTLS for authentication and encryption.
○ Authorize access based on service identity or
any channel attribute.
○ Configure finer grained RPC-level access control
for REST and gRPC.
What can you do with Istio security?

13. Why do we support mTLS via Istio?
Policy driven encryption in transit
with no code changes
… but that’s only the obvious value …..

14. … the real value is strong authentication
Logging Shared Service
(compromised)
Order
Processing
Service
Credit Card Info
Service
Channel
bound
identity
Channel
bound
identity
Order processing
identity cannot
be replayed
○ Peers are authenticated using
non-replayable service identities bound
to the TLS channel.
○ Similar to ALTS, Istio strongly
authenticates the workload identity and
not the host.
○ End user or application level identity is
propagated as a bearer token across
service “hops”.

15. Mixer: send metrics where you want them
frontend
proxy
API: /pictures
Latency: 10ms
Status Code: 503
src: 10.0.0.1
dst: 10.0.0.2 Mixer
AdaptersMixer
Mixer has an open
API and a pluggable
architecture: send
telemetry, logs and
traces to your system
of choice
Input policy from your
choice of policy
source

16. Pilot: configuring the data plane
Pilot pushes service
registry info and all
routing rules to Envoy
proxies -- sidecars
and ingress
Service A Service B
proxy proxy
Routing and
load
balancing
config to
Envoys
Pilot

17. How does Istio help?
With Istio, you can
control traffic by
routing
// A simple traffic splitting rule
destination: serviceB.example.cluster.local
match:
source: serviceA.example.cluster.local
route:
- tags:
version: v1
env: us-prod
weight: 90
- tags:
version: v2
env: us-staging
weight: 10

18. Ballerina and Istio

19. Ballerina with Istio
○ Seamlessly integrates with Istio
Metrics
(Prometheus &
Grafana)
Tracing
(Jaeger)
Client
Envoy
(sidecar proxy)
Pilot Mixer Istio Auth
Istio Control Plane
Time-Service

20. Ballerina Service for Istio ...
import ballerinax/kubernetes;
@kubernetes:Service {
serviceType:"NodePort",
name:"ballerina-time-service"
}
endpoint http:Listener listener {
port:9095
};
@kubernetes:Deployment {
image: "ballerina-time-service",
name: "ballerina-time-service",
singleYAML:true
}
@http:ServiceConfig {basePath:"/localtime"}
service<http:Service> time bind listener {
@http:ResourceConfig{
path: "/", methods: ["GET"]
}
getTime (endpoint caller, http:Request request)
{
_ = caller -> respond(response);
...
○ Add Kubernetes deployment and
service annotation
$build time_service.bal
○ Manual sidecar injection
$istioctl kube-inject
-f time_service.yaml
-o time_service_istio.yaml
○ Deploy
$kubectrl apply -f time_service_istio.yaml

21. Ballerina without Service Mesh
○ Ballerina has inbuilt capabilities to facilitate:
○ Resilient inter-service communication
○ Observability: Metrics, tracing, logging
○ Security: TLS, OAuth, JWT
○ Multi-protocol support: HTTP1/2, gRPC, AMQP, Kafka
○ Service discovery

22. Ballerina without Service Mesh - When?
○ You are not using a Service Mesh
○ Asynchronous event-driven messaging
○ Business logic depends on the network functions

23. Summary
○ Service mesh reduces the complexity of inter-service communication and
governance of those interactions.
○ Business logic shouldn’t be part of service mesh.
○ Istio overview.
○ Ballerina can work with or without service mesh.

24. Q & A

25. THANK YOU