APIs are fast becoming central to the way that an enterprise presents itself to partners and customers, enabling innovation and automation. A well crafted API is today's front page advertisement for your enterprise's capabilities, but there must be substance beneath the API, for it to fulfil its promise. Success beyond initial launch of the API rides upon many factors. In this talk we'll focus on the architectural elements that need to be considered in order to ensure the API will be secure, scalable, agile to change, manageable and maintainable. Along the way we will discuss how to leverage the sweet spots of IBM's hybrid integration portfolio to make your API initiative more productive, and maintainable into the future.

1. Building enterprise
depth APIs with IBM's
Hybrid Integration
portfolio
Kim Clark
Integration Architect
Offering Management
Hybrid Integration
0 5/28/17
This deck is available as a webinar at
http://ibm.biz/EnterpriseDepthAPIs

2. Abstract
APIs are fast becoming central to the way that an enterprise presents itself
to partners and customers, enabling innovation and automation. A well
crafted API is today's front page advertisement for your enterprise's
capabilities, but there must be substance beneath the API, for it to fulfil its
promise. Success beyond initial launch of the API rides upon many factors.
In this talk we'll focus on the architectural elements that need to be
considered in order to ensure the API will be secure, scalable, agile to
change, manageable and maintainable. Along the way we will discuss how
to leverage the sweet spots of IBM's hybrid integration portfolio to make
your API initiative more productive, and maintainable into the future.
1

3. Topics
• The anatomy of an API implementation
• API implementation options
• Enterprise depth API considerations
• Implications of microservices architecture

4. Hybrid Integration Reference Architecture
3
{ }
{ }
NoSQL
{ }
{ }
NoSQL
API Composition
SoR
Core
Business
Operations
Empowering
Digital teams
Systems of
Engagement
Business logic
Mobile Partners
SaaS
Offerings
API
Economy IoT XaaS
On-Premise
Cloudaffinity
SoR
“Low level” connectivity
Events Data Synchronisation
HybridIntegration
SoR
API & Event Gateway
API & Event Gateway
SoR SoR
API
Composition
Events
Data
Sync.
“Digital” connectivity
Article: https://ibm.biz/HybridIntRefArch Video: http://ibm.biz/HybridIntRefArchYouTube

5. Request/response real-time integration
ExposureConsumer(s) Provider(s)
request
response
Composition
Adaptation
(downstream)
Exposure
Provides a standardised,
easily administrable way to
control the exposure of real
time interactions.
Adaptation (downstream)
Understands the connectivity
protocols and data formats,
required to manage
communication with specific
provider systems.
Composition
Implements the custom
“integration logic”,
including aggregation from
multiple sources, and
merging of data.

6. What is the scope of an “API”?
ExposureConsumer(s) Provider(s)
request
response
Composition
Adaptation
(downstream)
API from the
consumers
perspective
API from the
implementers
perspective

7. Separation of the gateway from implementation
Gateway
Often placed in an DMZ
Focused on decoupling, security, traffic management
Consumer driven lifecycle
Gateway routes to multiple possible implementations
Implementation
Should not be placed in DMZ
Focused on composition, data manipulation, connectivity
Provider driven lifecycle
Many possible implementation patterns and technologies
Consumer(s) Provider(s)
request
response
Gateway
component
Integration
component

8. What does a large scale integration landscape look like
Systems of engagement
– Modern languages/runtimes
– Agile
– Simple modern connectivity
Systems of record
– Older technology
– Harder to change
– Harder to integrate with
Integration Hub
Adapter Adapter
“Systems of
Engagement”
Applications
Exposure Gateway (internal)
“Systems of
Record”
Applications
Mature large enterprise
(simplified)
“Enterprise
Service Bus?”
“Web API
Gateway”
Exposure Gateway (external)

9. More than just a gateway
API Gateway
Developer
Portal
API
Manager
API Gateway:
• Decoupling/routing
• Traffic management
• Security
• Translation
Developer portal:
• API discovery
• Self subscription/administration
• Account usage analytics
API Manager:
• Plan/product design
• Access management
• Policy administration
• API plan usage analytics
The API implementation should not be burdened with the
complexities of API exposure. Exposure should be delegated
to a separate API management capability offering no just a
gateway and management, but also a developer portal.
API Implementation

10. Create Run
ManageSecure
API Creation
• API Creation from Swagger doc or
Loopback models, in minutes
• API Discovery from SoRs
• Cloud & on-premises staging
of APIs, Plans & Products
Microservice Runtimes
• Node.js & Java Microservice runtime
• Built-in CLI for DevOps
• On-cloud & on-premises staging of
Microservice applications
Management, Socialization & Analytics
• API, Plan & Product policy creation
• Lifecycle governance & management
• Self-service, customizable, developer
portal with subscription & community
management
• Advanced Provider & Consumer
Analytics
Field Proven Security
• Policy enforcement, quota
management & rate limiting
• Response caching, load-balancing
and offload processing
• Message format & transport
protocol mediation
IBM API Connect – as an API management gateway

11. Primary API implementation options
{code}
SoR SoRSoR
API
Composition
Events
Data
Sync.
Digital connectivity
SoR SoRSoR
Integration hub
API GatewayAPI Gateway API Gateway
Custom code
(e.g. microservices)
iPaaS
(integration platform as a service)
Deep connectivity
SoR SoR SoR
{code}
{code}
{code}
{code}
Where complex highly customised
compositoin is require, a full code based
application tier is introduced.
The environment is built and managed, and
common integration requirements such as
mapping and connectivity may also end up in
code that has to be maintained. .
Where the system of record makes
reasonable interfaces available and simple
composition is all that is required.
An iPaaS provides a tooling and
configuration based approach to API
composition. It provides easily configurable
connectivity, caching, implicit elastic
scalability, and resilience, in a fully
managed typically cloud based
environment.
An iPaaS usually includes the gateway
capabilities for API exposure.
Where the system of record only provides
a complex or low level interface. An
integration hub providing deep connectivity
is used to convert into a more modern
interface.
The integration hub is traditionally owned
and run by the enterprise.
Typically a separate gateway exposes the
APIs to consumer.

12. SOA architecture using the traditional ESB pattern
Systems
ofRecord
Integration
Hub
Engagement
Applications
Externally Exposed Services/APIs
Lightweightintegration runtime
Lightweightlanguage runtime
Public API
Enterprise API
API Gateway
Integration Hub
Exposure Gateway
Microservice
application
Exposure Gateway (external)
Traditional and common implementation
of the enterprise service bus (ESB)
pattern is a centralized facility from
which all synchronous requests to back
end systems are exposed in a
standardized way.
ESB is an architectural pattern, but
unfortunately the term is often
confusingly attributed to specific
components.
The centralized nature of the
typical implementation was due
to technical limitations of the
time. Bare metal servers, CPU
based static licensing, slow
procurement of infrastructure.
Asynchronous integration
Request/response integration

13. Lightweight integration
Componentization/containerization of the integration hub
Systems
ofRecord
Engagement
Application
Externally Exposed Services/APIs
Exposure Gateway (external)
Lightweightintegration runtime
Lightweightlanguage runtime
Public API
Enterprise API
API Gateway
Microservice
application
Modern integration runtimes have
become more lightweight, and there is a
range of more flexible infrastructure
including virtual machines, containers
and container orchestration.
There is no reason why the centralised
ESB can not be broken up into smaller
more easily managed and scaled
independent pieces.
This could certainly be seen to be
borrowing from microservices
principles, even if it is not necessarily
full microservices architecture.
Note that pre-ESB asynchronous hub
and spoke integration can also be
broken up in this way.
Would this still be classed as
the ESB pattern? Does
anybody care…
Asynchronous integration
Request/response integration

14. 13
REST {JSON} APIS
IBM Integration Bus
a lightweight integration runtime for deep connectivity
FAST LIGHT DEPLOYMENT
Lightweight runtime stops/starts in seconds. Rich functionality retained. Encourages multiple runtimes each with minimal
flows. “Cattle not pets” approach. https://youtu.be/qQvT4kJoPTM
VIRTUALIZATION
VM and Docker fully supported. Images provided. Layered filesystem install. Dependency free, e.g. no MQ. Configuration
as files - “infrastructure as code”. https://youtu.be/ybGOiPZO3sY
STATELESS
Stateless runtime. Instances are independent of one another. Suited to blue/green deployment updates, A/B testing
etc. https://ibm.biz/IIBoncloud
DISTRIBUTED DEPLOY READY
Standardized logs for cross correlation. Out of the box ingestion into Bluemix monitoring. Distributed business
transaction monitoring. Deep global cache support. https://youtu.be/sCPrT2dHKSs
DEVOPS TOOLING SUPPORT
Continuous integration and deployment ready. Script based install, build, deploy, configuration. Automation via common
tools, e.g. Chef, Puppet, IBM UrbanCode Deploy. Test automation https://tinyurl.com/gsg5qpr
CLOUD FIRST
Available elastically scalable as as a service (IIB on Cloud), on IBM Bluemix and other leading PaaS vendors.
JSON/REST SUPPORT
Swagger support. REST based exposure. Downstream REST invocation. Graphical mapping of JSON data with or
without schema. https://youtu.be/C_6gPlrCHZQ
CURRENT CONNECTIVITY
Native connectivity to NoSQL databases such as MongoDb, Kafka messaging and SaaS (e.g.SalesForce)
https://youtu.be/7mCQ_cfGGtU https://youtu.be/Is1pphngUlM
http://ibm.biz/LightweightIntegrationIIB

15. 14 5/28/17
App Connect – the iPaaS option
What is App Connect?
Business friendly integration that connects cloud &
enterprise apps as flows and APIs
A next generation, cloud native iPaaS.
What does App Connect provide today?
• App-aware smart connectors
• Automation of manual tasks: event driven flows
• Integration flow powered APIs
• Simple but powerful data mapping
• Secure on-prem and cloud connectivity.
• Easy to understand dashboard and error
reporting.
https://appconnect.ibmcloud.com

16. App Connect – API creation demo
15https://youtu.be/VQKbKe1kmH0

17. Create Run
ManageSecure
API Creation
• API Creation from Swagger doc or
Loopback models, in minutes
• API Discovery from SoRs
• Cloud & on-premises staging
of APIs, Plans & Products
Microservice Runtimes
• Node.js & Java Microservice runtime
• Built-in CLI for DevOps
• On-cloud & on-premises staging of
Microservice applications
Management, Socialization & Analytics
• API, Plan & Product policy creation
• Lifecycle governance & management
• Self-service, customizable, developer
portal with subscription & community
management
• Advanced Provider & Consumer
Analytics
Field Proven Security
• Policy enforcement, quota
management & rate limiting
• Response caching, load-balancing
and offload processing
• Message format & transport
protocol mediation
IBM API Connect – providing an API implementation too

18. A selection of enterprise-depth API considerations
• Caching
• Traffic management
• Granularity
17

19. API Gateway
In which layer should you cache?
Application
Data store
Device/
browser
CDN Server
Integration
Read cache only.
Should you terminate HTTPS at the CDN?
Is asynchronous cache purge sufficient?
What cache visibility do you have?
Will you get re-use across regions?
How will you test its effectiveness?
Must terminate HTTPS for full benefit.
Read cache primarily
How is cache invalidation performed?
Reduces load on API Gateway and all layers below.
Closest geographical point-of-presence
Uses existing internet capability (via HTTP headers)
Can’t share cache across users
Cache invalidation can be very challenging
Do you own the device app or have any controller over its design?
Reduces load on all other layers.
App can potentially work offline
Makes app extremely responsive
Reduces load on layers within enterprise.
API specific caching independent of application.
Cache consistent with API granularity
Reduces load on layers from application down.
Enables state free scalability for reference data
Writable cache options (with caution)
Compositions can benefit from fine grained caching.
Reduces load on database
Writable cache options with deep locking possibilities
Cache with understanding of the application
Application native data model can be used
Data relationships within cache are acceptable
Easiest point for accurate cache invalidation.
Further scale with grid compute
Preload closer to data store data model
No amount of caching at other levels is a substitute for a
well designed, organised and tuned database. Modern
databases (e.g. NoSQL) need attention too.
No reduction in load on application or layers above.
Database is the furthest distance from the client.
Do you have access to adjust the database?
Can you be sure you won’t destabilise the application?
Adds complexity to application build
Data model often different to API, so translation at other layers.
Change the application anyway or is it fixed?
What’s the application code change cycle?
Writable cache patterns can interfere with application design
Cache invalidation may require application knowledge.
Mobile App
Server
ConsPros

20. Consumer A
(requirement
100 msg/sec)
Consumer B
(requirement
300 msg/sec) Provider
throttle
Consumer
throttles
Back end system Z
(capacity 500
msg/sec)
500
100300
1. No throttling – back end system easily overloaded.
2. Provider only throttling – Back end system protected, but consumers can still take more than they are contracted for.
3. Consumer only throttling – Enables prioritisation of consumers. Aggregate of consumers must be limited to back end
capacity or risk overloading.
4. Consumer and provider throttling – Consumers forced to behave to SLA, and back end system protected.
Managing throughput effectively requires multiple throttling points
Consumer C
(requirement
300 msg/sec)
300

21. Granularity: Where to do composition across multiple datastores
20
Device or
browser app
API Gateway
App
Ser
v.
Composition
Point
Consumer app Gateway Integration Hub Integration Hub
Strengths UI responsiveness
Rapid innovation
API simplification
Reusable at API
API Simplication
Re-usable at all levels
API Simplification
Swifter response
Weaknesses Sequential latency
Authentication
Distributes application logic. Distributes application logic. Delayed synchronisation
Offline error handling
Acceptable for Reads
Isolated writes (e.g. read, read, write)
Reads
Isolated writes (e.g. read, read, write)
Reads
Isolated writes (e.g. read, read, write)
Combined writes, (but holding
intermediate state is controversial)
Asynchronous chained
writes
Data
App
Ser
v.
Data
Device or
browser app
API Gateway
App
Ser
v.
Data
App
Ser
v.
Data
Device or
browser app
App
Ser
v.
Integration
Hub (sync)
Data
App
Ser
v.
Data
Device or
browser app
App
Ser
v.
Data
App
Ser
v.
Data
API Gateway API Gateway
Integration
Hub (async)
Integration
Hub
Integration
Hub
http://www.slideshare.net/kimjclark/presentations “What’s behind a high quality API”

22. What effect does microservices architecture have?
• Definition
• Comparison with APIs/SOA
• Where does API management fit with microservices?
• Where does messaging fit with microservices?
21

23. Encapsulation is the key!
Microservice comp
Silo logic
Silo
data
Microservice comp
Microservice
component
Microservices ApplicationMonolithic Application

24. Why Microservices?
Small scoped, independent, scalable components
Agility
Faster iteration cycles
Bounded context (code and data)
Scalability
Elastic scalability
Workload orchestration
Resilience
Reduced dependencies
Fail fast
23

25. Microservice
component
Common misconception resulting from the term “microservice”
Monolithic application Microservices application
Exposed services/APIs
Microservice
component
Microservice
component
Exposed services/APIs
Silo
component
Microservices are just more fine grained web services
APIs are microservices
“micro” refers to the granularity of the components,
not the granularity of the exposed interfaces
x 1 x 3
x 4x 4
Is “microservices architecture” is really
“micro-component architecture”?
Clarification on Microservices vsAPIs - short video (4 mins)
http://ibm.biz/MicroservicesVsAPIVideo

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

27. Microservice
component
Inter-microservice vs. inter-application communication
Microservices
application
Microservice
component
Microservice
component
Inter-microservice communication
• Lightweight protocols: HTTP,
application messaging
• Runtime component registry
• Client-side load balancing and circuit
breaker patterns
Microservices
application
Exposure Gateway
Inter-application communication
• Enterprise protocols: Managed API
gateways, enterprise messaging
• Design time developer portals
• Gateway load balancing and throttling
JSON/HTTP RESTful communication styles may
be present in both types of communication, but
their implementation may be radically different.
JSON/HTTP

28. Microservice
Microservice
Microservice
Microservice
Micro services Inter-communication
Microservice
Message
Hub
Publish
Service
DiscoveryMicroservice
Microservice
Microservice
Subscribe
Subscribe
API
API
Publish
JSON /
HTTP
JSON /
HTTP
Microservices
application
Aim is decoupling for robustness
Messaging where possible
• Lightweight messaging
(e.g. AMQP, Kafka)
• Publish/subscribe
• Eventual consistency
Direct calls where necessary
Lightweight protocols
(e.g. JSON/HTTP)
• Load balancing/scaling via
service discovery
• Circuit breaker
• Caching

29. Creating truly independent microservices applications
28
Microservices application
API Gateway
SoR SoR
Enterprise integration
Gateway
SoRSoR
APIs
Event
Streams
Data
Synch
To provide agility, scalability and resilience benefits
microservices need to be as independent of the systems
of record as possible
• APIs: Are simplest to use, but create a runtime
dependency, reducing isolation. Patterns such as
circuit breaker required to retain resilience
• Event streams: Enable microservices to build
specialized views on the data (event sourcing), but
needs a separate path for updates, so may still need
some synchronous APIs unless using eventual
consistency patterns.
• Data sync: Provides a replica of back end system
data local to the microservice and potentially allows
changes in either back end or replica. Data sync
patterns are non-trivial however.
Messaging in microservices (20 mins):
http://ibm.biz/MicroservicesAndMessagingWebinar

30. Digital IT Enterprise IT
Message Hub
(Based on Apache Kakfa)
MQ Light API
29
Enterprise Messaging & Integration
Hybrid Messaging
MQ ExplorerMQ ClientMQ Light API
Kafka API REST API IBM MQ Appliance
Bluemix Public
Bluemix Dedicated
(Announced, GA March)
Bluemix Local
(Coming soon)
IBM MQ
Cloud
On-Prem
Cloud
On-Prem

31. IBM
Application
Integration
Suite
a composable
architecture for
hybrid integration
Cloud Connectivity
ü Broad native cloud connectors
ü Non-specialist composition
ü Pre-defined templates
Enterprise Integration
ü Deep mature connectivity
ü Rich flow language support
ü Advanced mediation capabilities
API Management
ü Policy based traffic management
ü Integrated developer portal
ü Lifecycle management

32. IBM Redbook: An architectural and practical guide
to IBM Hybrid Integration Platform
Contents
• Reference architecture
• Core use cases
• Portfolio overview
• Practical scenarios
http://ibm.biz/HybridIntegrationRedbook2016
31

33. API Innovation Workshop
One-day collaborative workshop between IBM solution
architects and your business and technology representatives to:
• prioritize top use cases for API adoption on the basis of
business value
• access the technical feasibility
• determine the recommended adoption approach
Contacts: cmarcoli@uk.ibm.com, zdenek_boruvka@cz.ibm.com
Free client workshop to qualify an API economy opportunity
32
Step Outcome
Preparation:
• Discuss business and technical context during preparatory calls
• Identify stakeholders, verify availability and commitment.
• Agenda tailored to your organization
• Pre-requisites verified, workshop scheduled
Workshop
• Discuss adoption use cases driven by opportunities related to customers, developers
and third parties. Define priority based on business value.
• Assess Impact on processes, analyze data and security requirements.
• Discuss end to end solution and impact on the current technology landscape
• Clarify use of IBM technology components.
• Assess value vs cost, define adoption roadmap
• Understand the high level solution
• Reach confidence on feasibility
• Produce an actionable API adoption roadmap

34. More on
this topic?
Look out for related posts and videos on:
“Integration Design and Architecture”
blog posts on IBM Integration blog:
https://developer.ibm.com/integration/blog/tag/integration-design-and-architecture
and related videos in:
http://ibm.biz/IntegrationDesignAndArchitectureVideos

35. 34 5/28/17