This document discusses the impact of microservices architecture on API management. It describes how microservices are structured as independently deployable services that communicate over a network. When microservices communicate across organizational boundaries, API management is advised to provide capabilities like a gateway, developer portal, and API management. The document also discusses how a service mesh can be used for internal microservice communication within an organization, making API management optional in that context. It provides examples of how Istio implements a service mesh and its features for dynamic routing and traffic control between microservices without requiring code changes.
3. Infrastructure & Technology
People & Process
Architecture & design
Fine grained
deployment
Improve build independence
and production velocity
(deployment agility)
Decentralized
ownership
Accelerate agility and
innovation
(development agility)
Cloud native
infrastructure
Dynamic scalability and
inherent resilience
(operational agility)
4. Microservice
component
Microservices ApplicationMonolithic Application
What are microservices?
Microservices is a technique for
structuring an application as a
collection of services
• Self-contained with clear interfaces
and a distinct purpose
• Loosely coupled – communicate
over a network
• Independently deployable,
scalable, maintainable and testable
6. API management: More than just a gateway
Developer
Portal
API
Manager
API Gateway:
• Decoupling/routing
• Traffic management
• Security
• Translation
Developer portal:
• API discovery
• Self-service
• Onboarding
• API subscription
• Account usage analytics
API Manager:
• API/plan/product design
• Access management
• Policy administration
• API plan usage analytics
The API implementation should not be burdened with the
complexities of API exposure beyond the microservices
application boundary. Exposure should be delegated to a
separate capability providing as a minimum, a gateway, a
developer portal, and API management.
API Implementation
6
API gateway
7. Decentralized API ownership
Developer Portal
API Manager
API
Implementation
A
API
Implementation
B
API
Implementation
C
A B C
A B C
API gateway API gateway API gateway
on a centralized API management infrastructure
API gateway
7https://developer.ibm.com/apiconnect/2018/12/10/api-management-centralized-or-decentralized
8. Enterprise boundary
Federated API gateways, centralized management
Developer
Portal
Line of business A
API gateway
API gateway
API gateway
API gateway
API
Manager
Line of business B
Line of business C
Line of business D
9. On premises
Federated API gateways, centralized management
Developer
Portal
API
Manager
Public Cloud A
Private
Cloud
Public Cloud Y
Public
Cloud Z
API gateway
API gateway
API gateway
API gateway
API gateway
10. Microservice
component
Inter-microservice vs. inter-application communication
Microservices
application
Microservice
component
Microservice
component
Microservices
application
Exposure Gateway
Inter-application communication
• Crosses organizational boundaries
• Potentially on different platform
• API management advised
Inter-microservice communication
• Within an organizational boundary
• Microservices on shared platform
• Service mesh (e.g. Istio) for complex
routing
• API management optional
• Event-driven microservices with event
backbone
Note: the protocol used for the communication may be the
same in both cases, (e.g. JSON/HTTP). It is the way that
the interfaces are exposed and managed that is different.
JSON/HTTP
JSON/HTTP
10https://developer.ibm.com/apiconnect/2018/11/13/service-mesh-vs-api-management
11. What Is Istio?
An open services
platform to manage
service interactions
across container- and
VM-based workloads
12. IBM is fully
committed to Istio
IBM is one of the
founding members of
Istio (along with
Google and Lyft)
13. What ISN’T Istio
It is NOT an API
Management solution
It does not replace
integration needs
14. Istio has a lot of features!
Provides a network for services:
● Security
● Policy Enforcement
● Resiliency
● Traffic Control
● Observability
Key Features:
● Service auth and identity
● Authorization
● Rate limiting
● Load balancing / shedding
● Retries and circuit breaking
● Fine-grained routing
● Metrics and logs generation
● Request tracing
● Fault injection
16. 16
Example: Dynamic Routing between Microservices
Microservice Microservice
(Micro)service
Microservice
Micro-service
(V1)
Envoy
Envoy
Envoy
Envoy
Envoy
Envoy
Ingress
Envoy
Envoy
Dynamic A/B Routing
No code in the microservices for
routing (they are “blind” to each
other
Ops team has complete control
over new microservice roll outs
Saves time, reduces errors/rework
19. Bringing API Management and Istio worlds together
bookInfo
(beta)
DataPower
API
Gateway
bookInfo
(stable)
Istio
Mesh
Edge
Gateway
Security policies (JWT, SSL, ...)
Map policy
XML <-> JSON
Parse policy
Custom policies
Complex
Routing
policies
Bookinfo
Virtual
service
EnvoyEnvoy
20. Context Augmentation using DataPower Gateway
bookInfo
(beta)
bookInfo
(stable)
Istio Mesh
Istio
sidecar
proxy
DataPower
API
Gateway
Augment request context
by setting the plan name
in a header based on
client subscriptions
"plan": "premiumplan”
OR
"plan": "betaplan",
Digitalization drives IT modernization
Modern styles of IT architecture impacts thee aspects of application development
Infra -> architecture -> people
Fine grained deployment is all about splitting things into smaller pieces for more agility
Loosely coupled Dependencies
Shorter Deplyment cycles
Independent management of components
Allows Ownership to be decentralized
Application teams can be constucted in more agile ways
teams, tribes, chapters, guild and so on…
Avoid priorities conflict
Sits on top of infrastructure that is cloud native through containerization
Portability
12 factor app
self contained with:
isolate dependencies
Store config in the environment
Treat backing services as attached resources
Strictly separate build and run stages
Define boundaries
Groups of microservices makes application
Reuse through copy
Kubernetes namespaces keep microservices contained
How to expose services outside the application?
Hide implementation complexity
Publishing API is more than just gateway
More customer centric
self sufficient
API Procut manager
Productized API
Are we saying that you should have gateway per micro service?
No, the infrastructure performing API management can still be centralized.
Can be managed in a multitenant way in completely isolated way
There are reasons why we might end up braking this into multiple developer portals
Or even gateways
Gateways over different organizational boundaries
Or as typical, over different clouds and environments. Gateways close to services, but you still want centralized management.
It’s possible to manage multiple gateways in multiple locations
Deployment and architectural flexibility
API’s in inter-application communications
Event driven architecture, using events, Kafka, multiple patterns
Service Mesh
Istio is service mesh to manage microservices
Having side car proxy micro gateway is not API management solution
No producer or consumer organization management capabilities
No tools for API Product management
Mostly operations tools
Quite a lot of simalar capabilities than API Management
But still different use case
Network for micro services
Service mesh intercepts invocations
Side car proxy
Control plane (Pilot, Citadel, Mixer), telemetry
Policy based routing
Patterns
visibility
Sidecar, Control plane, network of microservices, services are blind to each other
Inside microservice application, but how this relates to API Management?