菜单

技术

采纳?

  • 演进式架构借用自进化计算而引入的适应度函数,可以客观地展示应用程序及架构是否正在偏离期望的指标,实际上是可以集成到发布流水线中的测试。 依赖漂移适应度函数 追踪应用程序一个主要指标,即应用依赖的库、API或环境组件的新鲜度,并可以将过时需要更新的依赖标记出来。随着 DependabotSnyk 这类用于检测依赖漂移的工具日趋成熟,我们可以轻松地在软件发布流程中加入依赖漂移适应度函数,以保证应用程序依赖的更新。

    历史信息
  • 对于今天的组织来说,自动化评估、跟踪和预测云基础设施的运行成本是必要的。云供应商精明的定价模型,以及基于定价参数的费用激增,再加上现代架构的动态本质,常常导致让人吃惊的运行成本。例如,无服务架构 基于API访问量的费用,事件流方案中基于流量的费用,以及数据处理集群中基于运行任务数量的费用,它们都具有动态的本质,会随着架构演进而产生改变。当我们的团队在云平台上管理基础设施时, 将运行成本实现为架构适应度函数 是他们的早期活动之一。这意味着我们的团队可以观察运行服务的费用,并同交付的价值进行对比;当看到与期望或可接受的结果之间存在偏差时,他们就会探讨架构是否应该继续演进了。对运行成本的观察和计算需要被实现为自动化的函数。

    历史信息
  • 随着技术格局逐渐复杂化,诸如安全性的问题需要引入更多的自动化和工程实践。在系统构建过程中,我们需要将安全策略——即保护系统免受威胁和破坏的规则和程序,纳入考虑中。例如,访问控制策略定义,并强制谁在什么情况下可以访问哪些服务和资源;相反,网络安全策略应动态限制特定服务的流量速率。 我们的一些团队在 安全策略即代码 上有着丰富的经验。当我们说…即代码时,不仅意味着将这些安全策略写入文件中,还需要将其应用到诸如在代码中采用版本控制、在流水线中引入自动验证、在环境中自动部署并观察监控其性能等实践中。基于我们的经验以及现有工具(包括开放策略代理)和平台(如提供了灵活策略定义和实施机制,以支持安全策略即代码实践的 Istio)的成熟度,我们强烈建议在你的环境中使用此技术。

    历史信息
  • 自从 定制化服务模板 在雷达中出现以来,这个模式已经被广泛采用以帮助组织向微服务过渡。伴随着可观察性工具、容器编排和服务网格边车的不断进步,服务模板可以通过精心挑选的默认值,减少服务与基础设施配合所需的大量设置,从而帮助快速建立新服务。对定制化服务模板应用产品管理原则也取得了成功。以内部开发者作为客户,定制化服务模板可以帮助开发者将代码发布到生产环境,并提供合适的可观察性以进行操作。定制化服务模板带来的另一个好处,是可以作为轻量级的治理机制,对技术选型的默认项进行集中管理。

    历史信息

试验?

  • 大约十年前,我们引入了持续交付(CD),将其作为我们交付软件解决方案的常规方式。如今解决方案在不断增多,其中也包括机器学习模型,并且我们发现在这种解决方案上,持续交付实践仍然适用。我们将之称为机器学习的持续交付(CD4ML)。尽管 CD 的原则仍保持不变,但用于实现训练、测试、部署和监测模型的端到端过程,其实践和工具需要进行一些修改。例如:版本控制不仅要考虑代码的版本控制,还要考虑数据、模型及其参数的版本控制;测试金字塔扩展为包含模型偏差、公平性、数据和特征验证;部署过程必须考虑如何针对当前的冠军模型来提升和评估新模型的性能。当业界正在为 MLOps 这个新的流行词庆祝时,我们反而认为 CD4ML 才是我们实现端到端(可靠地发布以及持续改进机器学习模型,由想法到生产)过程的整体方法。

    历史信息
  • 在管理大量分析数据方面,Data mesh 标志着架构和组织范式的一种可喜转变。该范式建立在四个原则之上:(1)数据所有权和架构的面向领域去中心化;(2)将面向领域的数据视为产品;(3)将自助数据基础设施作为平台,支持自治且面向领域的数据团队;(4)联合控制以实现生态系统和互操作性。尽管这些原则很直观,并且只是试图解决以前集中分析数据管理的许多已知挑战,它们仍胜过了现有的分析数据技术。在现有工具之上为多个客户端构建数据网格后,我们学到了两件事:(a)要加速数据网格的实现,在开源或商业工具上仍存在着巨大的差距(例如,我们目前为客户自定义构建的基于时间的多语言数据,实现通用访问模型);(b)尽管存在差距,使用现有技术作为基本构建块仍是可行的。

    自然,技术匹配是实现企业基于数据网格的数据策略的主要组成部分。不过,要想成功,就需要进行组织结构调整,将数据平台团队分离开来,为每个领域创建数据产品负责人的角色,并引入必要的奖励机制,让领域将其分析数据作为产品,对其负责,并分享出去。

    历史信息
  • 许多数据管道都是在一个巨大的、或多或少是由 Python 或 Scala 编写的命令式脚本中定义的。该脚本包含各个步骤的逻辑以及将这些步骤链接在一起的代码。在 Selenium 测试中遇到类似的情况时,开发人员发现了 Page Object 模式,此后许多行为驱动开发(BDD)框架都实现了将步骤定义与整合代码进行分离。一些团队正在尝试将同样的思想引入数据工程。单独的声明式数据管道定义(也许是用 YAML 编写的)只包含声明和步骤顺序。它声明输入和输出数据集,在需要更复杂逻辑时引用脚本。A La模式 是一个相对较新的工具,它采用 DSL 方法来定义管道,不过 airflow-declarative 工具似乎是这个领域中最有前景的工具,它是一个将 YAML中定义的有向无环图转换为 Airflow 任务调度的工具。

    历史信息
  • 我们看到越来越多的用于创建软件架构和 图表即代码 的工具。相较于使用其他更重量级的工具,这些工具可以更方便的做版本控制,还可以从多个源创建领域特定语言。我们很喜欢这类工具,例如 DiagramsStructurizr DSLAsciiDoctor Diagram,还有诸如 WebSequenceDiagramsPlantUML 等系列产品,当然还有久负盛名的 Graphviz。现在创建一个 SVG 也变得相当简单了,如果能自己动手很快地写一个小工具来做这个,倒也不失为一个不错的选择。例如,本期雷达的某位作者就自己动手写了一个小的 Ruby 脚本用来快速地创建 SVG。

    历史信息
  • 当为我们的应用构建 Docker 镜像的时候,我们常常会考虑两件事情:镜像的安全性和大小。通常情况下我们使用容器安全扫描工具来检测和修复常见的漏洞和风险,以及使用 Alpine Linux 来解决镜像大小和分发性能问题。我们现在已经获得了有关 distroless Docker images 的更多经验,并准备推荐这种方法作为容器化应用程序的另一重要安全预防措施。Distroless Docker images 通过移除完整的操作系统发行版来减少占用空间和依赖。此技术可减少安全扫描噪声和应用程序攻击面,需要修补的漏洞较少,此外,这些较小的镜像更有效。 Google 针对不同的语言发布了一套 distroless container images。你可以使用 Google 构建工具 Bazel 或者仅仅使用多阶段 Dockerfiles 创建简单的应用程序镜像。请注意,默认情况下,Distroless 容器没有用于调试的 shell。不过,你可以在网上轻松地找到 Distroless 容器的调试版本,包括 BusyBox shell。 Distroless Docker image 是 Google 率先提出的技术,根据我们的经验,仍然主要限于 Google 生成的镜像。我们希望这项技术能够超越这一生态系统。

    历史信息
  • 随着越来越多的公司从遗留系统中迁移出来,我们觉得有必要强调一种从这些系统中获取数据的新机制,它可以作为变动数据捕获(CDC)的替代方案。Martin Fowler 早在2004 年就描述了事件拦截。在现代术语中,它涉及到在进入系统时将请求分流,以便逐步构建一个替代系统。这通常是通过复制事件或消息来实现的,但是 HTTP 请求分流也同样有效。例如在将事件写入大型机之前在销售点系统处将事件分流,又如在将支付事务写入核心银行系统之前对其进行分流。这两种情况都会导致部分遗留系统的逐步替换。我们认为,这种从源头获取状态更改,而不是使用 CDC 进行后期处理来重新创建状态更改的技术,一直以来都被忽视了,这也是我们在本期技术雷达中强调它的原因。

    历史信息
  • 大规模替换遗留代码始终是一项艰巨的工作,而且经常受益于执行 并行核对(Parallel run with reconciliation) 。实际上,该技术依赖于通过旧代码和新代码执行相同的生产流程,从旧代码返回响应,比较结果从而对新代码产生信心。尽管这是一种古老的技术,但近年来,我们在持续交付实践(如金丝雀发布和特性切换)的基础上看到了更健壮的实现,并通过添加额外的实验和数据分析层来比较实时结果来扩展它们。我们甚至已经使用这种方法来比较跨功能的结果,例如响应时间。尽管我们已结合定制工具多次使用该技术,但我们还是要感谢 GitHub 的Scientist工具,该工具对应用程序的关键部分进行了现代化改造,现已移植到多种语言。

    历史信息
  • 随着新冠疫情的蔓延,至少在目前,高度分散的团队似乎将成为“新常态”。在过去的六个月中,我们掌握了许多关于有效远程工作的知识。从积极的方面来说,良好的视觉工作管理和协作工具使得和同事们远程协作比以往更容易。例如,开发人员可以借助 Visual Studio Live ShareGitHub Codespaces 来促进团队协作并提高生产力。远程工作的最大弊端可能是筋疲力尽:许多人一整天被安排了大量的“背对背”视频通话,这种缺点带来的风险也开始显现。尽管在线可视化工具使得协作变得更容易,但也有可能会构建出复杂的巨型图,而这些图最终会难以使用;并且工具扩散的安全性方面也需要小心管理。我们的建议是记住后退一步,和你的团队沟通,评估可行与不可行的方法,并根据需要改变流程和工具。

    历史信息
  • 企业中计算和数据的结构不断变化:从单一应用程序到微服务;从集中式数据湖到数据网格;从本地托管到聚合云。与此同时,随着连接设备的激增,保护企业资产的方法在很大程度上仍保持不变。凭借对网络外围的高度依赖和信任——通过加强企业虚拟墙,使用专用链路和防火墙配置,以及替换不再适用于当今现实的静态和繁琐的安全过程的方法,企业继续进行大量投资,以保护其资产。这种持续的趋势迫使我们再次强调“零信任架构”。

    零信任架构是安全体系结构及策略的一种模式转变。它基于这样的假设:网络边界不再代表安全边界,不应仅基于物理或网络位置授予用户或服务隐式信任。用于实现零信任架构各个方面的资源,工具以及平台的数量持续增长,其中包括:以最小特权为基础,执行安全策略即代码,尽可能细化原则,并持续监控和自动缓解威胁;使用服务网格来实施应用到服务和服务到服务的安全控制;使用二进制鉴证以验证二进制文件的来源;除传统加密外,还包括安全区域,以强制实施数据安全性的三大支柱:传输,静态和内存。有关该主题的有用介绍,请参阅 NIST ZTA 刊物和有关 BeyondProd 的 Google 白皮书。

    历史信息

评估?

  • 现在很多公司正在面临的一个最微妙的决定便是是否要采纳低代码平台或无代码平台,这些平台可以被用来在非常特定的领域里解决一些特定的问题。限界低代码平台这一领域的供应商也有如过江之鲫。现在看来,这类平台的一个突出的问题,便是很难应用一些诸如版本控制之类的优秀的工程实践。而且这类平台上的测试也非常的困难。然而我们还是注意到了这个市场里的一些有趣的新兵,例如 Amazon Honeycode 可以被用来创建一些简单的任务和事件管理应用,还有 IFTTT(类似于云工作流)领域的 Parabola,这也是为何我们会将 限界低代码平台 纳入这个部分的原因。但是我们仍然对它们更广泛的适用性深表怀疑,因为这些工具,如日本 Knotweed,非常容易超出它们原本的限界而被泛化用于其他场景,这也是为什么我们对采纳这种技术持强烈的谨慎态度。

    历史信息
  • 腻子脚本在 Web 演进的过程中非常有用,它为那些尚未实现某些现代特性的浏览器提供了替代功能。但是,Web 应用通常会把这些腻子脚本发布到并不需要它们的浏览器中,这就导致了不必要的下载和解析开销。情况已经越来越明朗,因为现在只剩下少数几个渲染引擎,而大多数腻子脚本只针对其中之一:IE11 使用的 Trident 渲染引擎。此外,它的市场份额正在不断减少,其技术支持也将在一年内结束。所以,我们建议你使用 浏览器定制的腻子脚本 ,仅向特定浏览器发布必要的腻子脚本。该技术甚至已经由 Polyfill.io 实现成了服务。

    历史信息
  • SSL/TLS 的核心贡献者 Christopher Allen 在2016年给我们介绍了一种用于支撑新型数字化身份的10个原则,以及实现这一目标的途径:通往自主身份之路。自主身份也被称为 去中心化身份 ,按照基于IP协议栈的信任标准,是一种“不依赖任何中心化权威并且永远不能被剥夺的任何人、组织或事物的终身可转移身份”。采纳和实现去中心化身份正在逐渐升温并变得可能。我们看到了它在隐私方面的应用:客户健康应用政府医疗基础设施公司法律身份。如果想快速地应用去中心化身份,你可以评估 Sovrin NetworkHyperledger AriesIndy 等开源软件,以及去中心化身份可验证凭证 标准。我们正在密切关注这个领域,并帮助我们的客户在数字信任的新时代进行战略定位。

    历史信息
  • 云提供商已开始通过自定义资源定义(CRD)逐渐支持 Kubernetes 样式的 API 来管理其云服务。在大多数情况下,这些云服务是基础架构的核心部分,我们已经看到团队使用诸如 TerraformPulumi 之类的工具进行配置。有了这些新 CRD,如用于 AWSACK;用于 AzureAzure Service Operator 和用于 GCPConfig Connectors,你就可以使用 Kubernetes 来整备和管理这些云服务。这些 由 Kube 管理的云服务 的优点之一是应用程序和基础设施的声明状态可以用相同的 Kubernetes 控制平面来实现。缺点是它将 Kubernetes 集群与基础设施紧密结合在一起,因此我们正在仔细评估它,你也应该这样做。

    历史信息
  • 我们以前多次谈到创建平台工程产品团队来支持公司其他产品团队有许多好处,但实施起来确实很难。在基础设施即代码的世界中,业界似乎仍在寻找正确的抽象。尽管诸如 TerraformHelm 之类的工具,已经朝着正确的方向迈进,但其重点仍然是管理基础设施,而不是应用程序开发。当然,业界还是存在一些向“基础设施即软件”方向的转变,比如涌现出 PulumiCDK 等新工具。而开放应用程序模型(OAM)则试图对该领域进行标准化。通过使用组件、应用程序配置、范围和特征等抽象,开发人员能以与平台无关的方式描述其应用程序。而平台实现者则完全可以用工作负载、特征和范围等另一套抽象来定义其平台。 OAM 是否能被广泛采用还有待观察,但是我们建议关注这个有趣且有用的想法。

    历史信息
  • 安全区域 ,也称为可信执行环境(TEE),是指一种隔离具有较高安全级别的环境(处理器,内存和存储),并且仅提供与其周围的不受信任执行上下文进行有限信息交换的技术。例如,硬件和系统级别的安全区域可以创建并存储私钥,并使用它们执行如加密数据或验证签名等操作,而无需私钥离开安全区域或将其加载到不受信任的应用程序内存中。安全区域提供了一系列有限的指令来执行受信任的操作,并隔离不受信任的应用上下文。

    长久以来,这项技术一直得到许多硬件和系统供应商(包括 Apple)的支持,并且已有开发人员在物联网和边缘应用中使用该技术。然而,直到最近它才在企业和基于云的应用中获得关注。云提供商已经开始引入机密计算功能,如基于硬件的安全区域:Azure 机密计算基础架构允许启用 TEE 的虚拟机,并通过 Open Enclave SDK 开源库进行访问以执行受信操作。同样地,仍处于测试阶段的 GCP 机密虚拟机和 Compute Engine 允许使用在内存中进行数据加密的虚拟机,AWS Nitro Enclaves 紧随其后,即将发布其预览版。随着基于云的安全区域和机密计算的引入,我们现在可以在数据保护的两个支柱:存储的数据保护,传输的数据保护上添加第三个支柱:内存的数据保护。

    尽管仍处于企业安全区域的初级阶段,我们还是建议你考虑此技术,同时了解已知可能危及底层硬件提供商的安全区域漏洞

    历史信息
  • 使用 A/B 测试进行对照实验是揭示有关产品开发决策的好方法。 但是,当我们无法让参与 A/B 测试的两个小组之间彼此独立时,这个方法就失效了,也就是说,将某人添加到"A”小组中会影响“B”小组,反之亦然。 解决此问题空间的一种技术是回旋实验 。 这里的核心概念是我们在特定区域中以交替的时间段在实验的“A”和“ B”模式之间来回切换,而不是在同一时间段内同时运行。 然后,我们比较两个时段之间的客户体验和其他关键指标。 我们已经在某些项目中尝试了此方法,并且取得了不错的效果——它是我们的实验工具栏中一款很好的工具。

    历史信息
  • 凭证在我们生活中无处不在,例如护照、驾照和学历证书。但是,当今大多数数字凭证都是来自信息系统的简单数据记录,易于修改和伪造,并且经常暴露出不必要的信息。近年来,我们已经看到逐步成熟的可验证凭证解决了这一问题。 W3C 标准 将其定义为一种加密安全、尊重隐私和机器可验证的手段。与我们使用物理凭据时的经验类似,该模型以凭证持有者为中心:用户可以将可验证的凭证放入自己的数字钱包中,并在没有凭证发行人许可的情况下随时向其他人展示。这种去中心化的方法还使用户能够更好地管理自己的信息并有选择地公开,从而大大改善了数据隐私保护。例如,借助零知识证明技术,你可以构建可验证的凭证,无需透露自己的生日即可证明你是成年人。社区围绕可验证凭证开发了许多用例。我们已参考COVID-19 凭证计划(CCI) 实施了自己的 COVID 健康认证。尽管可验证凭证不依赖于区块链技术或去中心化身份,但该技术在实践中通常与 DID 结合使用,并将区块链用作可验证的数据注册表。许多去中心化身份的框架也嵌入了该技术。

    历史信息

暂缓?

  • 我们首次在技术雷达中介绍 GraphQL 时,曾提醒误用它会导致反模式,从长远来看弊大于利。尽管如此,我们发现团队对 GraphQL 越来越感兴趣,因为它能够 聚合来自不同资源的信息。这次我们想提醒你谨慎使用 Apollo Federation 和它对公司统一数据图的强大支持。即便乍看之下,有跨组织的普适概念这种想法是具有吸引力的,但是我们必须考虑之前业界做过的类似尝试——如 MDM 和规范数据模型等,这些尝试暴露了这种方法的缺陷。挑战会是巨大的,特别是当我们发现所在的领域要创建一个独特统一的模型非常复杂的时候。

    历史信息
  • 长期以来,我们都反对使用 中心化的企业服务总线,并且将 "智能端点和哑管道 " 定义为微服务架构的一个核心特性。遗憾的是,我们观察到传统的企业服务总线正在沉渣泛起, 披着API网关外衣的企业服务总线 正卷土重来,这自然会对过度庞大的API网关起到推波助澜的作用。不要被市场所惑,无论它顶着什么名号,只要是将业务逻辑(包括编排和转换)放到一个中心化的工具中,都必然会增加架构的耦合度,降低系统的透明度,增加对供应商的绑定,而且还没有任何明显的好处。API 网关仍然可以作为对通用关注点的一个非常有用的抽象,但是我们始终相信,业务逻辑应该由 API 提供,而不是 API 网关或是企业服务总线。

    历史信息
  • 几年前,出现了新一代的日志聚合平台,该平台能够存储和搜索大量的日志数据,用来发掘运营数据中的趋势和洞见。 这种工具有很多,Splunk是其中最著名的。由于这些平台可在整个应用程序范围内提供广泛的运营和安全可见性,因此管理员和开发人员越来越依赖于它们。当干系人发现可以使用 日志聚合进行业务分析 时,他们便开始乐于此道。但是,业务需求可能会很快超越这些工具的灵活性和可用性。旨在提供技术可观察性的日志通常很难对用户有深刻的理解。我们更喜欢使用专门为用户分析而设计的工具和指标,或者采用更具事件驱动性的可观察性方法,其中收集、存储业务和运营事件的方式可以用更多专用工具来重现和处理。

    历史信息
  • 自从我们2016年首次引入微前端以来,这个理念已经变得越来越受欢迎,并获得了主流的认可。但是正如其他名称比较易记的新技术一样,微前端偶尔也会被误用或滥用。尤其值得注意的是,在人们倾向于将一系列相互竞争的技术、工具或框架混合使用在一个页面中时,往往会拿微前端来做挡箭牌,从而导致 微前端的无序 。而这其中则以多个前端框架的混用尤甚。例如,在单页面应用中混合使用React.jsAngular。虽然这种做法在技术上是有可能的,但如果不是作为某个经过深思熟虑的过渡策略的一部分,那这种做法就是非常不可取的。团队之间还需要保持样式技术(例如: CSS-in-JSCSS modules) 和组件集成方式(例如:iFrames 或 web components)的一致性。此外,在状态管理、数据获取、构建工具、分析等其他方面,组织还需要决定到底应该保持一致的标准化方式,还是将这些问题都交由团队自己做决定。

    历史信息
  • 在过去的几十年里,最初由 Wolfram Mathematica 引入的计算笔记已经发展到可以支持科学研究、探索和教育工作流程了。自然,它们还支持数据科学工作流,并且诸如 Jupyter notebooksDatabricks notebooks 已经成为了一个很好的工具,它们提供了简单且直观的交互计算环境,能够结合代码来分析富文本数据,并将其可视化来讲述数据故事。这些笔记本是作为提供现代科学交流和创新的最终媒介而设计的。不过,在近几年,我们发现一种趋势:笔记本成为运行生产质量类型的代码媒介,其中这些代码通常用于驱动企业运营。我们看到笔记本平台供应商宣传他们的探索笔记本在生产中的使用。这是一个好的期望——对数据科学家来说,简易化编程却没有得到很好的实现,并且牺牲了可扩展性、可维护性、弹性以及一个长线产品代码所需支持的所有其他品质。因此我们不推荐生产化的笔记本,而是鼓励对数据科学家赋能,使其能够使用正确的编程框架构建预生产代码,从而简化持续交付工具以及端到端机器学习平台的抽象复杂性。

    历史信息
无法找到需要的信息?

每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

新的,移进/移出 ,没有变化