In this deck, we discuss how to augment service mesh functionality with API management capabilities, so you can create an end-to-end solution for your entire business functionality — from microservices to APIs, to end-user applications.

1. Extending Service Mesh with API
Management
Laslo Pastor
Associate Director/Solutions Architect

2. Agenda:
● Evolution of Applications
● Why microservice architecture?
● Challenges with microservices?
● Why Service Mesh?
● Why API Management?
● WSO2 API Manager with Istio / Demo

3. Evolution of Applications
Disaggregated architectures drive 50 billion endpoints to grow >1 trillion
CONSUMER DEMAND
SUPPLIERS DISAGGREGATE ARCHITECTURE TO MEET DEMAND
1
10
102
103
105
109
MONOLITHIC
BUSINESS APP
ENTERPRISE
APPS
DEPARTME
NTAL APPS
SAAS APPS
PUBLIC /
PRIVATE APIS
1970s
|
MAINFRAME
1980s
|
IT
AWAKENING
1990s
|
INTERNET
2000s
|
MOBILE
2010s
|
IoT/AI
2020+
|
DIGITAL NATIVE
SERVERLESS &
MICROSERVICES

4. What is Microservices Architecture?
● Microservice architectural style is an approach to developing a
single application as a suite of small services.
● Each running in its own process and communicating with
lightweight mechanisms.
● These services are built around business capabilities.
● Independently deployable by fully automated deployment
machinery.

5. Why Microservices Architecture?
● Individual components. Running, testing, deploying individually.
● Agility, flexibility and speed to market.
● Adapt microservice development for fast innovation.
● Smaller teams, agile software development life cycles.
● Freedom to use heterogeneous technologies, early feedback
cycles.

6. Problem with “big application” (a.k.a. “monolithic”)
Let say you have bigger application and you need to scale
it.
Why Microservices

7. Split your “bigger application” into smaller granules that can be
deployed independently
Split into Microservices. So we can implement each smaller business
function most effective way(language, platform, expertise).
Why Microservices

8. Split your “bigger application” into smaller granules that
can be deployed independently
Split into Microservices. So we can implement each
smaller business function most effective way(language,
platform, expertise).
Why Microservices

9. Scale/ Replicate each component individually. Because
each smaller service is microservice now. And they can
be deploy independently.
Why Microservices

10. ● Breaking up monoliths into microservices adds more
components.
● Easy to manage at the beginning but becomes very
complex when things scale.
Microservices Challenges

11. Challenges with Microservices

12. ● Network resiliency (retry, failower, circuit breaker)
● Governance overhead in orchestration (multi language libs)
● Service discovery (no hard coded endpoints)
● Disaggregation of architecture increases number of endpoints
● Secure communication (zero tolerance)
● Analytics, tracing, monitoring (Observability)
● Risk of new releases (roll out new version - Canary deployment)
Challenges with Microservices

13. How Can this be Solved?

14. Service Mesh
A service mesh is a dedicated infrastructure layer that controls
service-to-service communication over a network. It provides a
method in which separate parts of an application can communicate
with each other.
source:techtarget.com

15. Istio is an open source service mesh implementation which provides
behavioral insights and operational control over the service mesh as
a whole, offering a complete solution to satisfy the diverse
requirements of microservice applications.
Istio

16. Istio Component Overview
● Mixer enforces access control and usage policies across the
service mesh, and collects telemetry data from the Envoy proxy
and other services.
● Pilot provides service discovery for the Envoy sidecars, traffic
management capabilities for intelligent routing, and resiliency.
● Citadel enables strong service-to-service and end-user
authentication with built-in identity and credential
management.

17. Istio Component Overview
Istio Architecture (source — https://istio.io/docs/concepts/what-is-istio/)

18. Demo

19. User Story

20. User Story

21. Type Service Mesh API Management
Routing L3/L4 HTTP, GRPC, GraphQL
Security Service identity and mTLS User/App Authentication and
Authorization(OAuth / JWT)
Analytics Service operational analytics Business and developer focus
analytics
Rate Limiting RPC level rate limiting Business related rate limiting
Personas and Portal DevOps portals Publisher, Developer, CXO portal

22. ● When users need to expose microservices services to outside in
a secured and a controlled manner.
● When fine grained security should be enforced on APIs
exposed.
● When stats need to be collected on API usage for monetization
and billing.
● When it is required to offer a marketplace for APIs for easy
discovery and adoption.
When is API Management required in a
Service Mesh

23. Istio + WSO2 API Manager
Istio Architecture (source — https://istio.io/docs/concepts/what-is-istio/)
WSO2 Mixer Adaptor
Separately Hosted WSO2 API
Manager

24. Servicemesh and API Management

25. Steps Involved

26. Artifacts to Istio

27. JWT Validation Process

28. JWT Token Validation Process

29. OAuth 2.0 Validation Process

30. Analytics Process

31. API Analytics

32. What’s Coming Up In The Future
● API usage analytics from API Manager.
● Automated binding creation and deployment to Istio.
● Monetization on usage.
● Throttling and rate limiting of APIs.

33. WSO2 - Istio adapter
https://github.com/wso2/istio-apim/tree/1.0
Demo code -
https://github.com/pubudu538/microservices-samples

34. THANK YOU
wso2.com