Microservices principles are revolutionizing the way applications are built, by enabling a more decoupled and decentralized approach to implementation, creating greater agility, scalability and resilience. These applications still need to be connected to one another, and to existing systems of record. Agile integration architecture brings the benefits of cloud-ready containerization to the integration space. It provides the opportunity to move from the heavily centralized ESB pattern to integration within more empowered and autonomous application teams. We look at the architectural differences in this approach compared to traditional integration, and also at how it enables more decentralized organizational structure better suited to digital transformation. You can read a more detailed paper on this approach at http://ibm.biz/AgileIntegArchPaper. This presentation was recorded for Integration Developer News (http://www.idevnews.com/) and is available here: http://ibm.biz/AgileIntegArchWebinar

1. Think 2018 / DOC ID / March 19, 2018 / © 2018 IBM Corporation
Lightweight, Agile Integration Architecture:
A Containerized and Decentralized Approach to
Cloud-Ready Connectivity
Kim Clark
Integration Architect
Nick Glowacki
Integration Specialist

2. 1
Architecture
& Design
Infrastructure
& Technology
People &
Process

3. 2
Architecture & Design
Hybrid integration architecture
Agile integration approach
Microservices vs SOA
Deployment granularity
Infrastructure
& Technology
People &
Process

4. What does a real integration architecture look like?
3
Systems
ofRecord
Integration Hub
Integration Hub
Adapter Adapter
Engagement
Applications
Microservice
applications
SaaSApplications
(external)
Adapter
Externally Exposed Services/APIs
Exposure Gateway (internal)
Exposure Gateway (external)
BusinessPartners

5. 4Think 2018 / March 2018 / © 2018 IBM Corporation
Centralized
Integration
(ESB pattern)
Fine-grained
Integration
Deployment
Decentralized
Integration
Consumers
Providers
Integrations
Re-use
Quality
Stability
Support
Monitoring
Governance
Performance
Fixed requirements
What’s its track record
Is the vendor trustworthy
Will it serve me long term
What do the analysts think of it
Could I get sacked for a risky choice
Agility
Velocity
Autonomy
Cloud native
Vendor agnostic
Developer is king
Rapid prototyping
Short learning curve
Can I start small
Can it help me today
What do my peers think of it
Does it have an active community
Application Integration – Where is it going?

6. Resilience
Minimized dependencies,
discrete failover, fail fast,
start fast
5
Maturity
§ Are you ready for a radical change in methods, skillsets,
infrastructure, operations.
§ Are you sufficiently automated (infrastructure, test, dev pipeline,
deployment etc.)
Maintenance
§ Will you be able to sustain the skillsets needed to maintain the
microservices architecture in the future?
Latency & Serialization
§ A request/response chained down a set of microservices must incur
extra latency from network hops and serialization
§ Serialization has advanced massively in recent years, but
inevitably has some contribution to CPU usage
Data sharing
§ Not all data can be split into neat independent functions. Some
things are shared, and this needs careful design
Real-time dependencies and their combined availability
§ Microservices calling other microservices synchronously need careful
consideration
§ Tends to creep, as one service builds on top of another
§ Need to move to more complex message based techniques and/or
introduce availability patterns such as circuit breaker
Manageability
§ How do you manage and monitor a vast network of microservices
§ How do you diagnose problems across a heavily distributed
landscape
How does persistence work?
§ Pessimistic versus Optimistic
§ How to handle shared objects
§ Relational / NoSQL
§ ACID / BASE / CQRS / Event Sourcing?
Considerations
Microservice
component
Microservices ApplicationMonolithic Application
Agility
Faster iteration cycles, bounded
contexts, dedicated teams…
Scalability
Elastic scalability,
workload orchestration,
cloud infrastructure

7. Application
SOA relates to enterprise service exposure *
Application ApplicationApplication
Service oriented architecture (SOA)
and microservices architecture relate to different scopes
Microservice
application
µService
µServiceµService
µService
Microservices relate to
application architecture
* this simple distinction can be contentious depending on your definition of SOA
Microservices vs SOA - short blog and video (10 mins)
http://ibm.biz/MicroservicesVsSoaBlog, http://ibm.biz/MicroservicesVsSoaVideoShort
Original PoV paper on microservices and in integration (~ 15 pages) http://ibm.biz/MicroservicesVsSoa
Webinar based on above paper (55 mins) http://ibm.biz/MicroservicesVsSoaFullWebinar

8. The fate of the ESB Pattern: Moving to agile integration
Part 2: Moving to lightweight, agile integration
http://ibm.biz/AgileIntegArchPaper
Containerization
Centralized
ESB
Fine-grained
integration
deployment
Application autonomy Polyglot runtimes
Decentralized
integration
ownership
Integration as a
microservice runtime
Part 1: The fate of the ESB
http://ibm.biz/FateOfTheESBPaper
more material
http://ibm.biz/AgileIntegArchLinks

9. Deployment Granularity
8
Within each domain, some grouping remains for
pragmatic reasons
• Agility
• Scalability
• Resiliency

10. Organizational Granularity
9
Slice along application domain/ LoB boundaries
Centralised integration architecture
Often done at dev time and at the artefact level
Occasionally some separation of runtime monitoring
e.g. accounting and chargeback
Rarely completely segregated
Only enforced by audit compliance
Agile integration architecture
Complete separation through Dev-Prod
Supports business agility
Minimises blast radius of radical change
Independent release cycles
Payroll
Supply
Chain
Warehouse
Inventory
Common utils
and formats
Version control
Payroll
Supply
Chain
Warehouse
Inventory
Payroll
Supply
Chain
Warehouse
Inventory
Common utils
and formats
Prod
Common utils
and formats
Splitting along organisational boundaries is a natural first step, initiating a more decentralised approach to
integration. Further splits along lower level application and functional boundaries can then be explored.

11. 10
Architecture
& Design
Infrastructure
& Technology
People & Process
Decentralization
Autonomy
Multi-skill teams
Full stack developers

12. The people aspect of decentralization
Systems
ofRecord
Engagement
Application
Externally Exposed Services/APIs
Microservice
Application(s)
Exposure Gateway (external)
Systems
ofRecord
Integration
Runtime
Engagement
Applications
Externally Exposed Services/APIs
Integration Runtime
Exposure Gateway
Microservice
application
Exposure Gateway (external)

13. Different audiences
12
Systems
ofRecord
Engagement
Applications
Microservice
applications
SaaS
Applications
Integration Hub
Agility
Velocity
Autonomy
Freemium
Cloud native
Vendor agnostic
Developer is king
Rapid prototyping
Short learning curve
Can I start small
Can it help me today
What do my peers think of it
Does it have an active community
Will it look good on my resume/cv
Re-use
Quality
Stability
Support
Monitoring
Governance
Performance
Fixed requirements
What’s its track record
Is the vendor trustworthy
Will it serve me long term
What do the analysts think of it
Could I get sacked for a risky choice
Traditional
Integration

14. microservice application
Governance in a decentralized organisation
Flattened organizational structure
Architects/leaders/pioneers still work in a team.
They influence via “guilds” on key focus areas
Not all microservice teams are equal, some are
pioneers, some are factories.
Multi skill teams (business user, developer,
tester, scrum leader, …)
Pioneer roles (tool specialist, tool builder,
framework specialist, infrastructure specialist,
method specialist)
Full stack developers - UX, API, integration,
data, etc.)
microservice
component
microservice
component
microservice
component
Guild(s)

15. How much do you uniquely need to know for each stack?
What if we could ensure that the only unique skill was artefact creation?
Operations Operations Operations Operations Operations
Deployment Deployment Deployment Deployment Deployment
Build Build Build Build Build
Artefact
Creation
Artefact
Creation
Artefact
Creation
Artefact
Creation
Artefact
Creation
Security Security Security Security Security
Installation Installation Installation Installation Installation
Resource
allocation
Resource
allocation
Resource
allocation
Resource
allocation
Resource
allocation

16. How much do you uniquely need to know for each stack?
What if we could ensure that the only unique skill was artefact creation?
Operations Operations Operations Operations Operations
Deployment Deployment Deployment Deployment Deployment
Build Build Build Build Build
Artefact
Creation
Artefact
Creation
Artefact
Creation
Artefact
Creation
Artefact
Creation
Security Security Security Security Security
Installation Installation Installation Installation Installation
Resource
allocation
Resource
allocation
Resource
allocation
Resource
allocation
Resource
allocation

17. 16
Architecture
& Design
Infrastructure &
Technology
Containers
Container orchestration
Routing frameworks
Delivery automation
Cloud platforms
Multi cloud
Private cloud
People &
Process

18. © 2017 IBM Corporation l Interconnect 2017
Costofentryoffirstfunction
Increasing abstraction from infrastructure
Bare Metal
Virtual machines
Functions
Containers
• Reducing infrastructure cost
• More fine grained cost models
• Less operations cost
• More “cattle” less “pets”

19. What skills and capabilities are required
to get something into production?
18
• Author artefacts
(design, implement, maintain)
• Arrange delivery
(source control, install, compile, build, verify,
test)
• Allocate resources
(cpu, memory, storage, connections)
• Configure routing
(load balancing, failover, traffic control, re-try,
timeout, load shedding/shaping, request tracing)
• Enforce security
(authentication, access control, certificates,
encryption, port provisioning)
• Perform deployment
(scaling, distributed deploy, rolling update, A/B
testing, blue/green deployment, canary
releases)
• Manage operations
(health checks, monitoring, tracing, log
aggregation, quotas)
Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery

20. Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery
19
Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery
Traditional infrastructure
(Pets)
Cloud native infrastructure
(Cattle)
Runtime specific
Provided by platform

21. What capabilities does the cloud platform provide to all runtimes
Runtime
Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery
Delivery
e.g. Docker build, Jenkins, Git
Resource allocation
e.g. Kubernetes, Mesos
Deployment
e.g. Kubernetes, Helm
Routing
e.g. Istio, Linkerd
Security
e.g. Kubernetes/Istio/SPIFFE
Operations
e.g. ELK stack
20
Runtime specific
Provided by platform

22. Pets Cattle
"Cattle not pets with IIB"
http://ibm.biz/CattlePetsIIB
Benefits of Cattle vs Pets

23. HA2HA1
Challenges of traditional deployment topologies
Load bal. Load bal.
P1
P1
P2
P2
Characteristics
HA pairs
Scaling manual and vertical
Defined nodes
Explicit install and configure
Explicit cold/warm HA & DR
Peak CPU licensing
Dedicated OS instances/HW
Deploy to running shared servers
Replication across DCs
Administer live shared servers
Code is only joined with the
servers at deployment.
DR1
D2
D1
DR2
D1
D2
Load bal. Load bal.
Deployment
Manager
HA
Manager
Compile/
Build
Process
Code
repository
Release
repository
HA
Manager
a b
c
System
Administration
replication
Authoring
a b
c
Monitoring
Product specific component
Product specific artefact

24. Cloud platform
Simplicity and scaling benefits of cloud native platforms
Load bal.
Elastically scaled containers
Pooled shared underlying resources,
but decoupled containers
Implicit HA/DR
Deploy by image combining artefacts
and infrastructure
Administer image then redeploy, not
hot fixing.
Orchestration
FrameworkImage
Build
Code
repository Release
Image repository
Authoring
Load bal. Load bal.
Monitoring
Log aggregator
Product specific component
Product specific artefact
Template Image
repository
a
a
a
a
a
a
a
b
b
c
c
c
a
a

25. 24
© 2018 IBM Corporation
FAST LIGHT
DEPLOYMENT
VIRTUAL-
IZATION
SUPPORT
STATELESS
ENGINE
DISTRIBUTED
DEPLOY
READY
DEVOPS
TOOLING
SUPPORT
CLOUD
FIRST
JSON /
REST
SUPPORT
CONNEC-
TIVITY
IBM App Connect Enterprise (formerly known as IBM Integration Bus)

26. Worker Node
Runtime
(Java/Node.js/IIB/.NET)
Runtime
Fixed
Configuration
What Moves Per Release
VM
Pet Cattle
Runtime
Fixed
Configuration
Container
Key
Created new for
each new code
version
Remains same for
each new code
version
Host – including
Kernel
Environment
Configuration
Environment
Configuration
Code
Code

27. Cattle
"Cattle not pets: Achieving lightweight integration with IIB” http://ibm.biz/CattlePetsIIB
Building up the layers in the Docker image
Ubuntu
IIBv10
Fixed config.
Ubuntu Ubuntu
ACEv11
Ubuntu
ACEv11 + MQ
Fixed config.
Ubuntu
ACEv11
Fixed config 1
Ubuntu
ACEv11
bar file A
Fixed config.
Ubuntu
ACEv11
bar file B
Fixed config.
Ubuntu
ACEv11
Fixed config 2
Deployable
units

28. IBM Cloud Private
Helm
charts
Worker Node
Release
Image repository
Worker Node Worker Node
Monitoring
Log
aggregator
Deployment
Pod
Service
Service
Service
ServiceServic
eIIB10
a Servic
e
Service
Service
java
b
Node
c
Servi
ceMQ
d
Node
fv2
Kafka
e
ACE
g
Node
fv1
Tangible example
Template Image repository
…
IIB v10 Node.js ACE v11
Java IIB&MQ DataPower
Kafka MQ
Image
Build
Code repositories
Authoring
Product specific component
Product specific artefact
a
a
b c d e f g h
ServiceNode
fv1
ServiceNode
fv1
ServiceNode
fv1
Service
Node
fv2
Servic
eIIB10
aServi
ceMQ
d
Servi
ceMQ
d
Service
Servi
ceMQ
d
Kafka
e
Servic
eACE
g

29. 28
Architecture
& Design
Infrastructure
& Technology
People &
Process

30. 29
Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery
Traditional infrastructure
(Pets)
Cloud native infrastructure
(Cattle)
Artefacts
Resources
Security
Operations
Routing
Deployment
Delivery
Fine grained
Breaking up into multiple fully
decoupled components
(Architecture & Design)
Cloud native
Standardized administration,
orchestration, monitoring.
(Infrastructure & Technology)
Decentralized
Removing centralized control,
and providing autonomy to teams
(People & Process)

31. Synergy
Architecture
& Design
People &
Process
Infrastructure &
Technology
Maturity
Business
Benefit
Architecture
& Design
People &
Process
Infrastructure &
Technology
Maturity
Business
Benefit
Architecture
& Design
People &
Process
Infrastructure &
Technology
Maturity
Business
Benefit
Architecture
& Design
People &
Process
Infrastructure &
Technology
Maturity
Business
Benefit

32. Common themes across the integration portfolio
enabling microservices principles
• Lightweight runtimes with a cloud native options
• Trivial, no/low cost repeatable developer install
• DevOps toolchain support, scriptable “infrastructure as code”
• Support for containers, orchestration frameworks
• Cloud ready, and cloud vendor agnostic
• Standardized logging to enable cross component correlation
• New licensing models including flex, hybrid and usage based
• “Digital connectivity” – e.g. support for REST, NoSQL, Kafka, SaaS etc.
31

33. Integration architecture – key references
32
List of useful links on agile integration architecture
http://ibm.biz/AgileIntegArchLinks
Original PoV paper on microservices and in integration
Article http://ibm.biz/MicroservicesVsSoa
Webinar http://ibm.biz/MicroservicesVsSoaFullWebinar
Hybrid Integration Reference Architecture
Article http://ibm.biz/HybridIntRefArch
Webinar http://ibm.biz/HybridIntRefArchYouTube
Part 2: Moving to lightweight, agile integration
http://ibm.biz/AgileIntegArchPaper
Part 1: The fate of the ESB
http://ibm.biz/FateOfTheESBPaper

34. 33Think 2018 / DOC ID / Month XX, 2018 / © 2018 IBM Corporation