How BBVA is using Cloud SQL for its next generation IT initiatives
Editor’s note: Today we’re hearing from Gerardo Mongelli de Borja, Diego Garcia Teba and Víctor Armingol Guisado - Google Cloud Architects at BBVA. They share how Google Cloud fits into their multi cloud strategy and how their team provides Google Cloud services to stakeholders in BBVA.
Banco Bilbao Vizcaya Argentaria, S.A. (BBVA) is a Spanish multinational financial services company and one of the largest financial institutions in the world. Based in Madrid and Bilbao, Spain, BBVA has been engaged in digital transformation on a multi-cloud architecture which started nine years ago. Services like Cloud SQL and other solutions from Google Cloud have played instrumental roles in our transformation.
Financial institutions aren’t typically known for their quick embrace of new technology, but our willingness to try and benefit from new Google Cloud solutions has helped us carve a trailblazing path of digital adoption and innovation not only within the Spanish banking sector, but within the European and the Americas sectors as well.
How we started on Google Cloud
We began building on Google Cloud by deploying a social network service on Google App Engine with Firestore (back then Datastore). This proved to be an incredibly flexible solution that provided such short delivery times that we decided to integrate our organization’s intranet on the same system. From that point forward, BBVA stakeholders requested a number of internal employee-related applications, and we developed them using the same App Engine/Firestore system.
Since then, BBVA has further extended its cloud adoption. We established a global architectural department whose main purpose was to build an internal cloud called Ether Cloud Services (ECS). 90 to 95 percent of our current Google Cloud services were born in the cloud, and to avoid vendor lock-in, we’ve designed and built a multi-cloud architecture, with our entire ECS spanning over Google Cloud, AWS, and Azure.
To better iterate on our long-term plans, our section of the engineering team was moved within the architectural department and tasked with building an integration architecture for Google Cloud. This internal team provides the solutions and archetypes that allow the rest of BBVA to build their services on top of Google Cloud, following our established patterns.
Cloud SQL fits our strategy for effective managed services
Over those nine years, our database architecture has transformed as well, and we’ve tested various services within Google Cloud to determine which best suited our needs and our roadmap, starting with Datastore and later moving to Cloud SQL as we explored relational database engines. We also used Bigtable upon its release, and more recently, we’ve been using Firestore.
BBVA prioritizes managed services where available for their speed, ease of maintenance, and centralized control features. The fully managed relational database service provided by Cloud SQL fits perfectly within our internal strategy. Any time there’s a management application with a use case for a transactional relational database, we consider the option of Cloud SQL. For most initiatives, we use MySQL, since people often have experience working with it. PostgreSQL is also used for more specific use cases such as global deployments, which are typically regional in Europe or the U.S. and provide service to Mexico and other American countries.
How BBVA approaches new initiatives
Whenever there’s a business requirement within BBVA, the solution architecture department first jumps in and analyzes our overall technology stack and the initiative requirements. When a Google Cloud use case arises—and that’s mainly on internal employee-activity applications—we pull from many of the Google Cloud solutions, deciding which tools can be used within the organization.
The internal application examples include paycheck portals, internal directories, and internet applications like procurement, project control, and management control, all developed within BBVA. For example, we have many Wordpress apps within the organization that use Cloud SQL. Most of the applications are built on top of our base stack of App Engine with Datastore. From there, if the initiative needs relational data coverage, we propose Cloud SQL as a solution. If the internal stakeholders need to install their own third-party product, we may suggest using Compute Engine, Cloud Run, or Google Kubernetes Engine GKE)
Because the Google stack is so deep and diverse, our internal Google Cloud team often fields internal questions about how to use a service, such as how to integrate Dataflow with an external cloud. So then solution architects often come to us to ask for a proof of concept, or an investigation, which leads to a new integration.
Having that in mind, when an initiative brings its own use case, the solution architecture department sets up the solution, and turns to us to set up the whole Google Cloud environment. Part of our job is to provide daily support to such tasks. We set up the project, we set up the Cloud Identity and Access Management (Cloud IAM) roles, and all the permissions. More specifically for Cloud SQL, we set up the database itself according to their needs. We give them a root user with a generated root password, and we provide initial guidelines on how to start using Cloud SQL. For example, we try to avoid direct external connections, since we want to avoid IP whitelisting, so we recommend using Cloud SQL Proxy for their direct connections. From time to time, we monitor their use and consumption, the billing for those projects, and whether they have the proper sizing for Cloud SQL databases.
As part of our constant monitoring work on initiatives, we continue to benchmark Cloud SQL against other databases within Google Cloud like Datastore and MySQL in order to recommend the best option for each use case. Using Cloud Composer, we also provide backup systems for individual databases to comply with legal standards. For example, we might need a full backup for the last ten years, or one backup for a week, or the last 30 full logical backups.
We have many IT silos within BBVA. Different teams try to tackle a problem with a solution they arrange themselves. So as part of our digital transformation, we may offer these teams the option to put their information on a database type of their choice so long as it's within Google Cloud. That way, they get the features they need, and we get the control we need.
Using Cloud SQL to solve shadow IT
One of the next big things for us to solve is Shadow IT. Cloud SQL allows us to give project owners, solution architects and other groups in general, a way to create resources in a secure, controlled and approved way while at the same time giving them the freedom and flexibility to spin up resources without us having to be a bottleneck in the process. This allows us to apply best practices, keep things secure and in compliance, out of the box monitoring and alarms and gives us better visibility into BBVA’s database inventory on GCP.
Google Cloud supports our multi-cloud strategy
The full integration of Google Cloud solutions feels natural and intuitive, and makes it so easy to work with its various tools, such as SQL Proxy or Identity Aware Proxy (IAP). Everything is connected and easy to use. And when we find a solution that works for a use case, we reproduce that solution over and over within the organization. In addition to Cloud SQL, we’re super fans of Firebase, and we have an explosion of use cases within BBVA that are being handled well with this solution. We’re currently migrating to Memorystore for Redis to change our applications from Google App Engine version one to version two.
As our embrace of the full Google Cloud stack of products shows, we’ve found them to be instrumental and effective solutions in our digital transformation, offering security, scalability, and fully managed services that perform across our multi-cloud architecture, and allow us to focus on new initiatives and meeting the needs of our future roadmap.