SPEAKER: We understand that retail banks depend
on Temenos apps to process essential banking
transactions, from deposits and withdrawals to critical loans.
In this demo, our fictional bank has deployed their Transact
core banking app running on new OTP distributed database
on Anthos Google Kubernetes Engine, or GKE,
giving them the flexibility to run production workloads
on premises in their own data center
while also having a secondary site
on Google Cloud set up for bursting
to handle unforeseen surges in core banking
transactions, failover to the cloud for disaster recovery,
and autoscaling back down to maintain business as usual.
This full demo, if done live, spans one hour,
so keep in mind that we have edited for time.
Let's take a quick tour of the dashboard.
Starting on the upper left, you can see the ActiveMQ message
queue count.
Going down the left side, you see the Transact and NuoDB CPU
and NuoDB commits on-prem and in the cloud.
We're using JMeter to load the transactions into ActiveMQ.
So on the upper right chart, we present the number
of transactions per second.
In this demo, the system on-prem is
built to handle a maximum normal load
of 20 transactions per second.
Going down the right side, see the two GKE nodes ready to go,
with the ability to autoscale up to five nodes.
Transact on premise is set scale up to three replicas.
After that, to support additional load,
Transact is set to scale up to 19 replicas in Google Cloud
GKE.
And on the bottom, we show how NuoDB Transaction Engine
is also set to scale up to three replicas.
As we've been going through the tour,
you can see that, with the exception of a brief spike,
the system has been processing a fairly steady
and, quote unquote, "normal load" of about 13 transactions
per second.
In the ActiveMQ chart, you can also
see that, for the most part, transactions
are being processed right away.
So messages are not queueing up.
All looks good so far.
We've started fast forwarding, so you
can see how Google Cloud can help with a sudden surge
up to 150 transactions per second and beyond.
GKE Transact replica scaled to 19,
and GKE nodes autoscale up to 5.
NuoDB transaction engine will also
scale up to 2, with the CPU utilization
rate exceeding the target.
Messages are building in the queue.
We fast forward more to show how the system is coping well
with the increasingly heavy load, and that activity
in the NuoDB transaction engine replicas is converging.
Finally, we reach peak activity of about 250 transactions
per second.
Messages really start accumulating as just too
much for the system to handle.
Now, we simulate a worst case scenario
in this demo, failure on premises at the maximum load.
In this DR scenario, Cloud is just
about managing the messages, while the on-prem site is down.
After about 470 seconds of downtime,
the on-prem data center is operational again.
Next, we'll show how transact on Google Cloud
is set to automatically scale back down when transaction
loads return to normal.
Messages have gone down to zero, transaction engine activity
converges, and Transact replicas in Google Cloud scale
back to 1.
And NuoDB transaction engine in the cloud
also scales down to 2.
The system in the cloud continues to scale down.
NuoDB transaction engine replicas
are now down to a minimum.
And the GKE nodes are starting to scale back down from 5 to 2
as well.
In conclusion, this demo showed how
Transact can be set up to burst seamlessly from on premises
to Google Cloud to handle unforeseen spikes in load,
how we can failover to the cloud,
and also autoscale back down again
to maintain business as usual.
Thank you for watching.