注意事项 佩雷夫 ：这篇热门文章概述了编程语言和相关技术生态系统中的主要变化（2010-2019年）（特别关注Docker和Kubernetes）。 它的最初作者是Cindy Sridharan，她专门研究开发人员和分布式系统的工具-特别是她写了《分布式系统可观察性》一书，并且在Internet领域中受到了对云原生主题特别感兴趣的IT专业人员的欢迎。
2019年即将结束，所以我想分享我对过去十年中一些最重要的技术成就和创新的看法。 此外，我将尝试展望未来，并概述未来十年的主要问题和机遇。
我想立即提出保留意见，在本文中我不涉及
数据科学 ，人工智能，前端工程等领域的变化，因为我个人对此没有足够的经验。
打反击
2010年代最积极的趋势之一是静态静态语言的复兴。 但是，此类语言并没有消失（当今需要C ++和Java；十年前已经成为主流），但是在2005年Ruby on Rails运动出现之后，具有动态类型（动态）的语言受到了极大的欢迎。 随着Node.js源代码的开放，这种增长在2009年达到顶峰，使得服务器上的Javascript成为现实。
随着时间的流逝，动态语言在服务器软件开发中已经失去了吸引力。 在容器革命期间流行的Go语言似乎更适合于创建具有并行处理信息的高性能，资源高效的服务器（Node.js的创建者
同意 ）。
Rust于2010年推出，其中包括
类型理论方面的进步，旨在成为一种安全的类型化语言。 在此十年的上半年，业界对Rust的态度相当酷，但是在下半年，Rust的知名度显着提高。 Rust使用的值得注意的例子包括它
在Dropbox中的Magic Pocket中的使用，
AWS Firecracker （我们在本文中已经讨论过-大约Transl。） ，Fastly的Fastly早期WebAssembly编译器（现已成为Bytecode Alliance的一部分）等。在Microsoft考虑将Windows的某些部分重写为Rust的情况下，可以肯定地说，这种语言在2020年代有光明的前景。
甚至动态语言也获得了新的功能，例如
可选类型 。 它们首先在TypeScript中实现，TypeScript是一种语言，它允许您创建类型化的代码并在JavaScript中进行编译。 PHP，Ruby和Python已经获得了自己的可选类型系统（
mypy ，
Hack ），这些系统已成功用于
生产中 。
SQL返回NoSQL
NoSQL是另一种技术，该技术在本世纪初比在末期更受欢迎。 我认为有两个原因。
首先，事实证明，与SQL模型相比，NoSchema模型缺乏模式，事务和对一致性的较弱的保证更加难以实现。 Google在标题为“
为什么要尽可能选择强一致性的
博客 ”中写道：
我们在Google上学到的一件事是，如果工程师可以依靠现有的存储来处理复杂的事务并维护数据顺序，则应用程序代码更简单，开发时间更短。 引用Spanner的原始文档，“我们认为，最好是程序员在出现瓶颈时处理由于事务滥用而引起的应用程序性能问题，而不是始终不考虑事务。”
第二个原因与公共云空间中“可伸缩”分布式SQL数据库（例如
Cloud Spanner和
AWS Aurora ）的增长以及CockroachDB之类的开源替代方案
（我们也写过它-大约Transl。）有关 ，许多解决方案由于技术问题，传统的SQL库“无法扩展”。 甚至曾经是NoSQL运动缩影的MongoDB现在也
提供分布式事务。
对于需要对多个文档（在一个或多个集合中）进行原子读写操作的情况，MongoDB支持包含多个文档的事务。 对于分布式事务，事务可以用于许多操作，集合，数据库，文档和分片。
总流媒体
毫无疑问，Apache Kafka已成为过去十年中最重要的发明之一。 它的源代码于2011年1月开放，多年来，Kafka彻底改变了数据业务的运作方式。 从初创公司到大型公司，Kafka被用于我有工作机会的所有公司。 提供给他们的保证和用例（发布，订阅，流，面向事件的体系结构）用于各种任务：从组织数据存储到监视和流分析，这在许多领域都需要，例如金融，医疗保健，公共部门，零售和等
持续集成（在较小程度上持续部署）
连续集成在过去十年中没有出现，但是在过去的十年中，它已经
扩散到某种程度 ，以至于它已成为标准工作流程的一部分（对所有请求请求进行测试）。 成为GitHub作为开发和存储代码的平台，更重要的是，基于
GitHub流开发工作
流程意味着在接受向主提交请求之前进行测试是工程师开始从事其职业的
唯一工作流程最近十年。
连续部署（连续部署；按原样部署每个提交并在其进入主服务器时进行部署）不如连续集成广泛。 但是，随着许多不同的基于云的API进行部署，像Kubernetes这样的平台（为部署提供标准化API）的日益普及以及诸如Spinnaker的多平台，多云工具（基于这些标准化API的建立）的出现，部署过程变得更加自动化，简化和简化。通常比较安全。
货柜
也许可以说这些容器是2010年代最被炒作，讨论，广告和误解的技术。 另一方面，这是过去十年中最重要的创新之一。 所有这些杂音的部分原因是我们几乎在任何地方都收到的混合信号。 既然炒作已经平息了一些时间，那么片刻就会变得更加鲜明。
容器之所以流行，并不是因为它们是运行可满足全球开发者社区需求的应用程序的最佳方式。 容器之所以受欢迎，是因为它们成功地满足了市场对一种解决完全不同问题的工具的需求。 事实证明，Docker是解决紧迫的兼容性问题（“在我的机器上工作”）的
出色开发工具。
更确切地说，
Docker映像发生了革命性的变化，因为它解决了环境之间的奇偶校验问题，并确保了应用程序文件及其所有软件和操作依赖性的真正可移植性。 这个工具以某种方式刺激了“容器”的普及，实际上构成了非常底层的实施细节，这一事实对我来说也许仍然是过去十年的主要谜团。
无服务器
我敢打赌，“无服务器”计算的出现比容器更为重要，因为它确实使您能够实现
按需计算的梦想。 在过去的五年中，我注意到无服务器方法的范围逐渐扩大（增加了对新语言和运行时的支持）。 诸如Azure耐用功能之类的产品的出现似乎是朝着实现有状态功能（同时解决与FaaS限制有关的
一些问题 ）迈出的坚实一步。 我将感兴趣地观察这种新范例在未来几年中将如何发展。
自动化技术
可能是运营工程师社区从这一趋势中受益最大，因为正是他促成了诸如“基础架构即代码”（IaC）之类的概念的实施。 此外，对自动化的热情与“ SRE文化”的发展相吻合，“ SRE文化”的目标是更加面向程序的操作方法。
通用API
在过去的十年中，另一个令人惊奇的特征是各种开发任务的API功能。 良好，灵活的API使开发人员可以创建创新的工作流和工具，进而帮助维护和增加可用性。
此外，API虚构是对某些功能或工具进行SaaS虚构的第一步。 这种趋势还与微服务的日益普及相吻合：SaaS只是您可以使用API使用的另一项服务。 当前，在监视，支付，负载平衡，持续集成，警报，
功能标记 ，CDN，流量工程（例如DNS）等领域，有许多SaaS和FOSS工具，在过去十年中蓬勃发展。
可观察性
值得注意的是，今天我们有
比以前更多的高级工具可用于监视和诊断应用程序行为。 普罗米修斯监控系统在2015年获得了开源的称号，它可能被称为与我合作过的
最佳监控系统。 它不是完美的，但是大量事情是以完全正确的方式实现的（例如，在度量标准的情况下支持
维度 ）。
得益于OpenTracing（及其后继产品OpenTelemetry）等举措，分布式跟踪是另一种在2010年代成为主流的技术。 尽管跟踪仍然很难使用，但是一些最新的进展使我们希望，在2020年代，我们将揭示其真正的潜力。
（请注意perev。：请同时在我们的博客中阅读同一作者的文章“ 分布式跟踪：我们做错了一切 ”。）展望未来
las，在未来十年中，有许多痛点正在等待解决。 这是我对它们的想法，以及有关如何摆脱它们的一些潜在想法。
解决摩尔定律问题
丹纳德定标法的终结和摩尔定律的落后要求新的创新。 约翰·轩尼诗（John Hennessy）在
他的演讲中解释了为何像TPU这样的
领域特定体系结构可以成为解决摩尔定律落后问题的解决方案之一。 像Google的
MLIR这样的工具包似乎已经朝着这个方向迈出了一大步：
编译器应支持新应用程序，轻松移植到新硬件，绑定从动态，受控语言到矢量加速器和程序控制存储设备的许多抽象级别，同时提供用于自动调整的高级开关，并提供即时功能实时地诊断和分发有关整个堆栈中系统功能和性能的调试信息，并且在大多数情况下提供 zvoditelnost足够接近的手写汇编。 我们打算就这样一个编译基础结构的开发和公众可用性分享我们的愿景，进展和计划。
CI / CD
尽管CI的日益普及已成为2010年代的主要趋势之一，但詹金斯仍然是CI的黄金标准。
这个领域在以下领域急需创新：
- 用户界面（用于编码测试规范的DSL）；
- 实施细节，将使其真正地可扩展和快速；
- 与各种环境（阶段，产品等）集成，以实施更高级的测试形式；
- 持续验证和部署。
开发人员工具
作为一个行业，我们开始创建越来越复杂且令人印象深刻的软件。 但是，谈到我们自己的工具，我们可以说情况可能会好得多。
联合和远程（通过ssh）编辑已获得一定的普及，但尚未成为新的标准开发方法。 如果您像我一样，拒绝仅仅为了进行编程就
需要永久性Internet连接的想法，那么在远程计算机上通过ssh进行工作就不太适合您。
本地开发环境，尤其是对于从事大型面向服务的体系结构的工程师而言，仍然是一个问题。 一些项目正在尝试解决它，我很想知道这种用例最符合人体工程学的UX的外观。
将“便携式环境”的概念扩展到其他开发领域，例如在特定条件下或在特定设置下遇到的重现错误（或
易碎测试 ），也将很有趣。
我还希望看到在语义和上下文相关代码搜索，允许您将生产事件与代码库的特定部分相关联的工具等领域的更多创新。
计算（未来的PaaS）
在2010年代对容器和无服务器的普遍宣传中，过去几年中，公共云中的解决方案范围已大大扩展。
在这方面，出现了几个有趣的问题。 首先，公共云中可用选项的列表在不断增长。 云服务提供商拥有人员和资源，可以轻松跟上开源世界的最新发展，并发布无服务器Pod之类的产品（我怀疑只是通过使自己的FaaS运行时与OCI兼容）或其他产品。类似的花哨的东西。
那些使用这些云解决方案的人只会羡慕不已。 从理论上讲，Kubernetes云产品（GKE，EKS，Fargate上的EKS等）提供了独立于云的提供商API来运行工作负载。 如果您使用类似的产品（ECS，Fargate，Google Cloud Run等），则可能会最大限度地利用服务提供商提供的最有趣的功能。 另外，随着新产品或计算范式的出现，迁移可能变得简单而无忧。
鉴于此类解决方案的开发速度有多快（如果在不久的将来不会出现几个新的选择，我感到非常惊讶），小型的“平台”团队（与基础设施相关的团队，负责创建用于启动工作负载的本地平台）在公司中），在功能，易用性和整体可靠性方面很难竞争。 Kubernetes将2010年代标记为用于创建PaaS（平台即服务）的工具，因此基于Kubernetes创建内部平台在公共云空间中提供相同的选择，简单性和自由度似乎毫无意义。 基于容器的PaaS作为Kubernetes策略的概念无异于故意放弃最具创新性的云功能。
如果您看一下
当今可用的计算功能，那么很明显，仅基于Kubernetes创建自己的PaaS等于将自己逼入绝境（不是太有远见的方法，对吗？）。 即使有人决定今天基于Kubernetes创建容器化的PaaS，但与云功能相比，几年后它看起来还是过时的。 尽管Kubernetes最初是作为一个开放源代码项目而存在的，但其祖先和思想启发者却是Google内部的相应工具。 但是，它最初是在2000年代初/中期开发的，当时计算环境完全不同。
此外，从广义上讲，公司不应成为使用Kubernetes集群的专家，也不应创建和维护自己的数据中心。 提供可靠的计算基础是
云服务提供商的主要目标。
最后，我觉得我们在
交互体验 （
UX ）方面已经退缩了一些行业。 Heroku于2007年推出，至今仍是
最易于使用的平台之一。 毫无疑问，Kubernetes具有更强大的功能，可扩展性和可编程性，但是我错过了开始并部署到Heroku的难度。 要使用此平台，只需了解Git。
所有这些使我得出以下结论：对于工作，我们需要更好的更高级别的抽象（对于
最高级别的抽象尤其如此）。
最高级别的正确API
Docker是一个很好的例子，表明需要更好地分离任务以及
正确实现最高级别的API 。
Docker的问题是（至少）该项目的目标设置得过于笼统：使用容器技术解决兼容性问题（“在我的机器上工作”）的一切。 Docker既是映像格式，又是具有自己的虚拟网络的运行时，CLI工具，root守护程序等等。 无论如何，消息传递都
更加令人困惑，更不用说“轻量级VM”，控制组，名称空间，众多安全问题和功能，以及与营销调用“在任何地方创建，交付，运行任何应用程序”混合在一起的功能。
与所有好的抽象一样，将各种问题分解成可以相互组合的逻辑层需要花费时间（以及经验和痛苦）。 las，在Docker达到这种成熟度之前，Kubernetes进入了战斗。 他垄断了炒作周期，以至于现在每个人都试图跟上Kubernetes生态系统的变化，并且容器生态系统获得了次要地位。
Kubernetes在许多方面与Docker共享相同的问题。 尽管讨论了很酷的和可组合的抽象，但是
并没有将
不同的任务分为几层 。 基本上，它是一个容器乐队，可以在不同机器集群中启动容器。 这是一个相当低级的任务，仅适用于操作集群的工程师。 另一方面，Kubernetes也是
最高级别的
抽象，它是用户通过YAML与之交互的CLI工具。
尽管有很多缺点，但Docker仍然是（现在仍然是）
很酷的开发工具。 为了立即跟上所有“麻烦”，其开发人员设法正确实现
了最高级别的
抽象 。
通过最高级别的抽象，我指的是目标受众真正感兴趣的功能的子集 （在这种情况下，大部分时间都花在本地开发环境中的开发人员）并且完美地“即开即用”地工作 。
Dockerfile和docker CLI实用程序应该是构建良好的“顶级用户界面”的示例。 普通开发人员可以在不了解
实现复杂性的情况下开始使用Docker
，这会增加操作经验 ，例如名称空间，控制组，内存和CPU限制等。 最终，编写Dockerfile与编写Shell脚本没有太大不同。
Kubernetes是为各种目标群体设计的：
- 集群管理员
- 涉及基础架构问题，扩展Kubernetes功能并基于该平台创建平台的软件工程师;
- 最终用户通过
kubectl与Kubernetes进行kubectl 。
Kubernetes的“一个适合所有人的API”方法是一种封装不足的“复杂性山”，没有说明如何扩展它。 所有这些导致一条漫长的学习道路。 Adam Jacob表示：“ Docker给用户带来了前所未有的变革性体验。 询问使用K8的任何人是否希望它像第一次docker run一样工作。 答案将是“是”：
我要说的是，当今大多数基础设施技术太底层了（因此被认为“太复杂”）。 Kubernetes的实施水平相当低。
当前形式的分布式跟踪（许多跨度缝合在一起以形成traceview）也实现得太低。 通常，实现“最高级别的抽象”的开发人员工具是最成功的。 该结论在许多情况下都是正确的（如果该技术过于复杂或难以使用，则该技术的“最高级别的API / UI”尚未公开）。
目前，云原生生态系统因其对低级别的关注而感到尴尬。 作为一个行业，我们必须创新，试验和教导正确的“最大，最高抽象”水平。
零售贸易
在2010年代，数字零售体验几乎没有改变。 一方面，在线购物的便利性应该会冲击经典的零售商店，另一方面，在线购物在十年中从根本上没有改变。
尽管我对未来十年该行业的发展没有具体想法，但如果我们在2030年以与2020年相同的方式进行购买，我将感到非常失望。
新闻学
我对世界新闻业的状况越来越失望。 找到客观，细致地广播的公正新闻资源变得越来越困难。 通常，新闻本身和对其看法之间的界限被消除了。 通常，信息是有偏见的。 在某些国家中，在历史上新闻与观点之间始终没有区别的情况下尤其如此。 在英国最近一次大选之后发表的最新文章中，《卫报》的前编辑艾伦·罗斯布里奇
写道 ：
主要思想是，多年来我一直看美国报纸，并对在那里独自负责新闻，对完全不同的人发表评论的同事感到抱歉。 但是，随着时间的流逝，可怜变得令人羡慕。 现在，我认为所有英国国家报纸都应将新闻责任与评论责任区分开。 las，普通读者（尤其是在线读者）很难区分出差异。
考虑到硅谷在道德方面的声誉相当可疑，我决不相信技术会“革新”新闻业。 同时，如果出现公正，公正，可信赖的新闻资源，我（和我的许多朋友）将感到高兴。 尽管我无法想象这样一个平台的外观，但我敢肯定，在一个事实越来越难以辨别的时代，对诚实新闻业的需求比以往任何时候都高。
社交网络
社交网络和集体新闻平台是世界各地许多人的主要信息来源，缺乏准确性和某些平台不愿至少对基本事实进行基本检查会导致种族灭绝，对选举产生干扰等可怕后果。
社交网络也是有史以来功能最强大的媒体工具。 他们从根本上改变了政治惯例。 他们更改了广告。 他们改变了流行文化（例如，社交网络为所谓的取消文化
（ “
种族主义的社交网络
-大约翻译” ）的发展做出了主要贡献。 批评者认为，社交媒体被证明是道德价值观快速而“反复无常”变化的沃土，但他们也为边缘群体的代表提供了团结的机会（他们以前从未有过这样的机会）。 从本质上讲，社交网络已经改变了人们在21世纪的交流方式和表达方式。
但是，我也深信社交网络助长了人类最恶劣的冲动。 为了受欢迎，经常会忽略注意力和体贴，几乎不可能表达出对某些观点和立场的合理反对意见。 两极分化常常会失控，结果，公众根本听不到独立的意见，而专制主义者控制着在线礼仪和可接受性问题。
我问自己，是否有可能创建一个“更好的”平台来帮助提高讨论的质量？ 毕竟，推动“互动”的正是这些平台通常带来的主要收益。 正如Kara Swisher在《纽约时报》上写道：
可以发展数字参与而不会招致仇恨和不容忍。 大多数社交网络之所以如此有毒，是因为创建它们是为了提高速度，病毒性和吸引力，而不是内容和准确性。
如果在几十年之内，社交网络的唯一遗产将是公共话语中的细微差别和充分性的侵蚀，那将真的令人遗憾。
译者的PS
另请参阅我们的博客：