Ensuring financial stability starts with database stability

Editor’s note: We are hearing today from Freedom Financial Network, provider of technology-based solutions that help consumers overcome debt and establish financial security. To meet the demand of their growing suite of services across the organization, they moved from Rackspace to Google Cloud SQL.

At Freedom Financial Network, our products and services have helped hundreds of thousands of consumers reduce and consolidate their debt. Our suite of customized solutions is driven by a core architecture of intelligent decision-making microservices, shared across the organization, that depend upon independent instances. 

Before making the switch to Google Cloud, we utilized Rackspace’s solution. But over the past year (during a period of significant growth), we realized that we needed to free up our infrastructure and platform teams to provide more comprehensive support across the enterprise. We also wanted to drive growth by transitioning from a monolithic to a microservices architecture, helping us expand our suite of consumer products and allowing our internal teams a more flexible, self-service access to our infrastructure.

On Rackspace, through our existing monolithic architecture, we were managing large clusters of instances running on MySQL. Each of Freedom Financial Network’s business units had one large cluster of instances. Rackspace was managing those clusters, and thus taking work off our hands, but we had very little control over these databases. Every small change such as disk resizing would take a couple of weeks at least. Because of that, our database instances were vastly overprovisioned and expensive. 

We saw that Google Cloud could host and manage all of our databases, saving us valuable time and resources, and that Google Cloud SQL’s versatility would allow us to build flexible, secure solutions that would meet the needs of our teams and our customers. We were able to break down our clusters into many smaller instances that we can manage entirely through automation without adding overhead.

A complex migration made easier by Google Cloud

Our migration involved the transformation of our monolithic architecture to a microservices architecture, deployed on Google Kubernetes Engine (GKE) and using the Cloud SQL Proxy in a sidecar container pattern or the Go proxy library to connect to Cloud SQL. Each microservice uses its own schema and schemas can be grouped in shared instances or be hosted on dedicated instances for higher load applications. 

We successfully leveraged Google Cloud’s new Database Migration Service (DMS) to migrate our databases from Rackspace to Cloud SQL. We used it to migrate three separate production databases, with five total schemas migrated and an overall size of close to 1 TB of data with less than 15 minutes of downtime. Ultimately, the migration was successful and largely painless. We’ve shut down our services at Rackspace, and all of our databases are running on Google Cloud’s managed services now. DMS was really the only option because of the size of our databases. We estimated that doing a “dump and load” migration would have required application downtime in excess of 12 hours—not to mention the hours we would have spent doing prep work. 

Using Cloud SQL as our database foundation

Since completing the migration, Cloud SQL has helped us meet our goals around security, scale, and flexibility. We now deploy a robust set of microservices and instances—following a recent resizing, we have an estimated 180 instances consuming 350 CPUs, for 1300 gigs of RAM. Our microservice examples include everything from simple use cases and application configuration databases to larger, more complex databases that hold information used frequently by business teams. We save so much time not having to manage 180 instances.

Our Platform Team now uses Terraform to create new resources to other Freedom Financial Network teams in Google Cloud. For example, when a team starts a new project and needs a new instance, all they have to do is use the custom Terraform module we’ve built on top of the default Cloud SQL provider to submit a pull request. By creating a module, we ensure that all of the instances are created consistently. The module configures and manages common default options around size of instance needed, if they want to add a read replica, and high availability, while adhering to our regular naming conventions.

We’ve recently switched to using Workload Identity on GKE, which gives us a lot of flexibility around permissions. Each of our microservices has a Kubernetes service account, which is linked through Workload Identity to a Google Cloud services account, and we only grant that account its necessary permissions. This allows us to ensure that each microservice only accesses the instances it needs to perform its tasks. 

A huge benefit of the Cloud SQL Proxy is its security features, allowing us to enforce SSL connections to the databases, and ensuring that the databases aren’t accessible from the outside. We can segregate our data easier, boosting reliability. With greater database segregation, we can limit the blast radius of a potential incident. All of Cloud SQL’s out-of-the-box services, including monitoring, help us flag any potential problems with instances.

With Google Cloud managing our databases, we can focus more time and resources on supporting our other teams. With every team running faster, Freedom Financial Network as a whole can operate faster, we can solve business problems more efficiently, and drive growth in a greater diversity of new areas and customer products. With Google Cloud SQL, our new structure is optimized for our expected growth.

Explore Freedom Financial Network and learn more about Google Cloud SQL.