This presentation gave an introduction to Istio and service mesh, as well as a description of how service mesh fits in with API Management.

1. Introduction to Istio: 1.0, and
APIs & Microservices
Dan Ciruli, Product Manager
@danciruli

2. “Who is this guy?”
“What is a service mesh and why are
you doing this?”
“Ok, so tell me more about Istio.”
“What’s the life of a request?”
“What have you done for me lately?”
“What does this have to do with API
Management?”
Things I’m going to
talk about

3. “Who is this guy?”

4. “What is a service mesh and why
are you doing this?”

5. What is a
service
mesh?
A service mesh provides a
transparent and
language-independent
way to flexibly and easily
automate application
network functions.

6. Distributed
world
The trends of containerization, microservices
and hybrid/multi-cloud deployments have
created more distributed applications than ever.
Developers, devops and secops personnel need
modern tools to secure, manage and monitor
distributed applications.

7. Separate
applications from
infrastructure

8. Decouple operations
from development
Separation of
concerns

9. “Ok, so tell me more about Istio”

10. What Is Istio?
An open services
platform to manage
service interactions
across container- and
VM-based workloads

11. Istio Value
Proposition Observability
Control
Security

12. Istio Observability
● Transparently collect golden signals
(traffic, error rates, latency)
● Monitor uniform service level
indicators for every service
● Collect logs and traces for deep
understanding of service behavior
● Clearly map service
interdependencies
● Improved understanding of
applications at the service (not
network) level

13. Istio Control
Change retry, circuit-breaking and routing
behavior without changing code
Roll out new versions to canary without
worrying about ops challenges
Apply access control and rate limiting
policies to protect services from bad
behavior

14. Istio Security
● Secure by default - new and existing
applications.
● Meet compliance obligations by
encrypting data in transit.
● mTLS assures a secure, proven
service-based identity for every call
● With strong identity, authorization can
be explicitly required

15. Istio Architecture
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.
Control Plane API
Mixer
Service A Service B
proxy proxy
HTTP/1.1,
HTTP/2, gRPC or
TCP -- with or
without mTLS
Pilot Citadel
Config data
to Envoys
TLS certs to
Envoys
Policy checks,
telemetry

16. Pilot: Configuring
the data plane ● Observe service topology
○ Kubernetes pods, services &
ingress rules
○ Aware of VM based services in
mesh via Consul integration
● Routing rules
○ Merge with routing rules from
config
○ Roll out routing policies with no
downtime/redeployment
● Push configuration to sidecars
● Can integrate/read state from
registries like Consul, Eureka

17. Mixer: Pluggable
control plane ● All telemetry is sent (asynchronously)
● Policy checks happen synchronously
● Telemetry and logging APIs to allow
plugins of any backends
○ Telemetry, logs, traces
● Policy APIs allow plugins of arbitrary
policy backends
○ Policy (authorization, quota)
● Heavy caching at proxy and in Mixer to
retain performance and not swamp
backends

18. Citadel: service
identity-based
security
● 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
● Defence in depth - security does not
stop at the edge.
● Policy driven encryption in transit with
no application code changes.

19. Enable customers to
secure, monitor and
manage services
everywhere.
Kubernetes first, but
not Kubernetes only.
Istio Everywhere

20. (Whispers): ‘Do you really want to hear about a life of a request in the mesh?’

21. “What’s the life of a request?”

22. Life of a request in the mesh
Service A comes up. Envoy is deployed with it and
fetches service information, routing and
configuration policy from Pilot. If Citadel is being
used, TLS certs are securely distributed as well.
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Routing and
load
balancing
config to
Envoys
TLS certs to
Envoys

23. Life of a request in the mesh
Service A places a call to service B.
Client-side Envoy intercepts the call.
Envoy consults config to know how/where to route
call to service B (including any dynamic routing
rules).
Mixer
Service A Service B
proxy proxy
Pilot Citadel

24. Life of a request in the mesh
Envoy forwards request to appropriate instance of
service B. There, the Envoy proxy deployed with the
service intercepts the call.
Mixer
Service A Service B
proxy proxy
Pilot Citadel
HTTP/1.1,
HTTP/2, gRPC or
TCP -- with or
without mTLS

25. Life of a request in the mesh
Server-side Envoy checks with Mixer to validate that
call should be allowed (ACL check, quota check,
etc).
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Policy checks,
telemetry

26. Life of a request in the mesh
Mixer checks with appropriate adaptors (policy
engine, quota adaptor) to verify that the call can
proceed and returns true/false to Envoy
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Policy checks,
telemetryPolicyEngine
Quota
Adapter

27. Life of a request in the mesh
Server-side Envoy forwards request to service B,
which process request and returns response
Mixer
Service A Service B
proxy proxy
Pilot Citadel

28. Life of a request in the mesh
Envoy forwards response to the original caller, where
response is intercepted by Envoy on the caller side.
Mixer
Service A Service B
proxy proxy
Pilot Citadel

29. Life of a request in the mesh
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Logging
adapter
Monitoring
adapter
Envoy reports telemetry to Mixer, which in turn
notifies appropriate plugins

30. Life of a request in the mesh
Client-side Envoy forwards response to original
caller.
Mixer
Service A Service B
proxy proxy
Pilot Citadel

31. Life of a request in the mesh
Mixer
Service A Service B
proxy proxy
Pilot Citadel
Logging
plugin
Monitoring
plugin
Client-side Envoy reports telemetry to Mixer
(including client-perceived latency), which in turn
notifies appropriate plugins

32. “What have you done for me
lately?”

33. ● Extensibility, Environment &
Efficiency (Core)
● Traffic Management
● Observability
● Security
Istio tracks

34. Core
- K8s: Envoy Installation and Traffic Interception
- K8s: Istio Control Plane Installation
- Attribute Expression Language
- Mixer Adapter Authoring Model
- K8s: Istio Control Plane Upgrade
- Helm
- Multicluster Mesh
- Consul Integration
- Cloud Foundry Integration
- Basic Configuration Resource Validation
- Mixer Self Monitoring
- Custom Mixer Build Model
- Out of process Mixer Adapters (gRPC Adapter)
Traffic Management
- Memquota Implementation and Integration
- Protocols:
- HTTP 1.1
- HTTP 2.0
- gRPC
- TCP
- MongoDB
- WebSocket
- Gateway: Ingress, Egress for all protocols
- TLS termination and SNI Support in Gateways
- Traffic Control:
- Label/content based routing
- Traffic shifting
- Resilience features:
- Timeouts
- Retries
- Connection pools
- Outlier detection
- Enabling custom filters in EnvoyStable
Beta (ready for production
use)
Alpha (ready for use)
Istio 1.0

35. Observability
- Statsd Integration
- Local Logging (STDIO)
- Prometheus Integration
- Client and Server Telemetry Reporting
- Istio Component Dashboard in Grafana
- Service Dashboard in Grafana
- Stackdriver Integration
- SolarWinds Integration
- Service Graph
- Distributed Tracing to Zipkin/Jaeger
- Service Tracing
- Logging with Fluentd
- Trace Sampling
Security
- Pluggable Key/Cert Support for Istio CA
- Deny Checker
- List Checker
- Kubernetes: Service Credential Distribution
- Service-to-service mutual TLS
- VM: Service Credential Distribution
- Incremental Enablement of service-to-service mutual
TLS
- Authentication policy
- End User (JWT) Authentication
- OPA Checker
- Access Control Policy (Istio RBAC)
Stable
Beta (ready for production
use)
Alpha (ready for use)
Istio 1.0

36. What’s new in 1.0
Safely enabling mTLS on an existing service
Service A Service B
proxy proxy
mTLS
Service C
http
Not Istio enabled
Istio enabled
kind: "Policy"
metadata:
name: "example-
permissive"
namespace: foo
spec:
targets:
- name: service-B
peers:
- mtls:
mode: PERMISSIVE

37. What’s new in 1.0
gRPC Adapter
model
Mixer support for
developing out-of-
process adapters
frontend
proxy
API: /pictures
Latency: 10ms
Status Code: 503
src: 10.0.0.1
dst: 10.0.0.2 Mixer
AdaptersMixer
gRPC AdaptorsTemplate-Specific
gRPC Service

38. What’s new in 1.0
Authorization policies
Control access to services are
evaluated locally in Envoy increasing
performance and reliability
Pilot
Service A Service B
proxy proxy
Administrator
Policies for
Service A
Policies for
Service B
Auth
PoliciesIsito
Config

39. Where are we..
Istio 1.0!
● After over a year of work,
● ~200 developers
● Google, IBM, VMWare, Cisco, Red Hat, others...
● Adaptors for many monitoring systems … including Stackdriver
● Apigee Adaptor for API Management
Managed Istio:
● Available in Alpha: Istio automatically installed and upgraded with GKE

40. And, earlier today...

41. “What does this have to do with
API Management?”

42. What is API Management?
A set of features and functionality for exposing your
services as APIs to external customers and partners.

43. API Management +
Service
Management
Service management
on all your services
API
management
for the ones
you expose
to customers
and partners

44. What’s the diff?
Some sample differences between the
two.
API Management
Target audience External
Authentication JWT, API key
Rate limits Business related
Reporting needs Ops + Analytics
Documentation
needs
Fully branded sites
Monetization Sometimes

45. What’s the diff?
Some sample differences between the
two.
API Management Service
Management
Target audience External Internal
Authentication JWT, API key mTLS
Rate limits Business related Protection of
backends
Reporting needs Ops + Analytics Ops
Documentation
needs
Fully branded sites Often: none (gulp)
Monetization Sometimes Almost never

46. APIManagementPolicy
APIManagement
Telemetry
Before runtime API Management platforms have
tools for API producers (to make portals, create ‘API
products’, to combine services to APIs)
At runtime API management is a policy engine --
validate and authorize tokens, check against rate
limits.
Post runtime Downstream functionality (API analytics,
monetization) is driven from API-level telemetry
gathered by the proxy.
API Management as a Mixer Adapter
Mixer
Ingress Service B
proxy proxy
Policy checks,
telemetry

47. APIManagementPolicy
APIManagement
Telemetry
Before runtime: API Management platforms
have tools for API producers (to make portals,
create ‘API products’, to combine services to
APIs) and API consumers (read docs, use
interactive portals, generate credentials).
At runtime API management is a policy
engine -- validate and authorize tokens, check
against rate limits.
Post runtime Downstream functionality (API
analytics, monetization) is driven from API-
level telemetry gathered by the proxy.
Dashboards & monetization driven from data
gathered at runtime
API Management as a Mixer Adapter
Mixer
Ingress Service B
proxy proxy
Policy checks,
telemetry

48. Policy
Telemetry
Before runtime: API Management platforms
have tools for API producers (to make portals,
create ‘API products’, to combine services to
APIs) and API consumers (read docs, use
interactive portals, generate credentials).
At runtime API management is a policy
engine -- validate and authorize tokens, check
against rate limits.
Post runtime Downstream functionality (API
analytics, monetization) is driven from API-
level telemetry gathered by the proxy.
Dashboards & monetization driven from data
gathered at runtime
Is anyone doing that?
Mixer
Ingress Service B
proxy proxy
Policy checks,
telemetry

49. Is that it? No!
More to come: transformation! Better
routing! Method-level policies!
Get involved:
istio.io/about/community/ to read about
our working groups

50. Thanks for listening!
Istio.io
github.com/istio