扩展金融科技开发团队的 Backstage 开发者门户
扩展金融科技开发团队的 Backstage 开发者门户
在不干扰开发者体验的情况下融入 DevOps 原则是实现成功内部开发者门户的关键。
翻译自 Scaling a Backstage Developer Portal for a FinServ Dev Team 。
金融服务机构的技术团队发现自己处于竞争激烈的行业，不达到高质量的数字体验可能会影响客户的忠诚度。
这种竞争的一部分源于数字战略背后的运营成本。由于客户可以轻松获得价格具有竞争力的替代产品，在利率上升的时候尤其是一个相关的威胁，任何增加数字产品交付成本的因素都会使在价格上的竞争变得更加困难。
仅仅这一点就已经足够艰难，更不用说金融服务机构面临的复杂监管限制和安全问题。合规失误会带来巨额罚款，进一步限制定价的灵活性，而安全漏洞带来的声誉损害可能会让客户离开。
今年早些时候，我们会见了一家欧洲金融服务机构，讨论如何应对这些挑战，以更好地支持其开发团队。
团队和技术
其中一个首要任务是找到一种方式，以帮助开发团队在采用先进的云原生架构时更快地进行开发。
该团队以迅速性为出发点，采用了 AWS 云服务，但发现组织标准和配置要求的复杂性成为了阻碍。
开发团队依赖 DevOps 工程师来协调支持开发生命周期的应用环境，其中许多环境需要多个 SaaS 和 PaaS 服务（数据库、消息队列、缓存等）。这导致了漫长的配置过程，进一步减慢了开发者的速度，并延长了发布时间表。
即使大多数配置都通过 Terraform 定义为代码，领导层仍然认为可以进一步提高开发者的生产力。他们一直在考虑采用微服务来加速配置，但对未经监控的云基础设施部署的风险产生了担忧。
这导致了一个权衡：对配置的管理优先于开发者的访问，降低了他们通过公共云寻求的速度。
为了寻求平衡，该组织决定采用以下技术生态系统：
- 使用 Backstage 作为内部开发者平台（IDP），为开发人员提供自助访问应用程序资源的途径；
- 通过 Terraform 定义的 Amazon Web Services（AWS） 云基础架构，存储在 Bitbucket 中，并通过 Quali Torque 进行自动化；
- 与 ServiceNow 集成，以触发新版本、基础架构更改和其他活动的 DevOps 团队的批准请求。
其目标是提供一个平台，既满足开发团队对云访问的要求，又满足 DevOps 团队的标准化优先事项。开发人员可以直接在其 Backstage IDP 中访问环境，而 DevOps 可以通过 ServiceNow 维护对配置的可见性和控制权。
编排层
为了减少 DevOps 团队手动配置的数量，我们首先将组织的 BitBucket 存储库与 Quali 的 Torque 平台连接起来。
这使团队能够发现并导入在 Terraform 模块中定义的基础架构，然后生成新的 YAML，定义了支持每个特定开发者用例所需的所有 SaaS 和 PaaS 服务、依赖关系和输出。
经过 DevOps 的测试和批准后，这些 YAML 文件作为环境配置的模板存储在 git 中，并通过 Backstage 提供给开发团队。这消除了开发团队每次需要环境时都向 DevOps 请求的需要。
同时，DevOps 对这些环境中的异常设置了通知，比如配置的意外更改、不合规的云服务配置或长时间的环境运行时间等，可以在不中断开发者工作流的情况下进行调解。
平台
为了优化体验，我们将 Backstage 与 Quali Torque 集成，以便开发人员可以独立访问所有经批准的环境模板。基于角色的访问控制和帐户凭证的加密通过 Quali Torque 进行管理，满足了 DevOps 对未经批准的配置修改或从暴露的凭密中产生安全风险的担忧。
当开发人员通过Backstage启动创建新的软件组件、云资源或开发环境时，Quali Torque 根据 YAML 中定义的配置进行编排和部署。
这使得 DevOps 团队可以设置规则，自动拒绝违反其配置或操作标准的部署。
在 git 中管理的 Terraform 模块中定义的这些策略指示 Quali Torque 可以部署哪些环境，不能部署哪些环境。例如，创建一个禁止特定服务配置的策略将拒绝部署包含该配置的任何环境。
通过将策略应用于个别开发团队，通过 Quali Torque 工作空间进行管理，可以让 DevOps 将配置和操作标准与每个开发团队的用例相一致。
这种方法还可以自动化支持每个环境的云资源的运作。对于依赖于在正常工作时间内运行的临时环境的团队，策略可以自动在工作日开始时部署支持该团队环境的 AWS 资源，然后在工作日结束时自动终止这些资源。
开发者体验
开发人员通常会对软件组件有所了解。他们在其团队拥有权益的特定微服务范围内工作。 Backstage 为开发人员提供了团队职责的单一视图，以及有关支持这些职责的特定软件组件的信息。
对于这个团队来说，Backstage 允许开发团队查看、理解和访问执行其软件组件的环境，并在需要时执行连接、终止和重新启动这些环境中的资源等“第二天”操作。策略从开发和 DevOps 团队的日常运营影响中解脱出来。额外的集成使开发团队可以通过命令行界面（CLI）、集成开发环境（IDE）或 CI/CD 平台访问这些环境。
如果开发人员或开发团队需要在预定终止时间之外运行环境，他们可以请求由 DevOps 预先设置的持续时间限制内的延期。通过 Backstage UI 提交的与环境相关的其他请求将通过 ServiceNow 向 DevOps 团队触发通知。
集成方法还使 DevOps 团队可以看到资源利用情况。开发人员使用他们的 IDP 通过在 Quali Torque 中定义的模板运行 AWS 云资源，DevOps 可以看到基础架构被运行的频率、持续时间以及由谁运行。这些数据使 DevOps 团队可以深入分析任何运营异常的根本原因，调整其标准并收集反馈，以改进平台的开发者体验。
根据我们与开发团队的合作，可以明确地看出 IDP 对开发者体验的影响。在我们与开发团队的合作中，明显的一点是，有效的开发者体验需要与 DevOps 原则相结合。