Welcome to 'This is My Architecture.'
Today, I'm joined by Mauro from Avaloq.
- Hello, Ramon. - Hey, Mauro.
Mauro, tell us about Avaloq.
Sure. Avaloq, we develop fully integrating banking software
where which we provide an enhanced digital experience
to banks and wealth managers.
And we do this by standardizing business processes as a service
or software as a service.
And we use that model to actually provide the service that we want.
Okay, so you brought us an architecture diagram
of the Bank-in-a-Box project.
What is Bank-in-a-Box?
Bank-in-a-Box is--Let me take a step back.
Bank-in-a-Box is because we have the Avaloq ecosystem.
And the Avaloq ecosystem, we built it because we wanted to collaborate
and spur innovation with our customers,
within partners, and also third-party developers.
So for them to be able to actually innovate,
we needed to provide to them on demand like a bank.
So an ABS system for them, so Avaloq Banking System,
to be able to work on and test their APIs.
All right. And so, how would that work? Can you walk us through this architecture?
Sure, sure. The first thing that we need to think is,
when you want to automate something,
you need to have a core, you need to have a brain.
So on one side, we have the users
that actually request something from your automation.
And your automation here, we target EKS
because here we build all the services that we need to automate
all of the infrastructure.
So we pull from ECR
because since we follow the principle of immutable infrastructure,
so docker images on one side.
We have Amazon Machine Images on the other side.
And then we have also static resources
that we use to create the infrastructure that we need for our customers.
Okay. So now, our idea was to say,
okay, when a customer or a partner or a fin-tech
requests an account with us,
we map it directly to the account that we have in Amazon.
So the customer requests an account, we'll spin up an account for the customer.
And when that account is ready, then we're ready to provision the sandbox.
And the sandbox is basically an OpenShift cluster with an Oracle Database.
Everything is based on EC2 instances that we leverage through the AMIs.
So the customer, when he sends it, so after the account is being created,
EKS, even the different services, pull everything together
and start spinning up the ABS.
So it can spin up one, two, three.
It depends on how many the customer actually was entitled to actually use.
Right, right.
So now you have your customer environments, your Bank-in-a-Box, so to say,
for your customers.
How long does this process usually take?
A request for a sandbox, it takes about 50 minutes.
So it's pretty fast because, usually, when you go to customers,
it takes way long.
They need to provision the whole infrastructure, install the software,
and that's we use immutable infrastructure to speed up the process.
Furthermore, also for the accounts, we pre-bake the account.
So we use organizations/organizational units, so that we prepare all ready accounts,
so warm accounts,
and when a customer requests an account,
we already have the account ready,
and we pull it and configure it so that the user can use it.
So the accounts are already there before the user even creates them.
Yes, exactly. Wow, that's really cool.
And so, EKS, as a central management plane, so to say.
Yeah. Why EKS?
When you use Kubernetes, what are you interested about?
You're interested about the worker nodes because you have your services
that you want to deploy on Kubernetes.
And we didn't want to take care of the whole control plane
because it can become a mess.
You need to take care of it.
You need to make sure that it's updated and so forth,
but by using EKS,
we're just concerned about running the images.
So use the Kubernetes APIs to deploy our stuff.
And furthermore, with EKS,
we have the APIs so that we can upgrade it without issues
and requests further nodes and so forth.
Right, so very low maintenance effort for you on your end.
Interesting. And so, obviously, this is a banking environment,
so security is highest priority.
How do you make sure your Bank-in-a-Box, so to say, your environments,
are safe and your customers can't inadvertently open up a port?
What we did is, through our customer, we just expose the Internet-facing services,
but the services of the ABS, not the Amazon services.
So they don't have any access to the APIs of the underlying infrastructure.
And furthermore, we leverage AWS security, so really IAM roles underneath
to be able to set-up the infrastructure,
and we follow the least privilege principle.
Okay. Very interesting.
- Thank you so much for sharing, Mauro. - You're welcome.
And thank you for watching 'This is My Architecture.'