Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Optimize existing banking applications and build new ones faster with IBM Cloud Functions


Published on

Recording here:

In retail banking, as in other industries, IT systems are often over-provisioned in anticipation of peak demand. For example extra server capacity may be planned to match an anticipated payday check deposit spike that occurs once every two weeks while remaining mostly idle during periods of lower demand.

In contrast, a serverless architecture can scale computing capacity in response to this demand, efficiently matching the exact capacity as needed. This results in a better customer experience and closer match between bank IT costs and real-time customer demand.

In a recent proof-of-concept with a large global bank, IBM developer advocates helped to modernize a check deposit workflow with an elastic, serverless architecture built on Apache OpenWhisk and IBM Cloud Functions. All told, the bank showed that they might employ this event-driven architecture to theoretically process a billion checks for a small fraction of the current compute costs of their existing system, which uses virtual machines and bare metal servers.

Published in: Software
  • Be the first to comment

Optimize existing banking applications and build new ones faster with IBM Cloud Functions

  1. 1. Optimize existing banking applications and build new ones faster with IBM Cloud Functions Daniel Krook Software Engineer & Developer Advocate @DanielKrook
  2. 2. 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
  3. 3. Serverless architectures
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Apache OpenWhisk and IBM Cloud Functions
  9. 9. 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
  10. 10. 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.
  11. 11. Use Apache OpenWhisk via IBM Cloud Functions: wsk CLI
  12. 12. IBM Cloud Functions provides management, tooling, and monitoring
  13. 13. IBM Cloud Functions provides management, tooling, and monitoring
  14. 14. IBM Cloud Functions provides management, tooling, and monitoring
  15. 15. IBM Cloud Functions also provides included API gateway integration
  16. 16. Serverless architectures in banking
  17. 17. 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). 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
  18. 18. 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?
  19. 19. 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
  20. 20.
  21. 21. 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
  22. 22. Hybrid approach, synchronization through CouchDB replication
  23. 23. Workload with hybrid scheduling (cloud bursting to public)
  24. 24. 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.
  25. 25. Diving into the code
  26. 26. Demo
  27. 27. Where to go next
  28. 28. 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. • 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.
  29. 29. Other potential banking applications Overnight batch jobs Execute tasks in parallel, scaling out as needed, but only for a few minutes. 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.
  30. 30. Optimize existing banking applications and build new ones faster with IBM Cloud Functions Daniel Krook Software Engineer & Developer Advocate @DanielKrook