笔记。 翻译。：这篇在 Medium 上引起轰动的文章概述了编程语言世界和相关技术生态系统（特别关注 Docker 和 Kubernetes）的关键（2010-2019）变化。 其原作者是 Cindy Sridharan，专门研究开发工具和分布式系统，特别是她写了《分布式系统可观察性》一书，在互联网领域颇受 IT 专家欢迎，尤其对云原生主题感兴趣。
2019 年即将结束，我想分享一下我对过去十年中一些最重要的技术进步和创新的想法。 此外，我将尝试展望未来并概述未来十年的主要问题和机遇。
我想澄清的是，在本文中我不涉及数据科学等领域的变化 （数据科学）、人工智能、前端工程等等，因为我个人在这些方面没有足够的经验。
典型化的反击
2010 年代最积极的趋势之一是静态类型语言的复兴。 然而，此类语言从未消失（C++ 和 Java 现在很受欢迎；它们在十年前占据主导地位），但动态类型语言（dynamics）在 2005 年 Ruby on Rails 运动出现后，受欢迎程度显着增加。 随着 Node.js 的开源，这种增长在 2009 年达到顶峰，这使得服务器上的 Javascript 成为现实。
随着时间的推移，动态语言在创建服务器软件领域已经失去了一些吸引力。 在容器革命期间流行的 Go 语言似乎更适合创建高性能、资源高效、并行处理服务器（使用它 Node.js 的创建者本人）。
Rust 于 2010 年推出，包括以下方面的进步 试图成为一种安全的类型化语言。 在这十年的前五年，业界对 Rust 的反应相当冷淡，但在后半程，它的受欢迎程度显着上升。 Rust 的著名用例包括它的用途 , （我们在 - 大约。 译），早期的WebAssembly编译器 来自 Fastly（现在是 bytecodealliance 的一部分）等。随着微软考虑用 Rust 重写 Windows 操作系统的某些部分的可能性，可以肯定地说，这种语言在 2020 年代有着光明的前景。
即使是动态语言也有新的功能，比如 （可选类型）。 它们首先是用 TypeScript 实现的，TypeScript 是一种允许您创建类型代码并将其编译为 JavaScript 的语言。 PHP、Ruby 和 Python 有自己的可选类型系统（, ），已成功用于 .
将 SQL 回归 NoSQL
NoSQL 是另一种在本世纪初比末期更流行的技术。 我认为这有两个原因。
首先，NoSQL 模型由于缺乏模式、事务和较弱的一致性保证，比 SQL 模型更难实现。 在 标题为“为什么你应该尽可能选择强一致性” （为什么你应该尽可能选择强一致性） 谷歌写道：
我们在 Google 学到的一件事是，当工程师可以依靠现有存储来处理复杂事务并保持数据有序时，应用程序代码会更简单，开发时间也会更短。 引用 Spanner 的原始文档，“我们认为，程序员最好在出现瓶颈时处理由于事务滥用而导致的应用程序性能问题，而不是一直牢记事务的缺失。”
第二个原因是由于“横向扩展”分布式SQL数据库（例如 и ）在公共云空间，以及开源替代品，如 CockroachDB （我们也在谈论她 - 约。 译），解决了许多导致传统 SQL 数据库“无法扩展”的技术问题。 即使是 MongoDB，曾经是 NoSQL 运动的缩影，现在也 分布式事务。
对于需要跨多个文档（跨一个或多个集合）进行原子读写的情况，MongoDB 支持多文档事务。 在分布式事务的情况下，事务可以跨多个操作、集合、数据库、文档和分片使用。
总流媒体
Apache Kafka 无疑是过去十年最重要的发明之一。 它的源代码于 2011 年 XNUMX 月开放，多年来，Kafka 彻底改变了企业处理数据的方式。 我工作过的每家公司都使用了 Kafka，从初创公司到大公司。 它提供的保证和用例（发布-订阅、流、事件驱动架构）用于各种任务，从数据存储到监控和流分析，在金融、医疗保健、公共部门、零售等
持续集成（以及较小程度上的持续部署）
持续集成不是最近10年才出现的，但是过去XNUMX年它出现了 已经蔓延到这种程度，它已成为标准工作流程的一部分（对所有拉取请求运行测试）。 建立 GitHub 作为开发和存储代码的平台，更重要的是开发基于 意味着在接受 master 的拉取请求之前运行测试是 唯一的 开发工作流程，对于过去十年开始职业生涯的工程师来说很熟悉。
持续部署（在每次提交到达主节点时进行部署）并不像持续集成那样广泛。 然而，随着用于部署的不同云 API 的出现，Kubernetes（为部署提供标准化 API）等平台的日益普及，以及 Spinnaker 等多平台、多云工具的出现（构建在这些标准化 API 之上） API），部署过程变得更加自动化、简化，并且总体上更加安全。
集装箱
容器可能是 2010 年代最受炒作、讨论、宣传和误解最多的技术。 另一方面，它是过去十年最重要的创新之一。 造成所有这些不和谐声音的部分原因在于我们从几乎所有地方接收到的混合信号。 现在炒作已经逐渐平息，有些事情变得更加引人注目。
容器之所以流行，并不是因为它们是运行满足全球开发人员社区需求的应用程序的最佳方式。 容器之所以流行，是因为它们成功地满足了对解决完全不同问题的某种工具的营销要求。 Docker 原来是 太棒了 解决紧迫的兼容性问题的开发工具（“在我的机器上运行”）。
更准确地说，革命发生了 Docker镜像，因为它解决了环境之间的奇偶校验问题，不仅提供了应用程序文件的真正可移植性，而且还提供了其所有软件和操作依赖项的真正可移植性。 事实上，这个工具在某种程度上刺激了“容器”的流行，而“容器”本质上是一个非常低级的实现细节，对我来说也许仍然是过去十年的主要谜团。
无服务器
我敢打赌，“无服务器”计算的出现甚至比容器更重要，因为它真正使按需计算的梦想成为现实 （按需）。 在过去的五年里，我看到无服务器方法通过添加对新语言和运行时的支持逐渐扩大范围。 Azure Durable Functions 等产品的出现似乎是实现有状态功能的正确一步（同时也是决定性的一步） 与 FaaS 限制相关）。 我将饶有兴趣地关注这种新范式在未来几年如何发展。
自动化
也许这一趋势的最大受益者是运维工程社区，因为它使基础设施即代码 (IaC) 等概念成为现实。 此外，对自动化的热情与“SRE 文化”的兴起不谋而合，该文化旨在采取更加以软件为中心的运营方法。
通用API化
过去十年的另一个有趣的特点是各种开发任务的 API 化。 良好、灵活的 API 允许开发人员创建创新的工作流程和工具，从而有助于维护并改善用户体验。
此外，API化是某些功能或工具向SaaS化的第一步。 这一趋势也与微服务的兴起相吻合：SaaS 已成为另一种可以通过 API 访问的服务。 现在有许多 SaaS 和 FOSS 工具可用于监控、支付、负载平衡、持续集成、警报、功能切换等领域 （功能标记）、CDN、流量工程（例如DNS）等，这些在过去十年中蓬勃发展。
可观测性
值得注意的是，今天我们可以访问 更先进 比以往任何时候都更能监控和诊断应用程序行为的工具。 Prometheus 监控系统于 2015 年获得开源状态，或许可以称为 最好的 与我共事过的人的监控系统。 它并不完美，但很多事情都是以完全正确的方式实现的（例如，支持测量 [维度] 对于指标）。
得益于 OpenTracing（及其后继者 OpenTelemetry）等举措，分布式跟踪是 2010 年代进入主流的另一项技术。 尽管追踪技术的应用仍然相当困难，但一些最新进展给我们带来了希望，我们将在 2020 年代释放其真正的潜力。 （注：另请阅读我们的博客中文章的翻译““同一作者所著。）
展望未来
不幸的是，未来十年还有许多痛点有待解决。 以下是我对它们的想法以及关于如何摆脱它们的一些潜在想法。
解决摩尔定律问题
登纳德缩放定律的终结和摩尔定律的滞后需要新的创新。 约翰·轩尼诗在 解释为什么成瘾者有问题 （特定领域） 像TPU这样的架构可能是解决落后摩尔定律问题的解决方案之一。 工具包如 谷歌似乎已经朝这个方向迈出了一大步：
编译器必须支持新的应用程序，轻松移植到新的硬件，链接从动态、托管语言到向量加速器和软件控制的存储设备等多个抽象层，同时提供用于自动调整的高级开关，提供刚刚-在功能时间上，诊断以及在整个堆栈中分发有关系统功能和性能的调试信息，同时在大多数情况下提供相当接近手写汇编程序的性能。 我们打算分享我们对此类编译基础设施的开发和公开可用性的愿景、进展和计划。
CI / CD
尽管 CI 的兴起已成为 2010 年代最大的趋势之一，但 Jenkins 仍然是 CI 的黄金标准。
这个领域迫切需要在以下领域进行创新：
- 用户界面（用于编码测试规范的DSL）；
- 实现细节将使其真正可扩展且快速；
- 与各种环境（暂存、生产等）集成以实施更高级的测试形式；
- 持续测试和部署。
开发者工具
作为一个行业，我们已经开始创建越来越复杂和令人印象深刻的软件。 然而，当涉及到我们自己的工具时，情况可能会好得多。
协作和远程（通过 ssh）编辑获得了一定的流行，但从未成为新的标准开发方式。 如果你像我一样拒绝这个想法 必要 永久连接到 Internet 只是为了能够进行编程，那么通过 ssh 在远程计算机上工作不太可能适合您。
本地开发环境，特别是对于从事大型面向服务架构的工程师来说，仍然是一个挑战。 一些项目正在尝试解决这个问题，我很想知道对于给定的用例来说，最符合人体工程学的用户体验是什么样的。
将“可移植环境”的概念扩展到其他开发领域（例如错误再现（或 ）在某些条件或设置下发生。
我还希望看到语义和上下文相关代码搜索、将生产事件与代码库特定部分相关联的工具等领域的更多创新。
计算（PaaS 的未来）
继 2010 年代围绕容器和无服务器的大肆宣传之后，公共云领域的解决方案范围在过去几年中显着扩大。
这提出了几个有趣的问题。 首先，公共云中的可用选项列表在不断增长。 云服务提供商拥有员工和资源，可以轻松跟上开源世界的最新发展，并发布诸如“无服务器 Pod”之类的产品（我怀疑只是通过使自己的 FaaS 运行时符合 OCI 标准）或其他类似的奇特产品。
人们只能羡慕那些使用这些云解决方案的人。 理论上，Kubernetes 云产品（GKE、EKS、Fargate 上的 EKS 等）为运行工作负载提供独立于云提供商的 API。 如果您使用类似的产品（ECS、Fargate、Google Cloud Run 等），您可能已经充分利用了服务提供商提供的最有趣的功能。 此外，随着新产品或计算范例的出现，迁移可能会变得简单且无压力。
考虑到此类解决方案范围的发展速度有多快（如果在不久的将来没有出现几个新选项，我会感到非常惊讶），小型“平台”团队（与基础设施相关并负责为运行工作负载的公司）在功能、易用性和整体可靠性方面将非常难以竞争。 2010 年代，Kubernetes 被视为构建 PaaS（平台即服务）的工具，因此在 Kubernetes 之上构建一个与公众相同的选择、简单性和自由度的内部平台对我来说似乎完全没有意义云空间。 将基于容器的 PaaS 视为“Kubernetes 战略”，无异于刻意回避云最具创新性的功能。
如果您查看可用的 今天 计算能力，很明显，仅基于 Kubernetes 创建自己的 PaaS 无异于将自己逼入绝境（这不是一个非常有前瞻性的方法，不是吗？）。 即使今天有人决定在 Kubernetes 上构建容器化 PaaS，几年后与云功能相比它也会显得过时。 尽管 Kubernetes 最初是一个开源项目，但它的祖先和灵感来自 Google 内部工具。 然而，它最初是在 2000 年代初/中期开发的，当时的计算环境完全不同。
此外，从广义上讲，公司不必成为运行 Kubernetes 集群的专家，也不必构建和维护自己的数据中心。 提供可靠的计算基础是核心挑战 云服务提供商.
最后，我觉得我们作为一个行业在以下方面有点倒退了： 交互体验 (）。 Heroku 于 2007 年推出，至今仍然是最流行的工具之一 便于使用 平台。 无可否认，Kubernetes 更加强大、可扩展且可编程，但我怀念它是多么容易上手并部署到 Heroku。 要使用这个平台，你只需要了解Git即可。
所有这些使我得出以下结论：我们需要更好、更高层次的抽象来工作（对于 最高层次的抽象).
最高级别的正确 API
Docker 是一个很好的例子，说明需要同时更好地分离关注点 最高级别 API 的正确实现.
Docker 的问题在于（至少）最初该项目的目标过于宽泛：一切都是为了使用容器技术解决兼容性问题（“在我的机器上运行”）。 Docker 是一种镜像格式、具有自己的虚拟网络的运行时、CLI 工具、以 root 身份运行的守护进程等等。 无论如何，消息的交换是 更多 令人困惑，更不用说“轻量级虚拟机”、cgroup、命名空间、大量安全问题和功能，以及“在任何地方构建、交付、运行任何应用程序”的营销号召。
与所有好的抽象一样，需要时间（以及经验和痛苦）将各种问题分解为可以相互组合的逻辑层。 不幸的是，在 Docker 达到类似的成熟度之前，Kubernetes 就加入了竞争。 它如此垄断了炒作周期，以至于现在每个人都在努力跟上 Kubernetes 生态系统的变化，而容器生态系统则处于次要地位。
Kubernetes 与 Docker 有许多相同的问题。 对于所有关于酷和可组合抽象的讨论， 将不同的任务分层 封装得不是很好。 它的核心是一个容器编排器，在不同机器的集群上运行容器。 这是一个相当低级的任务，仅适用于操作集群的工程师。 另一方面，Kubernetes 也 最高层次的抽象，一个 CLI 工具，用户通过 YAML 与之交互。
Docker 过去是（现在仍然是） 凉爽的 开发工具，尽管有其所有缺点。 为了同时跟上所有“野兔”的步伐，其开发人员成功地正确实现了 最高层次的抽象. 我所说的最高层次的抽象是指 一个子集 目标受众（在这种情况下，大部分时间都在本地开发环境中度过的开发人员）真正感兴趣并且开箱即用的功能.
Dockerfile 和 CLI 实用程序 docker 应该是如何构建良好的“最高水平的用户体验”的一个例子。 普通开发人员无需了解任何复杂性即可开始使用 Docker 有助于积累运营经验的实施例如命名空间、cgroup、内存和 CPU 限制等。 最终，编写 Dockerfile 与编写 shell 脚本没有太大区别。
Kubernetes 针对不同的目标群体：
- 集群管理员；
- 软件工程师致力于解决基础设施问题，扩展 Kubernetes 的功能并创建基于它的平台；
- 最终用户通过以下方式与 Kubernetes 交互
kubectl.
Kubernetes 的“一个 API 适合所有”方法呈现出封装不充分的“复杂性之山”，并且没有关于如何扩展它的指导。 所有这些都导致了不合理地拖延学习轨迹。 如何 Adam Jacob 表示：“Docker 带来了前所未有的变革性用户体验。 询问所有使用 K8s 的人是否希望它像他们的第一台一样工作 docker run。 答案是肯定的”：
我认为当今大多数基础设施技术都太低级（因此被认为“太复杂”）。 Kubernetes 的实现水平相当低。 分布式追踪 （许多跨度缝合在一起形成跟踪视图）也以太低的级别实现。 实现“最高级别抽象”的开发人员工具往往是最成功的。 这一结论在数量惊人的案例中成立（如果技术太复杂或难以使用，那么该技术的“最高级别 API/UI”尚未被发现）。
目前，云原生生态系统由于其低层次的关注点而令人困惑。 作为一个行业，我们必须进行创新、实验和教育，了解“最大、最高抽象”的正确水平是什么样的。
零售贸易
2010 年代，数字零售体验基本保持不变。 一方面，网上购物的便利性本应冲击传统零售商店，另一方面，网上购物十年来基本保持不变。
虽然我对这个行业在未来十年将如何发展没有具体的想法，但如果我们在 2030 年像 2020 年一样购物，我会非常失望。
新闻学
我对全球新闻业的现状越来越失望。 找到公正、客观、细致报道的新闻来源变得越来越困难。 新闻本身和有关新闻的观点之间的界限常常是模糊的。 一般来说，信息的呈现方式是有偏见的。 在一些历史上新闻和观点不分离的国家尤其如此。 英国《卫报》前编辑艾伦·拉斯布里杰 (Alan Rusbridger) 在上次英国大选后发表的一篇文章中表示： :
主要是我多年来一直看美国报纸，为那里的同事感到难过，他们全权负责新闻，把评论留给了完全不同的人。 然而，随着时间的推移，怜悯变成了嫉妒。 我现在认为所有英国全国性报纸都应该将新闻责任与评论责任分开。 不幸的是，普通读者（尤其是在线读者）很难辨别其中的差异。
鉴于硅谷在道德方面的声誉相当可疑，我永远不会相信技术能够“彻底改变”新闻业。 话虽这么说，如果有一个公正、无私和值得信赖的新闻来源，我（和我的许多朋友）会很高兴。 虽然我不知道这样的平台会是什么样子，但我相信，在一个真相变得越来越难以辨别的时代，对诚实新闻的需求比以往任何时候都更大。
社会网络
社交媒体和社区新闻平台是世界各地许多人的主要信息来源，一些平台缺乏准确性，甚至不愿进行基本的事实核查，导致了种族灭绝、选举干扰等灾难性后果。 。
社交媒体也是有史以来最强大的媒体工具。 他们从根本上改变了政治实践。 他们改变了广告。 他们改变了流行文化（例如，对所谓取消文化发展的主要贡献 [排斥文化 - 大约。 译] 社交网络贡献）。 批评者认为，社交媒体已被证明是道德价值观快速而反复无常变化的沃土，但它也为边缘化群体的成员提供了以前所未有的方式组织起来的机会。 从本质上讲，社交媒体改变了 XNUMX 世纪人们交流和表达自己的方式。
然而，我也相信社交媒体会引发人类最糟糕的冲动。 为了受欢迎，考虑和深思熟虑常常被忽视，并且几乎不可能对某些观点和立场表达合理的分歧。 两极分化常常失控，导致公众根本听不到个人意见，而专制主义者控制着网络礼仪和可接受性问题。
我想知道是否有可能创建一个“更好”的平台来促进更高质量的讨论？ 毕竟，正是推动“参与度”的因素往往为这些平台带来了主要利润。 如何 卡拉·斯威舍 (Kara Swisher) 在《纽约时报》中说道：
在不引发仇恨和不宽容的情况下发展数字互动是可能的。 大多数社交媒体网站之所以看起来如此有毒，是因为它们是为了速度、病毒性和关注度而建立的，而不是内容和准确性。
如果几十年后，社交媒体的唯一遗产是对公共话语中细微差别和适当性的侵蚀，那将是非常不幸的。
译者PS
另请阅读我们的博客：
- «“;
- «“;
- «“;
- «“。
来源： habr.com