菜单

平台

采纳?

    试验?

    • Azure DevOps 服务包含 Git 仓库托管、CI/CD 流水线、自动化测试工具、待定项管理工具以及生成物(artifact)仓库等在内的一系列管理服务。在这个平台上,我们的团队积累了许多经验,并取得了不错的成绩——这也意味着 Azure DevOps 的逐步成熟。在灵活性上我们对它喜爱有加:它允许你使用来自不同供应商的服务。例如,你可以在 Azure DevOps 流水线服务上使用外部 Git 仓库。尽管我们的团队对 Azure DevOps Pipelines 尤为感兴趣,但不得不说,所有的 Azure DevOps 服务都提供了良好的开发者体验,有助于我们的团队交付价值。

      历史信息
    • Debezium 是一个变更数据捕获(Change Data Capture, CDC) 平台,可以将数据库变更流式传输到Kafka 的 topics。 CDC是一种流行的技术,具有多种应用场景,例如:将数据复制到其他数据库、输送数据给分析系统、从单体中提取数据至微服务以及废除缓存。 Debezium 对数据库日志文件中的变更做出反应,并具有多个CDC连接器,适用于多种数据库,其中包括Postgres、MySQL、Oracle 和 MongoDB。 我们在许多项目中都使用了Debezium,它对我们来说非常有效。

      历史信息
    • Honeycomb 是一种可观测性服务,它可以从生产系统中提取丰富的数据,并可以通过动态采样对其进行管理。开发人员可以记录大量丰富的事件,然后决定如何对它们进行切片和关联。理性预测生产系统出了哪些问题的时代已经过去,在当今的大型分布式系统中,这种交互式方法非常有用。Honeycomb 团队正在积极开发多种语言和框架的插件,已经支持的有GoNode、Java 和 Rails,其他新功能正在迅速添加。另外,其简化过的定价模型也让它更具吸引力。我们团队喜欢它。

      历史信息
    • 在上一期雷达中,JupyterLab 还处于评估象限,作为项目 Jupyter 基于 web 的用户界面,现在它已经成为许多数据从业者的首选。JupyterLab 的使用正在迅速超越 Jupyter Notebooks,且终将取而代之。如果你仍在使用 Jupyter Notebooks,去尝试一下 JupyterLab 吧。JupyterLab 的交互环境是对 Jupyter Notebook 的改进:通过单元格拖拽、tab 自动补全等新特性对原有的功能进行了扩展。

      历史信息

    评估?

    • 数据科学家将大量时间花在数据发现上,这意味着在这一领域能够提供帮助的工具势必会令人兴奋。尽管 Apache Atlas 项目已经成为了元数据管理的实际工具,但数据发现仍然不是那么容易完成的。Amundsen可以与 Apache Atlas 协同部署,为数据发现提供更好的搜索界面。

      历史信息
    • 对于我们许多团队来说,Terraform 已成为定义云基础设施的默认选择。但是,我们的一些团队一直在尝试使用 AWS云开发工具包(AWS CDK),并对其爱不释手。他们尤其喜欢该工具能使用一流的编程语言,而不是配置文件,从而可以利用现有的工具、测试方法和技能。像类似的工具一样,确保部署易于理解和维护也需要花费心思。该工具包目前支持 TypeScript、JavaScript、Python、Java、C#和.NET。AWS 和 HashiCorp 团队最近发布了 Terraform云开发工具包预览版,以生成 Terraform 配置,并用于 Terraform 平台的整备。我们将继续观察 AWS CDK。

      历史信息
    • 组织正在寻求通过开发人员门户或平台来支持和简化开发环境。随着工具和技术数量的增加,为了让开发人员能够专注于创新和产品开发而不必为重新发明轮子陷入困境,某种形式的标准化对于保持一致性来说越来越重要。集中的开发人员门户可以轻松提供服务发现和最佳实践。 Backstage 是一个由 Spotify 提供的创建开发人员门户的开源平台。它基于软件模板、统一的基础设施工具以及一致且集中的技术文档。它的插件化架构允许对组织的基础设施生态系统进行扩展和适配。

      历史信息
    • Dremio 是一个云数据湖引擎,支持针对云数据湖存储的交互式查询。通过使用 Dremio,你无需再为了满足预测性能而将数据提取和转存到一个专门的数据仓库,因此也无需再专门管理那些数据管道了。Dremio 为数据湖中的数据创建虚拟的数据集,并为消费者提供统一的视图。Presto 使存储与计算层分离的技术得到了普及,而 Dremio 则通过提升性能和优化运营成本使这一技术得到了更进一步的推广。

      历史信息
    • DuckDB 是一个嵌入式列式数据库,可用于数据科学与数据分析。 在将数据转移到服务器之前,分析师花费大量时间在本地清洗数据和可视化数据。 尽管数据库已经存在了几十年,但大多数数据库都是为客户端-服务器用例设计的,因此不适合本地交互式查询。 为了解决这一问题,分析人员通常会使用内存数据处理工具,例如:Pandasdata.table。 尽管这些工具是有效的,但它们能分析的范围只限于内存恰好能容纳的数据量大小。 我们认为DuckDB 用嵌入式列式引擎巧妙地填补了工具方面的空白,该引擎针对本地、大于内存的数据集进行了优化。

      历史信息
    • K3s 是一个轻量级的用于物联网和边缘计算的 Kubernetes 发行版。K3s 被打包成一个单独的二进制文件,对于操作系统的依赖性微乎其微,这使得它非常易于运维和使用。K3s 使用 sqlite3 而非 etcd 作为默认的存储后端。由于所有相关的组件都运行在同一个进程里,这使得 K3s 的内存占用非常低。通过剥离不相关的第三方存储驱动和云提供商,K3s 的二进制文件得以控制得非常小。在资源受限的环境中,K3s 是一个值得考虑的非常不错的选择。

      历史信息
    • Materialize 是一种具备以下优势的流式数据库——无须配置复杂的数据管道,就可进行增量计算。其配置过程十分简单,只须通过标准 SQL 视图来描述计算,然后将 Materialize 连接到数据流即可。底层的差异数据流引擎能够执行增量计算,以最小的延迟提供一致且正确的输出。与传统数据库不同,定义 Materialize 的视图没有任何限制,并且计算是实时执行的。

      历史信息
    • 我们已经看到人们对Pulumi的兴趣正在缓慢且稳步地上升。虽然Terraform 在基础设施编程世界中地位稳固,但 Pulumi 却填补了其中的一个空白。尽管 Terraform 是一个久经考验的常备选项,但其声明式编程特质,深受抽象机制不足和可测试性有限的困扰。如果基础设施完全是静态的,那么 Terraform 就够用了。但是动态基础设施但定义,要求使用真正的编程语言。Pulumi 允许以 TypeScript/ JavaScript、PythonGo语言(无需标记语言或模板)编写配置信息,这使其脱颖而出。Pulumi 专注于原生云架构,包括容器、无服务器函数和数据服务,并为Kubernetes 提供了良好的支持。最近,AWS CDK 的推出对其形成了挑战,但 Pulumi 仍然是该领域唯一的能独立于任何云平台厂商的工具。我们期望将来人们能更广泛地采用 Pulumi,并期待出现能对其提供支持的可行的工具和知识生态系统。

      历史信息
    • Tekton 是一个诞生不久的 Kubernetes 原生平台,用于管理持续集成和交付(CI/CD)管道。它不仅在 Kubernetes 上安装和运行,并且还将其 CI/CD 管道定义为 Kubernetes自定义资源。这意味着这些管道现在可以由原生的 Kubernetes 客户端(CLI 或 api)控制,并且可以利用底层资源管理特性(如回滚)。管道的声明格式很灵活,并且允许定义有条件的工作流、并行执行路径以及操作最终任务进行清理等特性。因此,Tekton 可以支持具有回滚、金丝雀发布等功能的复杂混合部署工作流。Tekton 是开源的,同时也作为GCP 管理服务被提供出来。虽然文档还有待改进,社区也在扩大,不过我们已经成功地将 Tekton 用于 AWS 上的生产工作负载。

      历史信息
    • 个人和组织如何在网络上建立数字化的信任,这一持续的挑战催生了关于如何证明身份、如何分享和验证建立信任所需的属性以及如何安全交易的新方法。我们的技术雷达介绍了一些开启数字信任新时代的基础技术,例如去中心化身份可验证凭证

      但是,如果没有将技术栈进行标准化的治理,以实现互操作性,那么就不可能实现这种全球规模的变化。作为Linux基金会的下属组织,新的基于IP协议栈信任基金会已经着手实现这一点。TCP/IP 的标准化成就了互联网的成功,从而实现了数十亿设备之间的互操作。该组织从中获得启发,正在定义具有4层的 基于 IP 协议栈的信任的技术和治理标准。 基于IP 协议栈的信任标准,包括公共工具,例如去中心化的标识符、去中心化的身份验证、代理(如数字钱包)的标准化协议、通信与数据交换协议(如用于发布和验证可验证凭证的数据流)以及应用生态系统(例如教育、金融、医疗保健等)。如果要重新考虑设计身份系统,以及如何建立与现有生态系统的信任,建议研究基于 IP 协议栈的信任标准,及其支持工具 Hyperledger Aries

      历史信息

    暂缓?

    • 技术都有被滥用的趋势,尤其是广为流行的技术。比如现在所见到的“Node泛滥”现象,就是一种随意或误用 Node.js 的趋势。其中有两点很突出。首先,我们经常听到这样的说法——应该使用Node.js,这样只用一种编程语言,就能完成前后端的所有代码。对此,我们还是坚持认为多语言编程是一种更好的方法,尽管我们也将JavaScript作为一等语言。其次,我们经常听到团队将性能作为选择 Node.js 的理由。这种观点已经被大量比较合理的基准数据所否定,但其来源还是有历史原因的。当初, Node.js 变得流行时,还是首个使用非阻塞编程模型的主流框架。该模型让 Node.js 非常适合IO密集型任务(我们在2012年的Node.js文章中提到了这一点)。由于单线程的特点,Node.js 从来就不是计算密集型任务的理想选择。而现在,其他平台已经拥有功能强大的非阻塞框架(其中一些已经配备既优雅又现代的 API )。所以性能已不再是选择 Node.js 的理由。

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

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

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