我们希望我们的工程团队能够迅速且敏捷地行动,然而许多组织却将基础设施的所有权与策略的所有权混淆了。工程团队希望迅速迭代并开发他们的 API,这才是策略所有权所代表的。而基础设施的所有权则应由平台团队负责。
在这篇文章中,我们将讨论如何通过安全的 API 基础设施策略为工程师赋能。这是关于如何成为一家以安全 API 为首要任务的公司系列文章的一部分。欢迎联系我们的中国合作伙伴咨询 consultant@gingxing.com。
工程团队应该和不应拥有的内容
工程团队的责任是构建引人入胜的产品和用户体验,同时能够迅速迭代 API 策略并快速发布。通常,他们需要现代 API 基础设施提供的功能子集,包括:
-
服务和 API 新版本的流量路由配置,涵盖通用分流、流量镜像、蓝绿部署、金丝雀发布以及流量内省和请求注入;
-
用于跨不同 API 版本路由的功能标志;
-
访问可观察性指标、日志和跟踪,以及其他流量功能,如重试、超时和熔断。
另一方面,有些组件是工程团队不应该拥有的:
-
基础设施的整体部署
-
基础设施的运维,包括无停机时间升级
-
流量的安全和加密配置
-
身份验证和授权(AuthN/Z),他们可以有影响,但应符合组织更广泛的安全立场
-
日志记录和调试基础设施,包括跟踪基础设施(他们应该有访问权限,但不负责运行这些功能)
-
防火墙规则
-
跨云和跨数据中心的连接性
作为 API 基础设施技术的购买者,评估技术是否允许将基础设施和配置分离以简化整个组织的部署至关重要。这确保了整个组织在统一控制平面的支持下进行简化的部署,同时仍然将数据平面基础设施和应用配置分隔开来:
如果没有制定明确的策略,工程团队将自行开发用于管理 API 基础设施的自定义解决方案。这样,团队将在不知不觉中助长影子 IT 的不良做法,导致缺乏控制和扩展性、组织内部效率低下,并增加安全漏洞的风险。这是一个错误的做法。
显然,我们大家都同意我们不希望我们的团队因效率低下和瓶颈而放慢速度。但不必如此。解决办法是什么?平台团队在代表工程团队管理底层基础设施(在 API 管理和服务网格层)的同时,赋予工程团队一些自主权来应用策略。这需要计划。有时,将整个设置委托给工程团队似乎更容易,但这不可避免地会导致灾难。
我们有责任完全拥有 API 基础设施,而不是将一个庞大的责任区域委托给我们的员工,他们无法与他们的其他任务一起妥善处理。
随着我们的应用程序从单体式发展到微服务,网络要求对我们的应用程序变得越来越重要。我们基本上是在用微服务的网络可靠性和安全问题来取代单体式应用程序中 CPU 的可靠性。当然,这是为了获得更好的可扩展性、恢复力和敏捷性。
我们的应用程序向微服务的转变创造了前所未有的 API 流量规模。
Kong 为数百家顶级财富 500 强和全球 2000 强组织提供了基础设施和配置的隔离,这些组织部署了单个控制面板来跨每个团队管理 API 基础设施,同时仍然允许开发人员在快速迭代中保持快速和敏捷。
想知道 Kong 如何帮助您的组织平衡敏捷性和安全性吗?欢迎联系我们的中国合作伙伴咨询详情 consultant@gingxing.com。