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.

Transition to the Cloud without Compromises

Digital transformation is continuously disrupting industries, particularly financial services organizations, in an unprecedented way. Why? Two key reasons: customer demand and business agility. The monolithic databases that enterprise organizations have relied on for decades for core business operations cannot support the requirements of the financial services industry today. To be competitive in the market, FinServ applications must be immediately consistent, continuously available, able to scale out and in on demand, and agile enough to maintain compliance with changing regulations. While legacy database infrastructure powered much of the banking industries’ applications to date, to do so many organizations have accumulated significant technical debt. As forward-thinking enterprises move to the cloud, experts like you are seeking solutions to reduce technical debt while increasing business agility. So what can you do to transition more seamlessly to the cloud? Scale Out. Still SQL.
Join us for this technical webinar and you’ll learn:
How to meet customer demands for application availability and agility
How to migrate to the cloud without rearchitecting every application
How to use distributed SQL databases as your on-ramp to the cloud
How to lower TCO and improve performance within your business-critical applications

  • Be the first to comment

  • Be the first to like this

Transition to the Cloud without Compromises

  1. 1. Scale Out Not Up with Distributed SQL: Transition to the Cloud without Compromises |
  2. 2. 2 | Meet the Speakers Nik Travellyn-Jones Principal Consultant NuoDB Simon Henman Senior Product Manager Enterprise Benchmarking and Sizing Temenos
  3. 3. 3 | Temenos – World’s #1 Core Banking Platform • Over 3,000 banks in 150 countries • 41 of 50 world’s largest banks • 330 successful deployments in 2019 • Model bank for local use
  4. 4. Storage Query Processing Durability SQL Parser SQL Optimizer Transaction Handling Transaction Engine (TE) Storage Manager (SM) TE TE SM SM Query Processing Storage Traditional RDBMS NuoDB Distributed RDBMS App App App App App
  5. 5. 5 | Why Distributed Matter? ● Need to get bigger machine to increase capacity  scale limit ● Need to have a passive failover  cost ● Need time to failover  RTO != 0 ● Can get more machines to increase capacity  unlimited scale ● All servers are Active  lower cost ● Continuous HA  RTO = 0 Scale Up Scale Out Scale Up Traditional RDBMS Distributed RDBMS - NuoDB
  6. 6. 6 | The database has historically been the least scalable component in application architectures, requiring expensive pre-provisioning and disaster recovery hardware. A distributed SQL database provides the transactional consistency your critical applications require, while enabling on demand scale out and continuous availability. Scale Out Lowers TCO & Improves Performance
  7. 7. 7 | Compare Scale-up-only with Scale-out 467 655 1101 2305 395 531 684 759 0 500 1000 1500 2000 2500 0 2 4 6 8 10 12 TPS App servers Retail mix benchmark NuoDB Cumulative TPS Traditional Database Cumulative TPS
  8. 8. 8 | Modern Architectures Microservices, containers, and Kubernetes enable enterprises to update and deploy applications rapidly. Traditional RDBMS cannot take advantage of elasticity and automation offered by these technologies. KubernetesMicroservices Containers
  9. 9. 9 | Benefits Distributed Architecture Active-Active Scale Out Automated Ops Modern architecture separating compute and storage Zero failover time (RTO=0) for always on protection Automated deployment and operations using Kubernetes Operators Address dynamic performance requirements with on-demand scale out and scale in
  10. 10. NuoDB: The Database To Build Your Future On Deploy mission-critical applications on a database built for on-premises, cloud, & hybrid environments Meet end user expectations for continuously available applications Availability Scalability Scale elastically to meet ever-changing application workload demands Choose when, where, and how to deploy mission-critical applications Leverage NuoDB to migrate enterprise SQL applications to cloud-native environments. Flexibility |
  11. 11.  Customers have very different requirements.  Variable growth  Very different transactions  Very different transaction volumes and SLA’s  Retail / Loans / Corporate with large peaks in performance.  Move to the cloud – why NuoDB ?  Distributed architecture  Cloud agnostic  Built in DR & Resilience  Reduction in costs  Active-active across clouds Benchmarking 11
  12. 12.  The objective of the benchmark was to compare *any* traditional RDBMS with NuoDB  Test case was Oracle but could be any RDBMS both with 8 DB cores. Mirror Benchmark 12
  13. 13.  The transaction mix used for comparison was based on retail transactions.  Customer information query – 16%  Account Transaction query - 10 %  Account Balance query – 34% (showing account overview and balances, not the account details)  Customer Information update – 0,1%  Account Details query – 0.1% (owners, product details, overdraft limits etc.)  Money Transfer account to account – 10 % (debit and credit in same transaction)  Posting Debit and Credit transactions – 19.8 % (debit and credit separate transactions)  Posting Cover Reservations – 9% Mirror Benchmark 13
  14. 14.  The traditional RDBMS requires 32 cores @95% busy  NuoDB required less than 6 cores @80% busy.  An additional server (TE) was required with good memory for NuoDB  Linear scalability  Low latency  Lower cost (Based on license in the cloud for TCO)  NuoDB is very well suited to a cloud environment with Temenos software. Mirror Benchmark conclusions 14
  15. 15. ONLINE – Transact & Infinity 15
  16. 16.  Temenos benchmarked the performance & scalability of its latest Transact R19 and Infinity product offerings on AWS Cloud and NUODB, and demonstrated :-  Highly Scalable Performance – 50K+ TPS, which is beyond what a typical customer requires  Lower TCO using Auto scaling (Only pay for what you use)  Use of Modern architecture - Transact, Data Event Streaming, Micro-services, Cloud  Cloud native / Agnostic characteristics – Use of cloud native technologies such as Lambda functions, DynamoDB and Kinesis  Dynamic Deployment – Docker Containers, ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service) High Water Transact & Infinity Benchmark 16
  17. 17.  51,200 TPS (transactions per second) achieved, with a mix of Transact & Infinity traffic  12.7k TPS on Transact (Reservation, Booking, Transfer & Payments)  38.5k TPS on Infinity (Balance enquiry & Transaction list microservices)  COB with auto-scaling completed in 2hrs 34mins on 100m accounts  Database of 100 million accounts across 38 million customers and 50 branches  Streaming Platform (DES) kept Transact and Infinity in sync, with low latency ( < 1.2 s )  Benchmark executed on AWS cloud with NuoDB database, leveraging native AWS technologies  Run with Native Database Locks Executive Summary 17
  18. 18. Executive Summary – Transact & Infinity 18 Peak TPS of 51,200 achieved! Auto-scaling Containers
  19. 19.  Transaction Workload Profile:  Load Pattern:  Ramp up: 0 to 50K TPS gradually over 45min  Steady State: At 50K TPS for 30min  Ramp down: From 50K TPS to 0, over 30min  Conditions:  Native Locking v1.0  NuoDB CONSISTENT READ isolation level was used for Transact and READ COMMITTED for Services Transact & Infinity – Detailed Workload 19
  20. 20. - Invocations Per Min Benchmark Results – Infinity (Lambda) 20 60 / 40 split between Balances and Transactions microservice calls Peak TPS of 38,500 achieved Per Min NOTE: Invocations Per Min = Transactions Per Min Average Response time < 40ms, as indicated from API Gateway. Response times from Load Generator (JMeter) are higher, at 120-150ms, likely to be down to latency of internet traffic
  21. 21. High Level Deployment Architecture 21 Transact DB Temenos Transact Amazon ECS Amazon MQ Temenos Infinity API Gateway (regional) Lambda (Microservices) Dynamo DB Load Generators VPC Load Generators Amazon KinesisLambda (Ingester) DES Source Amazon Kinesis DES Enricher VPC AWS Cloud 38,000 TPS 12,000 TPS
  22. 22. Customer benchmark example (Traditional deployment) 22
  23. 23. Customer benchmark example IBM Cloud (2017) 23 5 x 48 core database servers = 240 cores Servers online at all times ($$$) Response times circa. 240ms
  24. 24. Customer benchmark example IBM LinuxOne 2019. 24 62 cores in total (IFL) 12 DB cores / Oracle 9999.9 guaranteed up time Response times circa. 58ms
  25. 25. IBM LinuxOne Cont. 25 • RESULTS : 3,000 Transact tps on 62 total LinuxOne cores • Now on plan to be tested with NuoDB • Expectations are high due to the way LinuxOne / Mainframe handles its memory. • Plan for on premise Transact & Infinity deployment.
  26. 26. 27 | Next Steps Useful resources: ● Webinar: 3 Things You Need to Know When Assessing Database Scalability ● White paper: 4 Key Considerations for Maximizing Database ROI for Banking Applications ● White paper: Visionary Financial Services Organizations Move Beyond Multi-Cloud to Inter- Cloud Operations ● Get NuoDB Community Edition
  27. 27. Questions?