Optimize existing banking applications
and build new ones faster
with IBM Cloud Functions
Daniel Krook
Software Engineer & Developer Advocate
@DanielKrook
bit.ly/icf-bank

Agenda
• Overview of serverless architectures
• Introduction to IBM Cloud Functions, powered by Apache OpenWhisk
• Serverless architectures in banking: A case study
• Demonstration of the proof of concept application
bit.ly/icf-bank

Serverless architectures

Increasingfocusonbusinesslogic
Decreasing concern (and control) over stack implementation
Bare Metal
VM VM
VM
Virtual machines
Functions
Containers
Serverless developers focus more on code, less on infrastructure
bit.ly/icf-bank

Monolithic
Application
Break-down into
microservices
Make each
microservice HA
Protect against
regional outage
Region A
Region B
Microservices can be hard to manage at scale
bit.ly/icf-bank

Emerging workloads are a good fit for event-driven programming
Execute logic in response to database change
Perform analytics on sensor input messages
Provide cognitive computing via chatbots
Schedule tasks performed for a short time
Invoke autoscaled APIs and mobile backends
bit.ly/icf-bank

Memory
allocated
(MB)
Time executing
(milliseconds)
Instances
executing
simultaneously
(count)
Cloud resource cost
better matches
business value gained
Not a silver bullet, but this can result in
substantial savings for many workloads
New cost models more accurately charge for usage
bit.ly/icf-bank

bit.ly/icf-bank
Apache OpenWhisk and IBM Cloud Functions

OpenWhisk is a
cloud platform that
executes code in
response to events
OpenWhisk enables these serverless, event-driven workloads
Provides serverless deployment and operations model
Runs code only on-demand on a per-request basis
Optimized utilization, fine-grained metering at any scale
Flexible, extensible, polyglot programming model
Open source and open ecosystem (Apache Incubator)
Ability to run in public, private, and hybrid models
bit.ly/icf-bank

Developers work with triggers, actions, rules, and packages
Data sources define events
they emit as Triggers.
Developers map Actions to
Triggers via Rules.
Packages provide integration
with external services.
T
A
P
R
Data sources define events
they emit as Triggers.
Developers map Actions to
Triggers via Rules.
Packages provide integration
with external services.
bit.ly/icf-bank

Use Apache OpenWhisk via IBM Cloud Functions: bluemix.net/openwhisk
wsk CLI
bit.ly/icf-bank

IBM Cloud Functions provides management, tooling, and monitoring
bit.ly/icf-bank

IBM Cloud Functions provides management, tooling, and monitoring
bit.ly/icf-bank

IBM Cloud Functions provides management, tooling, and monitoring
bit.ly/icf-bank

IBM Cloud Functions also provides included API gateway integration
bit.ly/icf-bank

bit.ly/icf-bank
Serverless architectures in banking

A large bank was interested in what
serverless architectures could do for them
Attractive new billing model
Compared to a PaaS offering, FaaS
charges the customer based on the
actual time used by the service itself.
Server uptime is not billed (serverless).
bit.ly/icf-bankbit.ly/srvlss-bank
Lower application complexity
Independent scalability, integration and
delivery pipelines, testability and
development flows make it more
streamlined and automated, resulting
into less maintenance efforts and savings
on operations and development costs.
Easier API integration
Provides a great way to quickly and
reliably connect or relay private/public/
hybrid SOA or Cloud APIs at low cost

Their check deposit process was slow and error prone
The bank wanted to improve the speed, accuracy, and efficiency when processing the routing and payer account numbers
on paper checks.
Problem
Bank tellers manually enter this information from checks into branch computing systems. Not only is this error prone, but
the vast number of check deposit requests occur on one day in a two week period: Payday.
This can overwhelm the IT system, which consists of a static set of bare metal servers which don’t always meet demand
(and sit idle most other times), which delays the availability of payee funds, in turn reducing customer satisfaction.
Potential solution
Is there a way to automate this process that improves:
• Accuracy by implementing optical character recognition for data entry?
• Utilization by scaling up and demand as needed, without a fixed ceiling of capacity?
• Cost by mapping a per-transaction model directly onto the exact computing resources needed?
bit.ly/icf-bankbit.ly/srvlss-bank

So let’s scan those checks to automate deposit processing
Optical character recognition (OCR) should be
used to parse the data at the bottom of the check
representing:
• The routing number
• The payer account number
If this information is not readable or does not
follow the presented format, the check will be
considered invalid.
The hand-written amount data is not currently parsable nor is the payee account information provided on a check
itself. This data needs to be passed as metadata (that is, encoded in the file name as supplied by the bank clerk).
Routing number Deposit from account number
bit.ly/icf-bankbit.ly/srvlss-bank

bit.ly/icf-bankbit.ly/srvlss-bank

The bank explored a fully serverless approaches (on the
IBM Cloud) as well as two other hybrid/FaaS models
Serverless with public
IBM Cloud Functions
Deployment of the
computing engine on Cloud
• Serverless computing
Serverless on premises
with Apache OpenWhisk
Deployment of the computing
engine on-premises
• Sensitive data
• Avoid vendor lock-in
Hybrid, in a cloud-
bursting model
Deployment of the
computing model both
Cloud and on-premises
• Total cost of ownership
bit.ly/icf-bankbit.ly/srvlss-bank

Hybrid approach, synchronization through CouchDB replication
bit.ly/icf-bankbit.ly/srvlss-bank

Workload with hybrid scheduling (cloud bursting to public)
bit.ly/icf-bankbit.ly/srvlss-bank

Impressive results based on their capacity, performance, and cost tests
Yearly Cost = # of Executions
x Average Time (in seconds)
x Allocated Memory per Execution
x $ per GB/second
Estimating that
• Number of USA check transactions in 2016: 60 million1
• Average time of execution in seconds: 7 seconds
• Allocated memory per execution in GB: 0.256 GB
• Cost per GB-second of execution: 0.000017 USD
With these estimations we can predict that the
total yearly cost to process every paper check in 2016
would be approximately $1,830 USD if based on OpenWhisk.
bit.ly/icf-bankbit.ly/srvlss-bank

bit.ly/icf-bank
Diving into the code

Demo
github.com/IBM/openchecks
bit.ly/icf-bank

bit.ly/icf-bank
Where to go next

This journey highlights several OpenWhisk strengths
• Actions (functions) can be written in the best language for the job because of support for
polyglot development with Node.js and Docker, among others.
bit.ly/icf-bank
• The same OpenWhisk core system can be consumed on the public cloud and installed within
your own data center.
• The open source nature of OpenWhisk makes it transparent how data moves through the
system and is stored at rest.
• OpenWhisk has built-in support for responding to database change events from Cloudant and
Apache CouchDB.

Other potential banking applications
Overnight batch jobs
Execute tasks in parallel,
scaling out as needed, but
only for a few minutes.
bit.ly/icf-bank
Mobile app backends
Autoscale in response to
demand that differs on
weekends and weekdays.
Customer service bots
Create instances in
response to user inquiries
as needed.

Optimize existing banking applications
and build new ones faster
with IBM Cloud Functions
Daniel Krook
Software Engineer & Developer Advocate
@DanielKrook
bit.ly/icf-bank