Agile integration architecture in relation to APIs and messaging

IBM Cloud / DOC ID / Month XX, 2018 / © 2018 IBM Corporation
Agile Integration Architecture
in relation to APIs and messaging
Recording: http://ibm.biz/AgileIntegArchApiMessagingWebinar
Kim Clark
Integration Architect
Integration Portfolio

Integration modernization through
1
A. Fine grained deployment
B. Decentralized ownership
C. Cloud native infrastructure
API API API
API
API
API
API APIAPI
Traditional application integration
(centrally provisioned and administered silo)

Perspectives on
Application
Integration
perspective
API
perspective
M
essaging
perspective

Perspectives
Application
Integration
perspective
API
perspective
M
essaging
perspective

Integration modernization
Application Integration perspective
4
Traditional application integration
(centrally provisioned and administered silo)
Isolated integration deployment,
application ownership,
cloud-ready implementation

The fate of the ESB Pattern: Moving to agile integration architecture
http://ibm.biz/AgileIntegArchPaper
Containerization
Centralized
ESB
Fine-grained
integration
deployment
Application autonomy Polyglot runtimes
Decentralized
integration
ownership
Integration as a
microservice runtime
http://ibm.biz/AgileIntegArchWebinar

API Management perspective
7Accelerate digital transformation with Cloud & AI / July 2018 / © 2018 IBM Corporation
Traditional SOA exposure
API exposure
Consumer-centric, channel optimized
Distributed gateways
Self-service discovery, developer portals
Subscription and version management
Self-provisioned and administered
Internal and external
API
Service exposure
System centric
Single gateway
Waterfall delivery
Re-use focused
Mostly internal
API API
API
API
API
API
API API
API

Agile integration architecture and API management
Containerization
Centralized
ESB
Fine-grained
integration
deployment
Application autonomy Polyglot runtimes
Decentralized
integration
ownership
Integration as a
microservice runtime

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
API gateway

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

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

µService
µService
µService µService
µService
API gateway
API
Application
boundary
µService
Microservice
component
µService
µService
µService
API gateway
API gateway
µService
API gateway
Silo
application
API gateway
Silo
application
Managed API gateways define and enforce application boundaries
Boundaries make complex environments manageable
µService
µService
µService
API gateway
µService
µService
µService
API gateway
µService
µService
µService
API gateway

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
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

Messaging perspective
15Accelerate digital transformation with Cloud & AI / July 2018 / © 2018 IBM Corporation
Traditional application pervasive, self-
managed messaging topologies Self-provisioned, platform-managed, secure, reliably
and transparent communication in a multi-cloud
environments. Delivering an event driven enterprise.

Local vs Remote messaging
16
Local message store/forward,
ensures “put” is always possible
Additional process alongside application to enable inter-process
communication – against best practice for containers.
Local persistence required, which
complicates HA/DR scenarios
Messaging is a local component
Network connectivity assumed/required for “put”, moving
burden of local store/forward on client if network fails
Application is standalone single process,
so well suited to containers
No local persistence requirement, enabling
simplistic stateless HA/DR for application
Messaging can be consumed as-a-service

asynchronous(messaging,events,…)
trad. on premisescloud platform
cloud platformcloud platform
private cloudSaaS platform
iPaaS/iSaaS
SaaS platform
cloud platform cloud platform
The asynchronous backplane (messaging, events)
The asynchronous backplane provides reliable message/event storage and a
distribution network that can traverse application and cloud boundaries robustly.

Microservice Application
Creating truly independent digital applications requires
asynchronous communications as well as APIs
SoR SoR SoRSoR
APIs
invocations
EventStreams
Truly independent, decoupled microservice components enable
• Agility: Innovate rapidly without affecting other components
• Scalability: Scale only what you need, and only when you need to
• Resilience: Fail fast, return fast, without affecting other components
To provide those benefits they need to be independent of the systems of record
• APIs: Are simplest to use, but create a real-time dependency
• Event streams: Enable microservices to build decoupled views of the data
µService
µServiceµService
µService µService
µService µServiceµService
µService
API gateway
Enterprise integration

Source / Target
Request / Reply
Stream History
Transient Data
Persistence
Immutable Data
Scalable
Consumption
Targeted
Reliable Delivery
Events
(notifications)
Messaging
(commands)
ü
19

Agile integration architecture eBooklet
https://www.ibm.com/cloud/agile-integration-architecture
summarises the following source material
Public material
on integration
modernization
The evolving hybrid integration reference architecture
https://ibm.biz/HybridIntRefArch
http://ibm.biz/HybridIntRefArchYouTube
“Microservices, SOA, and APIs: Friends or enemies?”
https://ibm.biz/MicroservicesVsSoa
http://ibm.biz/MicroservicesVsSoaWebinar
http://ibm.biz/AgileIntegArchPaper
http://ibm.biz/AgileIntegArchWebinar
The fate of the ESB
http://ibm.biz/FateOfTheESBPaper
Useful links on agile integration architecture
http://ibm.biz/AgileIntegArchLinks
https://developer.ibm.com/apiconnect/blog
https://developer.ibm.com/integration/blog
https://developer.ibm.com/messaging/blogs
Staying up to date:

Agile integration architecture in relation to APIs and messaging

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agile integration architecture in relation to APIs and messaging

Similar to Agile integration architecture in relation to APIs and messaging (20)

More from Kim Clark

More from Kim Clark (16)

Recently uploaded

Recently uploaded (20)

Agile integration architecture in relation to APIs and messaging