编者按：今天我们听取了 支撑 BBVA 的 Google Cloud 架构师 Gerardo Mongelli de Borja、Diego Garcia Teba 和 Víctor Armingol Guisado 的发言。他们分享了 Google Cloud 如何适应 BBVA 的多云战略，以及他们的团队如何向 BBVA 的利益相关者提供 Google Cloud 服务。




Banco Bilbao Vizcaya Argentaria, S.A. (BBVA) 是一家西班牙跨国金融服务公司，也是世界上最大的金融机构之一。 BBVA 总部位于西班牙马德里和毕尔巴鄂，在九年前开始基于多云架构进行数字化转型。 Cloud SQL 等服务和来自 Google Cloud 的其他解决方案在我们的转型中发挥了重要作用。

在普遍的认知中，金融机构通常并不会快速的接受新技术，但我们愿意尝试并从新的 Google Cloud 解决方案中受益，这帮助我们开辟了一条开创性的数字采用和创新之路，不仅在西班牙银行业内，而且在欧洲和美洲部门也是如此。

我们如何开始使用 Google Cloud

我们通过在 Google App Engine 和 Firestore（当时是 Datastore ）上部署社交网络服务，开始在 Google Cloud 上进行构建。事实证明，这是一个非常灵活的解决方案，它提供了非常短的交付时间，因此我们决定将我们组织的内部网集成到同一系统上。从那时起， BBVA 利益相关者要求提供一些与内部员工相关的应用程序，我们使用相同的 App Engine / Firestore 系统来开发它们。

从那时起， BBVA 进一步扩大了云采用范围。我们成立了一个全球架构部门，其主要目的是构建一个称为以太云服务（ECS）的内部云。我们目前 90% 到 95% 的 Google Cloud 服务诞生于云中，为了避免锁定特定的供应商，我们设计并构建了一个多云架构，我们的整个 ECS 跨越 Google Cloud、AWS 和 Azure 。

为了对我们的长期计划进行更好的迭代，我们的工程团队部分被转移到架构部门，负责为 Google Cloud 构建集成架构。这个内部团队提供的解决方案和原型允许 BBVA 的其他部门按照我们既定的模式在 Google Cloud 之上构建他们的服务。 

Cloud SQL 符合我们的有效托管服务战略

在这九年里，我们的数据库架构也发生了变化，我们在 Google Cloud 中测试了各种服务，以确定最适合我们的需求和路线图的服务，先从 Datastore 开始，后来随着我们探索关系数据库引擎而转向 Cloud SQL。 我们还在 Bigtable 发布时就使用了它，最近，我们一直在使用 Firestore 。

BBVA 优先考虑托管服务的速度、易于维护和集中控制功能。 Cloud SQL 提供了完全托管的关系数据库服务完全符合我们的内部战略。每当有一个管理应用程序具有事务关系数据库的用例时，我们都会考虑将 Cloud SQL 作为选项。对于大多数计划，我们使用 MySQL ，因为人们通常有使用它的经验。 PostgreSQL 还用于更具体的用例，例如全球部署，这些用例通常位于欧洲或美国的区域，并为墨西哥和其他美洲国家/地区提供服务。

BBVA 如何实现新的计划

每当 BBVA 内有业务需求时，解决方案架构部门首先会介入并分析我们的整体技术栈和需求。当出现 使用Google Cloud 场景时（主要是内部员工活动相关的应用程序），我们会从许多 Google Cloud 解决方案中寻找，决定可以在组织内使用哪些工具。

内部应用的例子包括薪酬门户、内部目录和互联网应用，如采购、项目控制和管理控制，所有这些都是在 BBVA 内部开发的。例如，我们在组织内有许多使用 Cloud SQL的 Wordpress 应用程序。大多数应用程序都构建在我们带有 Datastore 的 App Engine 基础堆栈之上。从那里开始，如果该计划需要关系数据覆盖，我们建议将 Cloud SQL 作为解决方案。 如果内部利益相关者需要安装自己的第三方产品，我们可能建议使用 Compute Engine 、 Cloud Run 或 Google Kubernetes Engine （GKE）。

由于 Google 堆栈如此深入和多样化，我们内部的 Google Cloud 团队经常提出有关如何使用服务的内部问题，例如如何将 Dataflow 与外部云集成。因此，解决方案架构师经常来找我们要求进行概念验证或调查，从而导致新的集成。

考虑到这一点，当一个计划带来自己的用例时，解决方案架构部门会设置解决方案，然后委托我们设置整个 Google Cloud 环境。 我们的部分工作是为此类任务提供日常支持。 我们设置了项目，设置 Cloud Identity and Access Management (Cloud IAM) 角色以及所有权限。更具体地说，对于 Cloud SQL ，我们根据他们的需要设置了数据库本身。我们为他们提供了一个具有生成的 root密码的 root 用户，并提供了有关如何开始使用 Cloud SQL 的初步指南。例如，我们尽量避免直接外部连接，因为我们想避免 IP 白名单，因此我们建议使用 Cloud SQL Proxy 进行直接连接。我们也会不时监控它们的使用和消耗、这些项目的计费以及它们是否是适合的 Cloud SQL 数据库的实例规格。

作为我们对计划持续监控工作的一部分，我们继续对 Cloud SQL 与 Google Cloud 中的其他数据库（如 Datastore 和 MySQL）进行基准测试，以便为每个用例推荐最佳选项。通过使用 Cloud Composer ，我们还为各个数据库提供备份系统以符合相关法律标准。例如，我们可能需要过去十年的完整备份，或一周的一次备份，或最近 30 次完整的逻辑备份。

在 BBVA 内部我们有许多 IT 孤岛。不同的团队试图用他们自己安排的解决方案来解决问题。因此，作为我们数字化转型的一部分，我们可能会为这些团队提供将他们的信息放在他们所选择的数据库类型上的选项，只要它位于 Google Cloud 中即可。这样他们就能获得所需的功能，而我们也能获得所需的控制权。

使用 Cloud SQL 解决影子 IT

我们要解决的下一件大事是影子 IT。 Cloud SQL 使我们能够为项目所有者、解决方案架构师和其他一般群体提供一种以安全、可控和经审批的方式创建资源的方法，同时也让他们能够自由灵活地启动资源，而无需让我们成为整个流程中的瓶颈。这使得我们能够应用最佳实践、确保安全和合规，并且开箱即用的监控和警报也可以帮助我们能够更好地了解 BBVA 在 GCP 上的数据库清单。

Google Cloud 支持我们的多云战略

Google Cloud 解决方案的完全集成感觉自然而直观，并且可以轻松使用各种工具，例如 SQL Proxy 或 Identity Aware Proxy (IAP)。 一切都已连接的而且易于使用。当我们找到适用于用例的解决方案时，我们会在组织内一遍又一遍地复制该解决方案。除了 Cloud SQL ，我们还是 Firebase 的超级粉丝，我们在 BBVA 中拥有大量使用这一解决方案的用例。 我们目前正在迁移到 Memorystore for Redis ，以将我们的应用程序从 Google App Engine 版本 1 变更为版本 2。

正如我们对完整的 Google Cloud 产品堆栈的拥抱所展示的那样，我们发现它们是我们数字化转型中有用且有效的解决方案，提供安全性、可扩展性和完全托管的服务，可在我们的多云架构中执行，并使我们能够专注于新计划并满足我们未来路线图的需求。


文章信息

相关推荐