关于云计算:Thoughtworks-Tech-Radar-Vol-24-解读

昨天，Thoughtworks 推送了 2021 上半年技术雷达，总第 24 期。从本期开始，咱们对其中关键技术趋势，站在云厂商视角，解读与思考。<!–more–>

驳回

设计体系

[设计体系](https://www.thoughtworks.com/cn/radar/techniques/design-systems)定义了一组设计模式，组件库，以及良好的设计和工程实际，以确保数字产品的一致性。

观点
这个与各个云厂商提供基于本人云的最佳实际、白皮书的目标是统一的。

扩大浏览

《APPLE 的 Human Interface Guidelines

平台工程产品团队

采纳云计算和 DevOps，尽管进步了团队生产力，缩小了对集中式运维团队和基础设施的依赖，但也制约了那些不足自治理残缺利用和运维技巧的团队。一些组织通过创立 [平台工程产品团队](https://www.thoughtworks.com/cn/radar/techniques/platform-engineering-product-teams) 来应答这些挑战。这些团队保护着一个外部的利用平台，该平台使交付团队可能自助部署和运维零碎，从而缩小交付工夫和升高技术栈的复杂度。这里的重点是 API 驱动的自服务和反对工具，而交付团队依然须要对部署在该平台上的利用负责。

观点
云厂商是否能承当此角色？答案是不齐全能。
云厂商的服务 / 工具，白皮书最佳实际，是为了帮忙业务团队以最小的代价承当此团队的角色。落地的具体的企业，成果可能存在较大差别，这个依赖企业本身能力与企业组织。
互联网原生数字企业，实际成果比拟好；传统制作企业、政府部门实际成果可能比拟差，这种情景就须要带上咨询服务，不过咨询服务如何做到 授人以鱼不如授人以渔 呢？

Sentry

在前端错误报告方面，Sentry 曾经成了许多团队的默认选项。Sentry 提供了一些便当的性能，比方谬误分组，以及应用适当的参数定义谬误过滤规定，能够极大地帮忙解决来自终端用户设施的大量谬误。通过将 Sentry 集成到继续交付流水线中，你能够上传源码映射文件，从而更高效地调试谬误，并能很容易追踪到是在哪个版本的软件中产生了这些谬误。咱们很观赏只管 Sentry 是一个 SaaS 产品，但它的源代码是公开的，这样就能够收费用于一些较小的用例和 [自托管](https://develop.sentry.dev/self-hosted/) 中。

观点
既提供 SaaS 服务又开源，难道这就是优良软件该当具备的素质么。

试验

CDK

咱们许多应用 AWS 的团队中发现，[AWS 云开发工具包](https://docs.aws.amazon.com/cdk/latest/guide/home.html)(AWS CDK)是一个正当的 AWS 默认工具，以实现基础设施的整备工作。其特别之处在于，他们喜爱应用支流编程语言而不是配置文件来进行开发，从而能够应用现有的工具、测试方法和技能。但与相似的工具一样，此时也仍须要审慎地确保部署易于了解和保护。这个开发工具包目前反对 TypeScript、JavaScript、Python、Java、C# 和 .NET。新语言的反对正在被增加到 CDK 中。此外，咱们应用了 AWS 云开发工具包和 HashiCorp 的 [Terraform 云开发工具包](https://learn.hashicorp.com/tutorials/terraform/cdktf) 来生成 Terraform 配置，并胜利实现了与 Terraform 平台的整备。

观点
云是一个超级大的零碎，烟囱式的套件重叠在一起，不是云。AWS 就是一个超大软件系统。

Backstage

随着组织在寻求反对和简化其开发环境时，开始采纳开发者门户，咱们看到人们对 [Backstage](https://backstage.io/) 的趣味和使用量在一直增长。随着工具和技术数量的减少，采纳某种模式的标准化，对于放弃开发的一致性变得越来越重要。因为一旦实现了一致性，开发人员就能够专一于翻新和产品开发，而不是陷入反复创造轮子的泥淖。Backstage 是由 Spotify 创立的开源开发者门户平台。它由软件模板、对立的基础设施工具和统一且集中的技术文档所形成。插件式架构为组织的基础设施生态系统，提供了可扩展性和适应性。

观点
Backstage，就是对应平台工程产品团队所须要的撑持工具。此我的项目还是 CFCF 孵化我的项目，须要关注。

用 Kafka API 而非 Kafka

随着越来越多的企业开始使用事件在微服务之间共享数据、收集剖析数据或传输数据到数据湖，[Apache Kafka](https://www.thoughtworks.com/cn/radar/tools/apache-kafka) 曾经成为撑持事件驱动架构的最受欢迎的平台。只管 Kafka 的可伸缩的音讯长久化概念是革命性的，但要使其失常工作，还是须要依赖泛滥的流动部件，包含 Zookeeper、代理、分区和镜像。尽管实现和保护这些组件会很辣手，然而它们的确在须要的时候，尤其是在企业规模的利用中，提供了极大的灵活性和弱小性能。因为采纳 Kafka 残缺生态系统的门槛较高，所以咱们乐于见到一些平台在最近的爆发式增长。这些平台提供 用 Kafka API 而非 Kafka 的性能。最近涌现出的 [Kafka on Pulsar](https://github.com/streamnative/kop) 和 [Redpanda](https://www.thoughtworks.com/cn/radar/platforms/redpanda)，就是属于这类平台。而 [Azure Event Hubs for Kafka](https://github.com/Azure/azure-event-hubs-for-kafka) 则提供了对 Kafka 生产者和消费者 API 的兼容。但因为 Kafka 的某些性能（例如数据流客户端库）与这些代替代理不兼容，因而依然有理由抉择 Kafka 而不是这些代替代理。然而到底开发者是否会采纳“用 Kafka API 而非 Kafka”的策略，抑或这只是 Kafka 的竞争对手试图将用户诱惑到 Kafka 平台之外，还有待察看。最终，兴许 Kafka 最长久的影响力，就是其提供给客户的易用协定和 API。

观点
最终，兴许 Kafka 最长久的影响力，就是其提供给客户的易用协定和 API，任何实体都会沦亡，唯有文化生生不息。Kafka 能做到这个境界，曾经是高峰了。

Opstrace

[Opstrace](https://opstrace.com/) 是一个用于实现零碎可观测性的开源平台，旨在部署于用户本人的网络中。如果不应用像 Datadog 这样的商业解决方案(例如，因为老本或数据驻留地点的思考)，那么惟一的解决方案就是构建由开源工具组成的本人的平台。这须要投入很大的工作量，而 Opstrace 就是来解决这个问题的。它应用开源 api 和接口，如 [Prometheus](https://www.thoughtworks.com/cn/radar/tools/prometheus) 和 [Grafana](https://www.thoughtworks.com/cn/radar/tools/grafana)，并在下面增加了额定的个性，如 TLS 和身份验证。Opstrace 的外围运行了一个 [Cortex](https://github.com/cortexproject/cortex) 集群，提供可伸缩的 Prometheus API 和 [Loki](https://github.com/grafana/loki) 日志集群。与 Datadog 或 SignalFX 等解决方案相比，它是簇新的平台，所以[依然短少一些个性](https://opstrace.com/docs/references/roadmap#opstrace-roadmap)。尽管如此，它所解决的上述问题，使其在该畛域依然很有前景，值得关注。

观点
刚起步的监控服务，能够继续关注。

Pulumi

咱们曾经看到人们对 [Pulumi](https://pulumi.io/) 的趣味正在迟缓且稳步地回升。尽管 [Terraform](https://www.thoughtworks.com/cn/radar/tools/terraform) 在基础设施编程世界中位置巩固，但 Pulumi 却填补了其中的一个空白。只管 Terraform 是一个久经考验的常备选项，但其申明式编程特质，深受形象机制有余和可测试性无限的困扰。如果基础设施齐全是动态的，那么 Terraform 就够用了。然而动静基础设施但定义，要求应用真正的编程语言。Pulumi 容许以 TypeScript/ JavaScript、Python 和 Go 语言（无需标记语言或模板）编写配置信息，这使其怀才不遇。Pulumi 专一于原生云架构，包含容器、无服务器函数和数据服务，并为 Kubernetes 提供了良好的反对。最近，[AWS CDK](https://www.thoughtworks.com/cn/radar/platforms/aws-cloud-development-kit) 的推出对其造成了挑战，但 Pulumi 依然是该畛域惟一的能独立于任何云平台厂商的工具。咱们冀望未来人们能更宽泛地采纳 Pulumi，并期待呈现能对其提供反对的可行的工具和常识生态系统。

观点
Pulumi 容许开发者通过高级编程语言代替 DSL 编排资源，极大晋升了资源编排开发效率，这个产品会火，预计是 Terraform 的下一跳。AWS 也参考这种模式推出 CDK。

云沙箱

因为云服务变得越来越常见，并且创立 [云沙箱](https://www.thoughtworks.com/cn/radar/techniques/cloud-sandboxes) 变得更加容易且可大规模利用，咱们的团队因而更偏向于应用齐全基于云（绝对本地而言）的开发环境，并以此来缩小保护复杂度。咱们发现用于本地模仿云原生服务的工具限度了开发者对构建和测试周期的信念，所以咱们将重点放在标准化云沙箱上，而不是在开发机器上运行云原生组件。咱们强烈建议您采纳一些精益治理的实际来治理这些沙箱环境的标准化，尤其是在平安、访问控制和区域部署方面。

观点
记得在有一期技术雷达工具象限中，Thoughtworks 给出本地云服务模仿工具，便当利用开发测试。当初举荐 试验 云沙箱，猜测有几方面起因：

• 环境一致性：就如模拟器不能齐全代替真机设备是同一个情理。
• 云资源拜访便利性：云厂商与周边生态的逐渐成熟。

dbt

数据转换是数据处理工作流的重要组成部分：筛选、分组或组合多个数据源，将它们转换为适宜剖析数据或机器学习模型应用的格局。[dbt](https://www.getdbt.com/)既是一个开源工具，也是一个商业化的 SaaS 产品，为数据分析师提供了简略高效的转换性能。实际上，dbt 基于 SQL 实现了转换模型即代码。SQL 依然是数据世界 (包含数据库、仓库、查问引擎、数据湖和剖析平台) 的通用语言，大多数零碎都在肯定水平上反对它。这就使得这些零碎能够通过构建适配器来应用 dbt 进行转换。原生连接器的数量一直增长并囊括了 Snowflake、BigQuery、Redshift 和 Postgres，[社区插件](https://docs.getdbt.com/docs/available-adapters)的范畴也在扩张。咱们看到像 dbt 这样的工具正在帮忙数据平台变得更加“自助”。

观点
既提供 SaaS 服务又开源代码，看来会成为一种趋势？这个工具提倡的 转换模型即代码 的理念有点意思，填补了数据转换 / 数据集成畛域的自动化能力，值得关注。

Prowler

咱们很快乐看到基础设施配置扫描工具的可用性和成熟度都越来越好：[Prowler](https://github.com/toniblyx/prowler)帮忙团队扫描 AWS 基础设施配置，并依据扫描后果进步安全性。只管 Prowler 曾经存在了一段时间，但在过来的几年中，它有了长足的提高，咱们也发现了通过一个较短的反馈闭环来晋升我的项目安全性的价值。Prowler 将 [AWS CIS benchmarking](https://d0.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf) 分为几类（身份和权限治理，日志，监控，网络，CIS Level 1，CIS Level 2，EKS-CIS），其中包含许多查看，能够帮忙你深刻理解 PCI DSS 和 GDPR 合规性。

观点
Center for Internet Security 联盟指定了一套平安治理游戏规则，蕴含平安规范、Benchmark 报告、扫描工具、会员制度。Prowler 是其生态上的一个工具，要是能反对更多的云就更好了。

k6

咱们对 [k6](https://k6.io/) 的呈现感到很兴奋，它是性能测试生态环境中比拟新的一款工具，尤其重视开发者体验。k6 命令行运行器执行 JavaScript 编写的脚本，并让你配置执行工夫和虚构用户的数目。它的命令行有一系列[高级个性](https://k6.io/blog/how-to-control-a-live-k6-test)，比方能够在测试执行实现前，让你看到以后的统计数据，动静伸缩最后定义的虚构用户数量，甚至暂停和持续一个运行中的测试。命令行输入提供了一套带有转换器的可定制指标，能让你在 Datadog 和其余察看工具中可视化后果。为你的脚本增加 [checks](https://k6.io/docs/using-k6/checks)，能够很容易将性能测试集成到你的 CI/CD 流水线中去。如果要减速性能测试，能够看看它的商业版本 [k6 Cloud](https://k6.io/cloud)，它提供了云伸缩以及额定的可视化能力。

观点
又是开源与 SaaS 商业服务并存的模式。看来这种模式是软件的支流商业模式之一，先通过开源工具触达开发者，而后想方法转化为订阅 SaaS 服务的客户。

评估

.NET 5

咱们不会在雷达中介绍每一个新的.NET 版本，但 .NET 5 意味着在将.NET Core 和.NET Framework 合并为繁多平台方面迈出了重要一步。各组织应该开始制订策略，当.NET 5 或 6 版本可用时，将他们的开发环境（依据部署指标的不同而混合不同的框架）迁徙到繁多版本的.NET 5 或 6。这种办法的劣势将是一个通用的开发平台，不用思考预期环境：Windows、Linux、跨平台挪动设施（通过 [Xamarin](https://www.thoughtworks.com/cn/radar/tools/xamarin)）或浏览器（应用 [Blazor](https://www.thoughtworks.com/cn/radar/languages-and-frameworks/blazor) )。尽管对于有工程文化反对的公司来说，多语言开发仍将是首选办法，但其余公司会发现在繁多平台上进行标准化的.NET 开发更有效率。目前，咱们心愿将其保留在“评估”环中，看看.NET 6 中的最终对立框架体现如何。

Graal 原生镜像

[Graal 原生镜像](https://www.graalvm.org/reference-manual/native-image/)是一种以动态链接可执行文件或共享库的模式，将 Java 代码编译为操作系统本机二进制代码的技术。原生镜像通过优化，缩小了应用程序的内存占用和启动工夫。咱们的团队曾经胜利地在 serverless 架构中，将 Graal 原生镜像作为小型 Docker 容器执行，缩小了启动工夫。只管 Graal 原生镜像是为与 Go 或 Rust 等编程语言一起应用而设计的，这些编程语言须要本机编译，须要更小的二进制文件尺寸和更短的启动工夫，但对于有其余需要并心愿应用基于 jvm 的语言的团队来说，Graal 原生镜像也同样有用。

观点
在将来 Serverless 场景下，这个技术前景会很不错。

限界低代码平台

当初很多公司正在面临的一个最奥妙的决定便是是否要驳回低代码平台或无代码平台，这些平台能够被用来在十分特定的畛域里解决一些特定的问题。限界低代码平台这一畛域的供应商也有如过江之鲫。当初看来，这类平台的一个突出的问题，便是很难利用一些诸如版本控制之类的优良的工程实际。而且这类平台上的测试也十分的艰难。然而咱们还是留神到了这个市场里的一些乏味的新兵，例如 Amazon Honeycode 能够被用来创立一些简略的工作和事件治理利用，还有 IFTTT（相似于云工作流）畛域的 Parabola，这也是为何咱们会将 限界低代码平台 纳入这个局部的起因。然而咱们依然对它们更宽泛的适用性深表狐疑，因为这些工具，如日本 Knotweed，非常容易超出它们本来的限界而被泛化用于其余场景，这也是为什么咱们对驳回这种技术持强烈的审慎态度。

观点
低代码平台次要应用场景还是企业 IT，外部员工办公协同场景、经营报表场景，低代码发祥的微软 PowerApp 也是这个一个畛域的。这个畛域说实话对代码品质要求是比拟宽松的，在效率与品质之间衡量，效率优先。

用低代码平台去开发一个企业外围利用，那就是实用方的不对了。

去中心化身份

SSL/TLS 的外围贡献者 Christopher Allen 在 2016 年给咱们介绍了一种用于撑持新型数字化身份的 10 个准则，以及实现这一指标的路径：[通往自主身份之路](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)。自主身份也被称为 去中心化身份，依照[基于 IP 协定栈的信赖规范](https://www.thoughtworks.com/cn/radar/platforms/trust-over-ip-stack)，是一种“不依赖任何中心化权威并且永远不能被剥夺的任何人、组织或事物的一生可转移身份”。驳回和实现去中心化身份正在逐步升温并变得可能。咱们看到了它在隐衷方面的利用：[客户衰弱利用](https://www.civic.com/healthkey/)、[政府医疗基础设施](https://www.truu.id/) 和 [公司法律身份](https://id-bulletin.com/2020/06/04/news-gleif-and-evernym-demo-organization-wallets-to-deliver-trust-and-transparency-in-digital-business/)。如果想疾速地利用去中心化身份，你能够评估 Sovrin Network，Hyperledger Aries 和 Indy 等开源软件，以及去中心化身份 和 可验证凭证 规范。咱们正在亲密关注这个畛域，并帮忙咱们的客户在数字信赖的新时代进行策略定位。

观点
只有身份主权属于用户，数据主权才有根底。

部署漂移提醒器

[部署漂移提醒器](https://www.thoughtworks.com/cn/radar/techniques/deployment-drift-radiator) 使得部署在多个环境中的软件版本漂移可能被可视化。应用了主动部署形式的组织在将软件部署到靠近生产环境的环境中时，可能须要人工批准，这就意味着这些环境里的代码版本可能比以后的开发版本落后好几个版本。这项技术使得这些延后可能被展现在一个简略的面板内，包含在每个环境当中，每个被部署的组件有多大程度的延后。这可能帮忙突出因为曾经实现的软件没有部署到生产环境而导致的机会成本，并使得团队留神相干的危险，例如尚未部署的平安修复。

观点
部署状态、配置状态漂移治理，属于利用治理的范畴，预计会变得越来越重要。在 Gartner 钻研报告 Solution Criteria for Cloud Integrated IaaS and PaaS 中也提到了此项能力要求:

**Desired state configuration**: Customers with an immutable infrastructure approach may want to
detect any drift from the initially provisioned state. The provider must offer the capability to
detect application stack drift, by comparing the current state of elements deployed via its
provisioning templates service, to the defined states in the template. The customer must be able
to run this drift detection against the entire template, as well as individual elements provisioned
by the template. The drift report must contain the specific deviations found. This can be a
dashboard-only capability. The provider may also provide DSC capabilities for compute
instances, detecting and correcting deviations from the desired configuration. The provider may
also provide DSC capabilities for compute instances, detecting and correcting deviations from
the desired configuration.

以后支流云厂商或多或少都有反对部署漂移检测能力:

• AWS: CloudFormation Drift Detection
• Azure: Azure Resource Manager“what-if”

同态加密

齐全的同态加密 (HE)是指一类容许在加密数据上间接进行计算操作（如搜寻和算数运算）的加密办法。同时计算的后果依然以加密的模式存在，并且稍后能够对其进行解密和显示。尽管同态加密问题早在 1978 年就被提出来了，但直到 2009 年才呈现解决方案。随着计算机算力的晋升，和诸如 SEAL, Lattigo, HElib 和 Python 中的局部同态加密之类易于应用的开源库的呈现，同态加密在事实世界的应用程序中的利用才真正地变得可行。那些令人振奋的利用场景包含在将计算外包给一个不受信的第三方时的隐衷爱护，例如在云端对加密数据进行计算，或使第三方可能聚合同态加密后的联邦机器学习的两头后果。此外，大多数的同态加密计划被认为是对量子计算机平安的，并且标准化 同态加密的致力也正在进行之中。

观点
应用同态加密技术来实现 你来奉献算力然而你并不能得悉在算什么 的构想，听起来很不错。

凋谢应用程序模型 (OAM)

凋谢应用程序模型 (OAM) 旨在为“基础设施即软件”制订标准化计划。利用组件、应用程序配置、范畴和特色等形象，开发人员能以与平台无关的形式形容其应用程序。而平台实现者则齐全能够用工作负载、特色和范畴等另一套形象来定义其平台。自从上次提到 OAM 以来，咱们始终对其首个实现 KubeVela 放弃着关注。现在 KubeVela 行将公布 1.0 版，咱们期待着它能证实 OAM 构想中的前景。

观点
理解 OAM 诞生背景，就容易将 OAM 与平台工程产品团队关联起来。OAM 是解决开发人员（业务团队）与运维人员（基础设施团队）之间协同问题所提出的解决方案。

关注隐衷的网络分析

[关注隐衷的网络分析](https://www.thoughtworks.com/cn/radar/techniques/privacy-focused-web-analytics) 是一种收集网络分析的技术，它通过对终端用户匿名化的解决而避免透露其隐衷信息。恪守通用数据保护条例 (GDPR) 的一个令人诧异的后果是，许多组织不惜升高用户体验地应用简单的 cookie 批准过程，尤其是在用户没有立刻批准“所有 cookies”的默认设置的状况下。关注隐衷的网络分析具备双重劣势，无论是模式还是理论它都恪守了 GDPR 条例，与此同时也防止了引入具备侵入性的 Cookie 同意书。这项技术的一个实现便是[Plausible](https://plausible.io/)。

观点
隐衷越来越受到重视，不过隐衷爱护与便利性是矛盾的，如果有一种即放弃便当又爱护隐衷的计划，当然是受欢迎的。Plausible 竟然是 Google Analytics alternative，值得关注。

HashiCorp Boundary

在代理拜访你的主机和服务的场景下，平安网络和身份治理的能力是不可或缺的，[HashiCorp Boundary](https://www.boundaryproject.io/)将这些能力合并在一处，如果须要，还能够连贯多种云服务和本地自行部署的资源。密钥治理能够通过集成你抉择的密钥服务来实现，无论是云厂商提供的密钥服务，还是诸如 [HashiCorp Vault](https://www.thoughtworks.com/cn/radar/tools/hashicorp-vault) 这样的工具。HashiCorp Boundary 反对越来越多的身份认证提供方，并且能够集成到你的服务整体架构当中，来帮忙定义主机甚至是服务级别的权限。比如说，它能够用来实现对 Kubernetes 集群的细粒度访问控制。HashiCorp Boundary 也正在持续开发以反对更多功能，诸如从不同的起源动静拉取服务目录。所有这些实现都被封装在 HashiCorp Boundary 当中，对作为终端用户的、习惯于 shell 应用体验的工程师来说是不可见的，这一切都是通过 Boundary 的网络管理层平安地进行连贯。

观点
HashiCorp 这家公司从最后提供微服务注册核心 Consul，到部署工具 Nomand，再到 Terraform；当初又在平安畛域减少了 Boundary，加上本来有的秘钥治理 Vault；HashiCorp 有成为 IT 与利用治理全栈解决方案的公司的趋势。

imgcook

还记得在钻研我的项目 [pix2code](https://github.com/tonybeltramelli/pix2code) 中，如何通过图形用户界面的截图主动生成代码吗？当初这个技术曾经呈现了产品化的版本— [imgcook](https://www.imgcook.com/)，它是阿里巴巴旗下的软件即服务产品。它能够通过智能化技术把不同品种的视觉稿 (Sketch/PSD/ 动态图片) 一键生成前端代码。在双十一购物狂欢节期间，阿里巴巴须要定制大量的流动广告页面。常常会有一次性页面须要被疾速开发实现。通过深度学习办法，用户体验设计师的设计，首先被解决为前端代码，而后由开发人员进行调整。咱们的团队正在评估这项技术：只管图像处理是在服务器端进行的，主页界面却在网页上，imgcook 提供能够集成软件设计及开发生命周期的 [工具](https://github.com/imgcook)。imgcook 能够生成动态代码，如果你定义了畛域专用语言，它也能够生成数据绑定模块代码，该技术还没达到完满的水平，设计人员须要参考某些标准，以进步代码生成的准确性（尔后仍需开发人员的调整）。咱们对于魔术代码生成始终非常审慎，因为从长远看，生成的代码通常很难保护，imgcook 也不例外。然而如果你限定它用于特定的上下文，例如一次性流动广告页，这项技术值得一试。

观点
尽管阿里巴巴最近处在风口浪尖，他依然是中国平凡的软件公司。

Operator 框架

[Operator 框架](https://operatorframework.io/) 是一套开源工具，可简化 [Kubernetes operators](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) 的构建和生命周期治理。Kubernetes operator 模式最后由 CoreOS 引入，是一种应用 Kubernetes 原生能力来封装操作应用程序常识的办法；它包含要治理的资源和确保资源与其指标状态匹配的控制器代码。这种办法已被用于扩大 Kubernetes，以原生化治理 [泛滥应用程序](https://operatorhub.io/)，特地是有状态的应用程序。Operator 框架有三个组件：[Operator SDK](https://sdk.operatorframework.io/)，简化了 Kubernetes operators 的构建、测试和打包；[Operators 生命周期管理器](https://github.com/operator-framework/operator-lifecycle-manager/)负责 operators 的装置、治理和降级；以及公布和共享第三方 operators 的[目录](https://operatorhub.io/)。咱们的团队发现 Operator SDK 在疾速开发 kubernetes 原生应用程序时特地弱小。

观点
Kubernetes 的 Operator 机制，是撑持 Kubernetes 生态拓展的关键技术。

Yelp detect-secrets

[Yelp detect-secrets](https://github.com/Yelp/detect-secrets) 是一个用于检测代码库中存储的明码的 Python 模块；它会扫描一个门路下所有的文件寻找明码。它能够被用作 Git 预提交钩子或在 CI/CD 流水线的适当地位来进行扫描。它的默认配置上手非常容易，如果有须要也能够进行自定义配置。你还能够装置自定义插件去裁减它默认的启发式搜寻。与其余类似的工具比拟，咱们发现这款工具光以开箱即用的配置，就能够检测到更多品种的明码。

观点
利用治理能够实际此工具。

随着 API 标准生态系统的成熟，咱们看到了更多能够自动化查看款式的工具。[Zally](https://github.com/zalando/zally) 是一个简便的基于 OpenAPI 的代码扫描工具，它有助于确保 API 遵循团队制订的 API 款式指南。以开箱即用的形式，Zally 会针对为 [Zalando 的 API 款式指南](https://opensource.zalando.com/restful-api-guidelines/) 开发的规定集进行验证，同时它还反对基于 Kotlin 扩大机制开发自定义的款式规定。Zally 提供了直观的 UI 界面，展现款式违规的中央，同时也提供了命令行工具，这样能够轻松地集成到继续交付流水线中。

暂缓

天真的明码复杂度要求

明码策略是以后很多组织会默认启用的规范。然而，咱们依然见到很多组织外部要求明码必须蕴含符号、数字、大小写字母和特殊字符。诸如这样的要求就是 天真的明码复杂度要求。这些要求会导致谬误的安全意识，因为用户会因为满足这些要求的明码太难以记忆和输出，而抉择应用更不平安的明码。正如 NIST（美国国家标准技术研究所）举荐所提到的，影响明码强度的次要因素是明码的长度，因而用户应该抉择更长的明码，最长为 64 个字符（包含空格）。这些明码会更平安，并且更易于记忆。

观点
最平安的明码是没有明码。明码长度改为 64 个字符之后，预计唐诗宋词背诵的人会多了起来。

Reference

technology-radar-vol-24

披着 API 网关外衣的企业服务总线

The three Rs of security

Establishing your best practice AWS environment

The Path to Self-Sovereign Identity

更多云最佳实际 https://best.practices.cloud