Multi-cloud architecture: Three real-world examples from fintech

Multi-cloud architecture: Three real-world examples from fintech
[ Webinar ]

Cloud Concentration Risk

Learn how to architect for Cloud Portability.

Sign up

According to Gartner, by 2025 over 95% of new digital workloads will be deployed on cloud-native platforms. It makes sense – building with cloud-native technologies can shorten development cycles and increase operational efficiency.

Not only do organizations want to build on a cloud-native foundation, but they also want to have the ability to move applications and data from one cloud computing environment (public and/or private) to another with minimal disruption – also known as cloud portability. This capability helps organizations increase resilience and avoid the risks associated with cloud concentration.

In some industries like financial services, it’s also a response to regulations. Increasingly, regulatory bodies across the globe are advancing rules that require companies in important industries like fintech to employ resilient architectures that can survive severe operational disruption (outages, cyber attacks, etc).

One of the best approaches to ensure fault tolerance and achieve cloud portability is to run your applications across multiple clouds. 

However, it can be very difficult to set up multiple cloud environments if your architecture is reliant on legacy software that wasn’t built to be cloud-native, or cloud proprietary tools that can’t run on other clouds.

Below we will discuss how three forward thinking fintech companies build on a cloud-native, distributed SQL database (CockroachDB) to guarantee resiliency, avoid an unfavorable cloud vendor lock-in scenario, and ultimately future-proof their business.

Check out our 2024 multi-cloud webinar with Erol Kavas, Cloud Architect and Director at PwC.

Why Form3 adopted a multi-cloud architecture for payments

In the payments industry, when you serve a global customer base you need to navigate different payment schemes (i.e., the sets of rules for performing payment transactions) in different countries. Form3 was founded to make this much less complex for its customers by delivering a managed payments infrastructure with a single API that helps you adhere to payment schemes wherever you do business.

Aside from different payment schemes that they have to navigate, there are also different legislations Form3 must adhere to. Form3 originally selected AWS as their cloud provider and they started building their Faster Payment System (FPS) access solution on Amazon RDS for PostgreSQL which initially worked well for their needs. 

However, regulators started to ask Form3 questions about their infrastructure: What would happen if you couldn’t use AWS anymore? Is your platform portable? What if AWS has an outage? Can you run your platform in different clouds?

Given all the emerging regulations, Form3 thought there was a better solution: to not depend on any single cloud provider and run across multiple clouds at the same time. 

Form3 multi-cloud architecture

They decided to run CockroachDB across all three cloud providers: AWS, GCP, and Azure. They use the managed Kubernetes control plane offering for each vendor so that the vendor runs Kubernetes. That way, Form3 engineers can concentrate on the value add for the business, which is running their software and developing new features. 

And they don’t have to worry about or manage how their data is distributed, because CockroachDB handles that automatically. Even with that complex multi-node, multi-cloud architecture, developers can still treat CockroachDB as if it were a single-instance Postgres database.

“CockroachDB is doing some amazing gymnastics under the bonnet. You might think it’s just a simple query, but it’s actually going off to different nodes where the data is physically stored to retrieve it. The performance is really good. And then you have this tremendous scaling capability. Using CockroachDB almost feels a bit magic.” – Kevin Holditch Head of Platform Engineering, Form3

RELATED Read the full Form3 case study

Stake controls data location in multi-cloud deployment 

As an online trading company, it’s crucial that Stake is able to provide its customers with the right data at the right time so they can make informed decisions with their money. It’s also important that they are able to easily scale out to a global user base as their platform grows (they have over 450,000 users today) while maintaining high availability. 

When Stake originally started building their product, they wrote the application in Java and they wrote it fast! As with many startups, they wanted to go from concept to MVP very quickly. So they took what they knew and ran with it — ultimately creating a rigid monolithic application that became very hard to modify and created unnecessary technical debt. 

Once Stake’s MVP found product-market fit, it was time to grow their presence and their engineering teams and to move to a more modern approach for building applications via microservices and Kubernetes, coding in Go, and migrating off of PostgreSQL to CockroachDB. The shift allowed the teams to become more efficient and also enabled new engineers to get up to speed quicker.

Stake’s platform rests upon a top-to-bottom cloud native technology stack and they run CockroachDB on AWS and GCP across three regions. Initially, they only used AWS and started to slowly transition workloads to GCP. Because CockroachDB natively supports multi-region and multi-cloud deployments, this process is fairly straightforward and they were able to control where data resides.

“The ability to control where data resides is truly one of the unsung features of CockroachDB. It is so complicated with other systems – CockroachDB gives you flexibility and complete control so you can adhere to all sorts of global data regulations.” - Adrian Hannelly, Stake, Head of DevOps

RELATED Read more about how Stake leverages multi-cloud

How finleap achieved cloud portability

finleap connect (they style their company name in lower case) built a leading European fintech ecosystem, enabling companies in banking, accounting, and lending to provide next-gen, mobile-first financial services to their customers. Open banking is a very regulated, very strict, very security-heavy, and very fast-growing market. In order to keep pace with the competition, finleap recognized they needed to build a cloud-native architecture designed with scale and compliance in mind. 

After switching from VMs to Kubernetes, they needed to find a database that would work natively with their new distributed environment. Migrating a centralized database application (like MySQL, PostgreSQL, Oracle, SQL Server) to a distributed architecture is a difficult and complex task. You can’t just take a legacy RDBMS and wire it up to K8s – which led them to CockroachDB. 

After their successful migration to CockroachDB and Kubernetes, finleap’s customer base started to grow — and along with it, the need to support dozens of different environments while meeting global compliance regulations. More specifically, they needed to achieve cloud portability so that they could move applications from one cloud computing environment (public and private) to another with minimal disruption. This would greatly benefit their customers since it would create a fault tolerant setup. 

To achieve cloud portability, they wanted to run CockroachDB across multiple cloud providers and across federated Kubernetes clusters. Fortunately, CockroachDB is cloud-neutral and can be deployed across multiple clouds and clusters while still functioning as a single logical database — so you don’t actually have to federate clusters. With this setup, finleap is able to run across private clouds, public clouds (AWS, GCP, Azure), OpenStack, VMware, and Equinix. 

“Efficiency is everything! From developing apps to running infrastructure to creating a front-end, we need to be able to execute as quickly and cheaply as possible. CockroachDB greatly reduces operational overhead for our team and makes us feel confident in our ability to grow to new regions in the future.” - Christian Hüning, Director of Technology Cloud & Switchkit

RELATED Dig into how finleap became cloud portable

A multi-cloud future

[ guide ]

Banking resilience at global scale with Distributed SQL

download guide →

These are three examples of how fintech companies are running their applications and services across multiple clouds to support business use cases. With cloud provider outages continuing to cause disruptions for businesses, it might be time to reevaluate your organization’s strategy - especially if you are dealing with payment or customer data. 

If you are interested in hearing more about how CockroachDB makes a multi-cloud platform a reality, check out this post, get in touch, and check out this related video about five benefits of multi region architecture:

About the author

Cassie McAllister linkedin link

Cassie is a Senior Product Marketing Manager at Cockroach Labs. Her focus is on vertical marketing and telling customer stories. She's been in the database world for the past 5 years and previously worked in communications for cybersecurity companies. In her free time, you can find her at the beach, sipping wine, or skiing down a mountain.

Keep Reading

5 reasons to build multi-region application architecture

TL;DR - Multi-region application architecture makes applications more resilient and improves end-user experiences by …

Read more
How Hard Rock Digital built a highly available and compliant sports betting app

In 2020, Hard Rock International (HRI) and Seminole Gaming (SGA) launched Hard Rock Digital and tasked that organization …

Read more
Big Ideas in App Architecture: Store your data where you want

What are the biggest challenges of application architecture today? What are the most efficient and innovative solutions …

Read more