Major banks around the world are well aware that their business is about to change forever. Fintechs, Open APIs, Blockchains and other innovations are forcing them to adapt at speeds they’ve never dreamed of before. APIs and Microservices promise to grant them that level of agility, but embracing them demands a fundamental shift in technology, process and culture, all at once. This is the story of one major Canadian bank’s journey.

1. Presented at the API Summit from Nordic APIs
June 12, 2018 @ Austin, Texas
Adopting APIs & Microservices at a
Major Canadian Bank – Part 2

2. APIs are a natural evolution of CIBC’s integration journey.
Modern APIs are a technology innovation that will make the bank more agile with faster time-to-market.
Enterprise Service Bus Enterprise Service Bus
Domain Domain Domain
The Evolution of Integration
Monolithic
• Direct integration
• Defined use case only
• Need to understand details
of producer AND consumer
systems for integration
?
Enterprise Service Bus
• Service-Oriented Architecture (SOA)
• Interface Agreements/Contracts
• Connect indirectly through ESB
(layer of abstraction)
Domain Service Buses
• Federating the ESB environment
• Giving more autonomy to CIOs
• Pick the technologies and stack
that suits their needs
APIs / Microservices
• Mobile & single-page apps arrive
• FinTechs and regulators add fuel
• They all want “RESTful” APIs
• Functionality in small, separate
independent, scalable containers
• Coordinated integration
• Easier to change/upgrade
• Reuse = Faster + Less Duplication
• Increasing Demand
• ESB became bloated, complex
• Difficult to change
• One change affects all
• Lots of testing required
• Promotes Domain independence
• Enables heterogeneous tech.
• Facilitates innovation
• Domain Service Buses got thick
• Proliferation of Technology
• No need to agree ahead of time
• Automated “self-service” model
• Independent enhancement
• Independent deployment
• Contained the “blast radius”
• Accelerates innovation
GaGateway
The move to APIs represents a big cultural and structural shift for
the bank, and this shift must be backed up by the right technology.

3. APIs are the future: So how do we build them?
Before we could take advantage of APIs at the bank, we needed to choose an API platform.
The decision to build the API Foundation in-house is a hedge
against a volatile landscape and develops critical internal skills.
We have taken a different approach
Instead of gambling on one of these external platforms, Enterprise Architecture
built the API Foundation on open-source technology we developed in-house.
We need to pick a technology, but we
can’t predict which––if any––of these will
eventually dominate the landscape.
Numerous vendors have all come out
with their own API platforms
The market is full of API frameworks & platform that are
clamoring to be the standard technology of the future.
We subjected our API platform to intense,
independent 3rd party evaluation. So far
the evaluations have been very positive.
“Great framework –
thoughtful, holistic
and quite advanced”
“Building custom as a hedge against a
volatile market makes sense right now”
“Security model is
built-in and highly
robust”
“Enables creation of
customer enhancements,
including FI-specific ones”
“Uses
OpenSource
intelligently”
Then we took
our framework
to Europe…

4. Following these principles positions us well for future-readiness and
ongoing evolvability in a unpredictable technology environment.
• Security enforcement
• Billing & Metering
• Centralize Monitoring & Alerting
• Caching (User/Data)
• Centralized portal for Marketplace, Dev/Ops and
Governance
• Developer Freedom
• Diverse Consumer Behaviour
• Holistic/Organic Re-Use
• Purpose-Built Interfaces
• Friendliness/Ease-of-Use
PROLIFERATION
• Architecture Governance
• Centralized Management
• Generalized/Broad Re-Use
• Standard Resource Models
• Full-Featured Functionality
STANDARDIZATION
TOO MUCH = ANALYSIS PARALYSISTOO MUCH = THE WILD WEST
YOU HAVE TO DO THESE NO MATTER WHAT!
CROSS-CUTTING CONCERNS
The following principles are designed to help guide integration decisions going forward:
Embrace Agility
By prescribing rapid releases and frequent iterations, an Agile approach supports
creating solutions that can evolve quickly and easily, enabling radical innovation. To
achieve this rapid release cycle, remove developer road blocks wherever possible.
Open-Source First
The intent is the bring the best of the open source community to CIBC and fill gaps
in functionality with vendor products. Given the rapid pace of change in the
integration space, open source solutions often lead the pack.
Democratized Development
Allow development teams to use the technology stack which makes the most sense
business domain (i.e. heterogeneity), while still leveraging common mechanisms and
solutions to address cross-cutting concerns and inter-domain communications.
Smart Apps & Dumb Pipes
Focus intelligence in the applications and build only speed into the pipes, so that
logic is moved out of hubs and towards the applications. This trend may imply the
end of the ESB as a future-ready integration solution.
Balance Proliferation & Standardization
Encouraging experimentation and proliferation is the only way to drive innovation;
however, this must be balanced against centralized, standardized governance,
security and support models. A federated approach strikes the right balance.
Support Two-Speed / Bi-Modal IT
Components close to the user experience must iterate and evolve at a much faster
rate than those close to the back-end core systems, which are more focused on
integrity and safety. Supporting both these delivery modes in concert is key.
Establish your guiding principles before you pick technology.

5. Beware the “Magical Black Box” approach to API Gateways.
Many leading solutions advocate a centralized gateway, but this will likely end up limiting your architecture.
The API Foundation embraces the distributed gateway approach,
spreading out cross-cutting concerns to each individual microservice.
Centralized Gateway
All cross-cutting concerns and isolation are in a single, “smart” layer.
Although this
is easier to
manage…
While easier to adopt and manage, this approach included a lot of
baggage from the SOA days, emphasizing a “magical black box”
approach to integration, where the gateway acts as a central hub.
Distributing
gateways
means…
…you ensure the load and logic is spread
out, enabling scale and logical isolation.
Distributed Gateway
Cross-cutting concerns are distributed to where they make sense.
We are seeing the industry moving in this direction in lockstep
with microservice adoption. CA, IBM, Red Hat and others already
offer solution packaged this way to support true distribution.
…it can have trouble scaling and will
likely create a single point-of-failure.
NETWORK & SECURITY SERVICES
PERIMETER API GATEWAY (INNER/OUTER)
Branch Telephone ATM On-Line Mobile Developers Devices
GATEWAY
SERVICE
GATEWAY
SERVICE
GATEWAY
SERVICE
GATEWAY
SERVICE
GATEWAY
SERVICE
Branch Telephone ATM On-Line Mobile Developers Devices
CENTRALIZED API GATEWAY
(“MAGICAL BLACK BOX”)
DOMAIN SERVICE BUS
Service-Oriented Platforms
PROPRIETARY INTERFACE
Legacy & Custom Platforms
MOM
MICROSERVICES

6. The new players
are built as pure
service mesh…
The distributed approach is maturing into the service mesh.
The last few years have seen a radical move from centralized solutions to fully distributed equivalents.
With the rise of the service mesh, the volatility in the market will
increase, and building in-house skills will become even more critical.
The Rise of the Service Mesh
As the world of APIs experimented with different implementations, it became
increasingly clear that the “secret sauce” to achieving speed and agility was
not good API Management but a robust, distributed microservices architecture.
The industry stopped talking about API Gateways and started talking about MSA.
One vendor after another re-invented
their solutions to be more distributed.
“A centralized traffic
cop manages all your
API activity & rules”
“Build aggregate
APIs & convert to
legacy formats in
the gateway.”
“API Gateways expose
your shared services as
managed APIs”
“API Gateways act as the single
point-of-entry for all API
traffic in the system.”
“A sidecar is conceptually
‘attached’ to the main
application provides
“platform features.”
“Dedicated infrastructure
layer for making service-to-
service communication
safe, fast and reliable.”
Articles from
2013 to 2015
Articles from
2016 to 2018
Strongloop microgateway & API Connect
CA API Mgt & Layer 7 as microgateway
Latest version boasts NGINX service mesh
Moving from Apigee to Endpoints & Istio
“A service mesh is an inter-
service communication
infrastructure.”
“The latest greatest thing in
microservices.”
API Gateway Service Mesh

7. Our API Foundation embraces & improves the service mesh.
Thanks to the core open-source Light platform and our investment in in-house skills, we are leading the way.
Doing APIs and microservices the right way forces your bank to act
more like a technology company, which is a critical shift to get right.
Standard Service Mesh
Make no mistake, the Service Mesh represents
the future of APIs & microservices …
The service mesh pattern is still fairly new, and it means different
things to different people. As the model matures, it is like the
implementation options will diversify to suit different needs.
… but there’s still room for innovation from
smart internal teams looking for advantages.
Service Mesh Plus
That’s where skilled internal teams are key, as they should be looking
for opportunities to take the commoditized capabilities available
through open source and compose them into strong differentiators.
Uses a sidecar pattern, which is a dedicated
adjacent microservice acting as a proxy.
Requires all participants in the mesh to use a
homogenous set of agent microservices.
Using Jenkins, process automation for CI/CD is
executed against individual microservices.
Using OAuth, the service mesh can implement
a distributed authorization scheme.
Uses an embedded gateway inside each
microservice, resulting in fewer hops.
Leverages lightweight routers & proxies to
easily adapt to a heterogenous environment
The LightBot extension to Jenkins enables
automating multiple microservices across repos.
By steering the Light OAuth server to our needs,
we are moving to federated authorization.

8. The API Foundation is now in full swing across the bank.
We have taken great strides forward over
the last several months, achieving several
declared milestones.
Although we have only deployed a few
microservices, already we are seeing
significant savings (50-70%) in both cost
and time per integration.
API Foundation Core
Being Used Across
Delivery Teams
• Growing group of API
Foundation Developers
• APIF Core being used
in several active
initiatives
API Governance
Council in Place &
APIs are Mandated
• Council has cross-SBU
representation and
reviews all initiatives
that deviate from APIF
• Initial Governance
process in place, being
continuously refined
Managed Container
Environment (CaaS)
Fully Operational
• Private cloud in place
running an OpenShift-
based CaaS environment
• Development environment
in place, with complete
DevOps and microservice
cross-cutting tools
• Production environment
on track for end of June
Ongoing Developer
Training for APIs &
Microservices
• Over 80 internal
Designers and
Developers have
been trained on APIF
& microservices
• Ongoing training for
APIF, microservices,
swagger, with more
to come.
Pilot of internal
API Marketplace
is Available Today
• Early release of the
API Marketplace
currently running @
marketplace.cibc.com
• Formal beta
targeting end of
June, with general
availability slated
for mid-August.

9. Each pillar is built separately, but to have a stable strategy and
platform you need to build all four pillars, atop a strong foundation.
Each pillar will likely be tackled by different teams, but they are interdependent and must be coordinated.
Getting your API Platform up and ready is a balancing act.
CLOUD DEVOPS APIs AGILE
Bank of the Future
TECHNOLOGY & OPERATIONS
ORGANIZATIONAL STRUCTURE
CORPORATE VALUES & CULTURE
API STRATEGY & PLATFORM

10. Systems that can elegantly & incrementally adapt to an everchanging
environment never have to be replaced – they must only evolve!
Analogies for IT systems are shifting from hard, fixed, industrial things (bridges, buildings, cities) to
soft, flexible, living things (cells, molecules, organisms). This is driven by the need to embrace change.
The single most important idea you have to remember…

11. Thank you!
Check out the Light microservices platform @ http://www.networknt.com