看着我们在纽约的办公大楼，我们发现了一种观察不断变化的云原生领域的完美方式。

在 Packet，我们的工作价值（ 基础设施 infrastructure 自动化）是非常基础的。因此，我们花费大量的时间来研究我们之上所有生态系统中的参与者和趋势 —— 以及之下的极少数！

当你在任何生态系统的汪洋大海中徜徉时，很容易困惑或迷失方向。我知道这是事实，因为当我去年进入 Packet 工作时，从 Bryn Mawr 获得的英语学位，并没有让我完全得到一个 Kubernetes 的认证。:)

由于它超快的演进和巨大的影响，云原生生态系统打破了先例。似乎每眨一次眼睛，之前全新的技术（更不用说所有相关的理念了）就变得有意义……或至少有趣了。和其他许多人一样，我依据无处不在的 CNCF 的 “云原生蓝图” 作为我去了解这个空间的参考标准。尽管如此，如果有一个定义这个生态系统的元素，那它一定是贡献和引领它们的人。

所以，在 12 月份一个很冷的下午，当我们走回办公室时，我们偶然发现了一个给投资人解释“云原生”的创新方式，当我们谈到从 Aporeto 中区分 Cilium 的细微差别时，以及为什么从 CoreDNS 和 Spiffe 到 Digital Rebar 和 Fission 的所有这些都这么有趣时，他的眼里充满了兴趣。

在新世贸中心的影子里向我们位于 13 层的狭窄办公室望去，我们突然想到一个把我们带到那个神奇世界的好主意：为什么不把它画出来呢？（LCTT 译注：“rabbit hole” 有多种含义，此处采用“爱丽丝梦游仙境”中的“兔子洞”含义。）

于是，我们开始了把云原生栈逐层拼接起来的旅程。让我们一起探索它，给你一个“仅限今日有效”的福利。（LCTT 译注：意即云原生领域变化很快，可能本文/本图中所述很快过时。）

查看高清大图（25Mb）或给我们发邮件索取副本。

从最底层开始

当我们开始下笔的时候，我们希望首先亮出的是我们每天都在打交道的那一部分：硬件，但我们知道那对用户却是基本上不可见的。就像任何投资于下一个伟大的（通常是私有的）东西的秘密实验室一样，我们认为地下室是其最好的地点。

从大家公认的像 Intel、AMD 和华为（传言他们雇佣的工程师接近 80000 名）这样的巨头，到像 Mellanox 这样的细分市场参与者，硬件生态系统现在非常火。事实上，随着数十亿美元投入去攻克新的 offload（LCTT 译注：offload 泛指以前由软件及 CPU 来完成的工作，现在通过硬件来完成，以提升速度并降低 CPU 负载的做法）、GPU、定制协处理器，我们可能正在进入硬件的黄金时代。

著名的软件先驱艾伦·凯（Alan Kay）在 25 年前说过：“真正认真对待软件的人应该自己创造硬件”。说得不错，Alan！

云即资本

就像我们的 CEO Zac Smith 多次跟我说的：一切都是钱的事。不仅要制造它，还要消费它！在云中，数十亿美元的投入才能让数据中心出现计算机，这样才能让开发者消费它。换句话说（根本没云，它只是别人的电脑而已）：

我们认为，对于“银行”（即能让云运转起来的借款人或投资人）来说最好的位置就是一楼。因此我们将大堂改造成银行家的咖啡馆，以便为所有的创业者提供幸运之轮。

连通和动力

如果金钱是润滑油，那么消耗大量燃料的引擎就是数据中心供应商和连接它们的网络。我们称他们为“连通”和“动力”。

从像 Equinix 这样处于核心地位的接入商的和像 Vapor.io 这样的接入新贵，到 Verizon、Crown Castle 和其它接入商铺设在地下（或海底）的“管道”，这是我们所有的栈都依赖但很少有人能看到的一部分。

因为我们花费大量的时间去研究数据中心和连通性，需要注意的一件事情是，这一部分的变化非常快，尤其是在 5G 正式商用时，某些负载开始不再那么依赖中心化的基础设施了。

边缘计算即将到来！:-)

嗨，它就是基础设施！

居于“连通”和“动力”之上的这一层，我们爱称为“处理器层”。这是奇迹发生的地方 —— 我们将来自下层的创新和实物投资转变成一个 API 终端的某些东西。

由于这是纽约的一个大楼，我们让在这里的云供应商处于纽约的中心。这就是为什么你会看到（Digital Ocean 系的）鲨鱼 Sammy 和对 “meet me” 房间里面的 Google 标志的致意的原因了。

正如你所见，这个场景是非常写实的。它是由多层机架堆叠起来的。尽管我们爱 EWR1 的设备经理（Michael Pedrazzini），我们努力去尽可能减少这种体力劳动。毕竟布线专业的博士学位是很难拿到的。

供给

再上一层，在基础设施层之上是供给层。这是我们最喜欢的地方之一，它以前被我们称为 配置管理 config management 。但是现在到处都是一开始就是 不可变基础设施 immutable infrastructure 和自动化：Terraform、Ansible、Quay.io 等等类似的东西。你可以看出软件是按它的方式来工作的，对吗？

Kelsey Hightower 最近写道“呆在无聊的基础设施中是一个让人兴奋的时刻”，我不认为这说的是物理部分（虽然我们认为它非常让人兴奋），但是由于软件持续侵入到栈的所有层，那必将是一个疯狂的旅程。

操作系统

供应就绪后，我们来到操作系统层。在这里你可以看到我们打趣一些我们最喜欢的同事：注意上面 Brian Redbeard 那超众的瑜珈姿势。:)

Packet 为客户提供了 11 种主要的操作系统可供选择，包括一些你在图中看到的：Ubuntu、CoreOS、FreeBSD、Suse、和各种 Red Hat 系的发行版。我们看到越来越多的人们在这一层上加入了他们自己的看法：从定制内核和用于不可变部署的 黄金镜像 golden images （LCCT 注：golden image 指定型的镜像或模板，一般是经过一些定制，并做快照和版本控制，由此可拷贝出大量与此镜像一致的开发、测试或部署环境，也有人称作 master image），到像 NixOS 和 LinuxKit 这样的项目。

运行时

为了有趣些，我们将 运行时 runtime 放在了体育馆内，并为 CoreOS 赞助的 rkt 和 Docker 的容器化举行了一次比赛。而无论如何赢家都是 CNCF！

我们认为快速演进的存储生态系统应该是一些可上锁的储物柜。关于存储部分有趣的地方在于许多的新玩家尝试去解决持久性的挑战问题，以及性能和灵活性问题。就像他们说的：存储很简单。

编排

在过去的这一年里，编排层全是 Kubernetes 了，因此我们选取了其中一位著名的布道者（Kelsey Hightower），并在这个古怪的会议场景中给他一个特写。在我们的团队中有一些 Nomad（LCTT 译注：一个管理机器集群并在集群上运行应用程序的工具）的忠实粉丝，并且如果抛开 Docker 和它的工具集的影响，就无从谈起云原生。

虽然负载编排应用程序在我们栈中的地位非常高，我们看到的各种各样的证据表明，这些强大的工具开始去深入到栈中，以帮助用户利用 GPU 和其它特定硬件的优势。请继续关注 —— 我们正处于容器化革命的早期阶段！

平台

这是栈中我们喜欢的层之一，因为每个平台都有如此多的工具帮助用户去完成他们想要做的事情（顺便说一下，不是去运行容器，而是运行应用程序）。从 Rancher 和 Kontena，到 Tectonic 和 Redshift 都是像 Cycle.io 和 Flynn.io 一样是完全不同的方法 —— 我们看到这些项目如何以不同的方式为用户提供服务，总是激动不已。

关键点：这些平台是帮助用户转化云原生生态系统中各种各样的快速变化的部分。很高兴能看到他们各自带来的东西！

安全

当说到安全时，今年真是很忙的一年！我们尝试去展示一些很著名的攻击，并说明随着工作负载变得更加分散和更加可迁移（当然，同时攻击者也变得更加智能），这些各式各样的工具是如何去帮助保护我们的。

我们看到一个用于不可信环境（如 Aporeto）和低级安全（Cilium）的强大动作，以及尝试在网络级别上的像 Tigera 这样的可信方法。不管你的方法如何，记住这一点：安全无止境。:0

应用程序

如何去表示海量的、无限的应用程序生态系统？在这个案例中，很容易：我们在纽约，选我们最喜欢的。;) 从 Postgres “房间里的大象” 和 Timescale 时钟，到鬼鬼祟祟的 ScyllaDB 垃圾桶和那个悠闲的 Travis 哥们 —— 我们把这个片子拼到一起很有趣。

让我们感到很惊奇的一件事情是：很少有人注意到那个复印屁股的家伙。我想现在复印机已经不常见了吧？

可观测性

由于我们的工作负载开始到处移动，规模也越来越大，这里没有一件事情能够像一个非常好用的 Grafana 仪表盘、或方便的 Datadog 代理让人更加欣慰了。由于复杂度的提升，SRE 时代开始越来越多地依赖监控告警和其它智能事件去帮我们感知发生的事件，出现越来越多的自我修复的基础设施和应用程序。

在未来的几个月或几年中，我们将看到什么样的面孔进入这一领域……或许是一些人工智能、区块链、机器学习支撑的仪表盘？:-)

流量管理

人们往往认为互联网“只是能工作而已”，但事实上，我们很惊讶于它居然能如此工作。我的意思是，就这些大规模的、不同的网络间的松散连接 —— 你不是在开玩笑吧？

能够把所有的这些独立的网络拼接到一起的一个原因是流量管理、DNS 和类似的东西。随着规模越来越大，这些让互联网变得更快、更安全、同时更具弹性。我们尤其高兴的是看到像 Fly.io 和 NS1 这样的新贵与优秀的老牌玩家进行竞争，最后的结果是整个生态系统都得以提升。让竞争来的更激烈吧！

用户

如果没有非常棒的用户，技术栈还有什么用呢？确实，他们享受了大量的创新，但在云原生的世界里，他们所做的远不止消费这么简单：他们也创造并贡献了很多。从像 Kubernetes 这样的大量的贡献者到越来越多的（但同样重要）更多方面，而我们都是其中的非常棒的一份子。

在我们屋顶上有许多悠闲的用户，比如 Ticketmaster 和《纽约时报》，而不仅仅是新贵：这些组织拥抱了部署和管理应用程序的方法的变革，并且他们的用户正在享受变革带来的回报。

同样重要的，成熟的监管！

在以前的生态系统中，基金会扮演了一个非常被动的“幕后”角色。而 CNCF 不是！他们的目标（构建一个健壮的云原生生态系统），勇立潮流之先 —— 他们不仅已迎头赶上还一路领先。

从坚实的治理和经过深思熟虑的项目组，到提出像 CNCF 这样的蓝图，CNCF 横跨云 CI、Kubernetes 认证、和讲师团 —— CNCF 已不再是 “仅仅” 受欢迎的 KubeCon + CloudNativeCon 了。

via: https://www.packet.net/blog/splicing-the-cloud-native-stack/

作者：Zoe Allen 选题：lujun9972 译者：qhwdw 校对：wxy, pityonline

本文由 LCTT 原创编译，Linux中国 荣誉推出

诸如容器、边缘计算这样的技术焦点领域大红大紫，对在这一领域能够整合、协作、创新的开发者和系统管理员们的需求在日益增进。

随着全球经济更加靠近数字化未来，每个垂直行业的公司和组织都在紧抓如何进一步在业务与运营上整合与部署技术。虽然 IT 企业在很大程度上遥遥领先，但是他们的经验与教训已经应用在了各行各业。尽管全国失业率为 4.1%，但整个科技专业人员的整体的失业率在 4 月份为 1.9%，开源工作的未来看起来尤其光明。我在开源网络领域工作，并且目睹着创新和机遇正在改变世界交流的方式。

它曾经是个发展缓慢的行业，现在由网络运营商、供应商、系统集成商和开发者所组成的网络生态系统正在采用开源软件，并且正在向商用硬件上运行的虚拟化和软件定义网络上转移。事实上，接近 70% 的全球移动用户由低频网络运营商成员所占据。该网络运营商成员致力于协调构成开放网络栈和相邻技术的项目。

技能需求

这一领域的开发者和系统管理员采用云原生和 DevOps 的方法开发新的使用案例，应对最紧迫的行业挑战。诸如容器、边缘计算等焦点领域大红大紫，并且在这一领域能够整合、协作、创新的开发者和系统管理员们的需求在日益增进。

开源软件与 Linux 使这一切成为可能，根据最近出版的 2018开源软件工作报告，高达 80% 的招聘经理寻找会 Linux 技能的应聘者，而 46% 希望在网络领域招聘人才，可以说“网络技术”在他们的招聘决策中起到了至关重要的作用。

开发人员相当抢手，72% 的招聘经理都在找他们，其次是 DevOps 开发者（59%），工程师（57%）和系统管理员（49%）。报告同时指出，对容器技能需求的惊人的增长符合我们在网络领域所见到的，即云本地虚拟功能（CNF）的创建和持续集成／持续部署方式的激增，就如在 OPNFV 中的 XCI 倡议 一样。

开始吧

对于求职者来说，好消息是有着大量的关于开源软件的内容，包括免费的 Linux 入门课程。好的工作需要有多项证书，因此我鼓励你探索更多领域，去寻求培训的机会。计算机网络方面，在 OPNFV 上查看最新的培训课程或者是 ONAP 项目，也可以选择这门开源网络技术简介课程。

如果你还没有做好这些，下载 2018 开源软件工作报告 以获得更多见解，在广阔的开放源码技术世界中规划你的课程，去寻找另一边等待你的令人兴奋的职业！

点击这里下载完整的开源软件工作报告并且了解更多关于 Linux 的认证。

via: https://www.linux.com/blog/os-jobs-report/2018/7/open-source-networking-jobs-hotbed-innovation-and-opportunities

作者：Brandon Wick 选题：lujun9972 译者：LuuMing 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

随着创新步伐的增加, 长期规划变得越来越困难。让我们重新思考一下我们对变化的反应方式。

几乎每一天，新的技术发展都可能会动摇那些甚至最复杂、最完善的商业计划。组织经常发现自己需要不断努力适应新的环境，这导致了他们对未来规划的转变。

根据 CompTIA 2017 年的研究，目前只有 34% 的公司正在制定超过 12 个月的 IT 架构计划。从长期计划转变的一个原因是：商业环境变化如此之快，以至于几乎不可能进一步规划未来。CIO.com 说道，“如果你的公司正视图制定一项将持续五到十年的计划，那就忘了它。”

我听过来自世界各地无数客户和合作伙伴的类似声明：技术创新正以一种前所未有的速度发生着。

其结果是长期规划已不复存在。如果我们要在这个新世界取得成功，我们需要以不同的方式思考我们运营组织的方式。

计划是怎么死的

正如我在《 开放式组织 The Open Organization 》中写的那样，传统经营组织针对工业经济进行了优化。他们采用等级结构和严格规定的流程，以实现地位竞争优势。要取得成功，他们必须确定他们想要实现的战略地位。然后，他们必须制定并规划实现目标的计划，并以最有效的方式执行这些计划，通过协调活动和推动合规性。

管理层的职责是优化这一过程：计划、规定、执行。包括：让我们想象一个有竞争力的优势地位；让我们来配置组织以最终达成目标；然后让我们通过确保组织的所有方面都遵守规定来推动执行。这就是我所说的“机械管理”，对于不同时期来说它都是一个出色的解决方案。

在当今动荡不定的世界中，我们预测和定义战略位置的能力正在下降，因为变化的速度，新变量的引入速度正在加速。传统的、长期的、战略性规划和执行不像以前那么有效。

如果长期规划变得如此困难，那么规定必要的行为就更具有挑战性。并且衡量对计划的合规性几乎是不可能的。

这一切都极大地影响了人们的工作方式。与过去传统经营组织中的工人不同，他们为自己能够重复行动而感到自豪，几乎没有变化和舒适的确定性 —— 今天的工人在充满模糊性的环境中运作。他们的工作需要更大的创造力、直觉和批判性判断 —— 更多的需要背离过去的“常规”，以适应当今的新情况。

以这种新方式工作对于价值创造变得更加重要。我们的管理系统必须专注于构建结构，系统和流程，以帮助创建积极主动的工人，他们能够以快速和敏捷的方式进行创新和行动。

我们需要提出一个不同的解决方案来优化组织，以适应不同的经济时代，从自下而上而不是自上而下开始。我们需要替换过去的三步骤 —— 计划、规定、执行，以一种更适应当今动荡天气的方法来取得成功 —— 尝试、学习、修改。

尝试、学习、修改

因为环境变化如此之快，而且几乎没有任何预警，并且因为我们需要采取的步骤不再提前计划，我们需要培养鼓励创造性尝试和错误的环境，而不是坚持对五年计划的忠诚。以下是以这种方式开始工作的一些暗示：

• 更短的计划周期（尝试）。 管理者需要考虑的是他们可以快速尝试的短期实验，而不是在长期战略方向上苦恼。他们应该寻求方法来帮助他们的团队承担计算风险，并利用他们掌握的数据来对最有利的路径做出最好的猜测。他们可以通过降低开销和让团队自由快速尝试新方法来做到这一点。
• 更高的失败容忍度（学习）。 更多的实验频率意味着更大的失败机会。与传统组织相比，富有创造力和有弹性的组织对失败的容忍度要高得多。管理者应将失败视为学习的机会，在他们的团队正在运行的测试中收集反馈的时刻。
• 更具适应性的结构（修改）。 能够轻松修改组织结构和战略方向，以及在条件需要时愿意这样做，是确保组织能够根据快速变化的环境条件发展的关键。管理者不能再拘泥于任何想法，因为这个想法证明自己对实现短期目标很有用。

如果长期计划已经消亡，那么就可以进行长期的短期实验。尝试，学习和修改，这是在不确定时期前进的最佳途径。

订阅我们的每周实事通讯以了解有关开源组织的更多信息。

via: https://opensource.com/open-organization/18/3/try-learn-modify

作者：Jim Whitehurst
译者：MjSeven
校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Python 是为谁设计的？

几年前，我在 python-dev 邮件列表中，以及在活跃的 CPython 核心开发人员和认为参与这一过程不是有效利用个人时间和精力的人中强调说，“CPython 的发展太快了也太慢了” 是很多冲突的原因之一。

我一直认为事实确实如此，但这也是一个要点，在这几年中我也花费了很多时间去反思它。在我写那篇文章的时候，我还在波音防务澳大利亚公司（Boeing Defence Australia）工作。下个月，我离开了波音进入红帽亚太（Red Hat Asia-Pacific），并且开始在大企业的开源供应链管理方面取得了 再分发者 redistributor 层面的视角。

Python 的参考解析器使用情况

我尝试将 CPython 的使用情况分解如下，尽管看起来有些过于简化（注意，这些分类的界线并不是很清晰，他们仅关注于考虑新软件特性和版本发布后不同因素的影响）：

• 教育类：教育工作者的主要兴趣在于建模方法的教学和计算操作方面，不会去编写或维护生产级别的软件。例如：

  • 澳大利亚的数字课程
  • Lorena A. Barba 的 AeroPython

• 个人类的自动化和爱好者的项目：主要且经常是一类自写自用的软件。例如：

  • my Digital Blasphemy 图片下载器
  • Paul Fenwick 的 (Inter)National Rick Astley Hotline

• 组织 organisational 过程自动化：主要且经常是为组织利益而编写的。例如：

  • CPython 的核心工作流工具
  • Linux 发行版的开发、构建和发行管理工具

• “ 一劳永逸 Set-and-forget ” 的基础设施：这类软件在其生命周期中几乎不会升级，但在底层平台可能会升级（这种说法有时候有些争议）。例如：

  • 大多数自我管理的企业或机构的基础设施（在那些资金充足的可持续工程计划中，这种情况是让人非常不安的）
  • 拨款资助的软件（当最初的拨款耗尽时，维护通常会终止）
  • 有严格认证要求的软件（如果没有绝对必要的话，从经济性考虑，重新认证比常规升级来说要昂贵很多）
  • 没有自动升级功能的嵌入式软件系统

• 持续升级的基础设施：具有健壮支撑的工程学模型的软件，对于依赖和平台升级通常是例行的，不必关心源码变更。例如：

  • Facebook 的 Python 服务基础设施
  • 滚动发布的 Linux 分发版
  • 大多数的公共 PaaS 无服务器环境（Heroku、OpenShift、AWS Lambda、Google Cloud Functions、Azure Cloud Functions 等等）

• 长周期性升级的标准的操作环境：对其核心组件进行常规升级，但这些升级以年为单位进行，而不是周或月。例如：

  • VFX 平台
  • 长期支持（LTS）的 Linux 分发版
  • CPython 和 Python 标准库
  • 基础设施管理和编排工具（如 OpenStack、Ansible）
  • 硬件控制系统

• 短生命周期的软件：软件仅被使用一次，然后就丢弃或忽略，而不是随后接着升级。例如：

  • 临时 Ad hoc 自动化脚本
  • 被确定为 “终止” 的单用户游戏（你玩了一次后，甚至都忘了去卸载它们，或许在一个新的设备上都不打算再去安装了）
  • 不具备（或不完整）状态保存的单用户游戏（如果你卸载并重安装它们，游戏体验也不会有什么大的变化）
  • 特定事件的应用程序（这些应用程序与特定的事件捆绑，一旦事件结束，这些应用程序就不再有用了）

• 常规用途的应用程序：部署后定期升级的软件。例如：

  • 业务管理软件
  • 个人和专业的生产力应用程序（如 Blender）
  • 开发工具和服务（如 Mercurial、Buildbot、Roundup）
  • 多用户游戏，和其它明显处于持续状态还没有被定义为 “终止” 的游戏
  • 有自动升级功能的嵌入式软件系统

• 共享的抽象层：在一个特定的问题领域中，设计用于让工作更高效的软件组件。即便是你没有亲自掌握该领域的所有错综复杂的东西。例如：

  • 大多数的 运行时 runtime 库和框架都归入这一类（如 Django、Flask、Pyramid、SQL Alchemy、NumPy、SciPy、requests)
  • 适合归入这一类的许多测试和类型推断工具（如 pytest、Hypothesis、vcrpy、behave、mypy）
  • 其它应用程序的插件（如 Blender plugins、OpenStack hardware adapters）
  • 本身就代表了 “Python 世界” 基准的标准库（那是一个难以置信的复杂的世界观）

CPython 主要服务于哪些受众？

从根本上说，CPython 和标准库的主要受众是哪些呢？是那些不管出于什么原因，将有限的标准库和从 PyPI 显式声明安装的第三方库组合起来所提供的服务还不能够满足需求的那些人。

为了更进一步简化上面回顾的不同用法和部署模型，宏观地将最大的 Python 用户群体分开来看，一类是在一些感兴趣的环境中将 Python 作为一种 脚本语言 使用的人；另外一种是将它用作一个 应用程序开发语言 的人，他们最终发布的是一种产品而不是他们的脚本。

把 Python 作为一种脚本语言来使用的开发者的典型特性包括：

• 主要的工作单元是由一个 Python 文件组成的（或 Jupyter notebook)，而不是一个 Python 和元数据文件的目录
• 没有任何形式的单独的构建步骤 —— 是作为一个脚本分发的，类似于分发一个独立的 shell 脚本的方式
• 没有单独的安装步骤（除了下载这个文件到一个合适的位置），因为在目标系统上要求预配置运行时环境
• 没有显式的规定依赖关系，除了最低的 Python 版本，或一个预期的运行环境声明。如果需要一个标准库以外的依赖项，他们会通过一个环境脚本去提供（无论是操作系统、数据分析平台、还是嵌入 Python 运行时的应用程序）
• 没有单独的测试套件，使用 “通过你给定的输入，这个脚本是否给出了你期望的结果?” 这种方式来进行测试
• 如果在执行前需要测试，它将以 试运行 dry run> 和 预览 preview 模式来向用户展示软件将怎样运行
• 如果使用静态代码分析工具，则通过集成到用户的软件开发环境中，而不是为每个脚本单独设置

相比之下，使用 Python 作为一个应用程序开发语言的开发者特征包括：

• 主要的工作单元是由 Python 和元数据文件组成的目录，而不是单个 Python 文件
• 在发布之前有一个单独的构建步骤去预处理应用程序，哪怕是把它的这些文件一起打包进一个 Python sdist、wheel 或 zipapp 中
• 应用程序是否有独立的安装步骤做预处理，取决于它是如何打包的，和支持的目标环境
• 外部的依赖明确存在于项目目录下的一个元数据文件中，要么是直接在项目目录中（如 pyproject.toml、requirements.txt、Pipfile），要么是作为生成的发行包的一部分（如 setup.py、flit.ini）
• 有独立的测试套件，或者作为一个 Python API 的一个单元测试，或者作为功能接口的集成测试，或者是两者都有
• 静态分析工具的使用是在项目级配置的，并作为测试管理的一部分，而不是作为依赖

作为以上分类的一个结果，CPython 和标准库的主要用途是，在相应的 CPython 特性发布后，为教育和 临时 ad hoc 的 Python 脚本环境提供 3-5 年基础维护服务。

对于临时脚本使用的情况，这个 3-5 年的延迟是由于再分发者给用户开发新版本的延迟造成的，以及那些再分发版本的用户们花在修改他们的标准操作环境上的时间。

对于教育环境中的情况是，教育工作者需要一些时间去评估新特性，然后决定是否将它们包含进教学的课程中。

这些相关问题的原因是什么？

这篇文章很大程度上是受 Twitter 上对我的这个评论的讨论的启发，它援引了定义在 PEP 411 中 临时 Provisional API 的情形，作为一个开源项目的例子，对用户发出事实上的邀请，请其作为共同开发者去积极参与设计和开发过程，而不是仅被动使用已准备好的最终设计。

这些回复包括一些在更高级别的库中支持临时 API 的困难程度的一些沮丧性表述，没有这些库做临时状态的传递，因此而被限制为只有临时 API 的最新版本才支持这些相关特性，而不是任何早期版本的迭代。

我的主要回应是，建议开源提供者应该强制实施有限支持，通过这种强制的有限支持可以让个人的维护努力变得可持续。这意味着，如果对临时 API 的老版本提供迭代支持是非常痛苦的，那么，只有在项目开发人员自己需要、或有人为此支付费用时，他们才会去提供支持。这与我的这个观点是类似的，那就是，志愿者提供的项目是否应该免费支持老的、商业性质的、长周期的 Python 版本，这对他们来说是非常麻烦的事，我不认为他们应该这样做，正如我所期望的那样，大多数这样的需求都来自于管理差劲的惯性，而不是真正的需求（真正的需求，应该去支付费用来解决问题）。

而我的第二个回应是去实现这一点，尽管多年来一直在讨论这个问题（比如，在上面链接中最早在 2011 年的一篇的文章中，以及在 Python 3 问答的回复中的这里、这里、和这里，以及去年的这篇文章 Python 包生态系统中也提到了一些)，但我从来没有真实地尝试直接去解释它在标准库设计过程中的影响。

如果没有这些背景，设计过程中的一部分，比如临时 API 的引入，或者是 受启发而不同于它 inspired-by-not-the-same-as 的引入，看起来似乎是完全没有意义的，因为他们看起来似乎是在尝试对 API 进行标准化，而实际上并没有。

适合进入 PyPI 规划的方面有哪些？

任何提交给 python-ideas 或 python-dev 的提案所面临的第一个门槛就是清楚地回答这个问题：“为什么 PyPI 上的模块不够好？”。绝大多数的提案都在这一步失败了，为了通过这一步，这里有几个常见的话题：

• 比起下载一个合适的第三方库，新手一般可能更倾向于从互联网上 “复制粘贴” 错误的指导。（这就是为什么存在 secrets 库的原因：它使得人们很少去使用 random 模块，由于安全敏感的原因，它预期用于游戏和模拟统计）
• 该模块旨在提供一个参考实现，并允许与其它的竞争实现之间提供互操作性，而不是对所有人的所有事物都是必要的。（如 asyncio、wsgiref、unittest、和 logging 都是这种情况）
• 该模块是预期用于标准库的其它部分（如 enum 就是这种情况，像 unittest 一样）
• 该模块是被设计用于支持语言之外的一些语法（如 contextlib、asyncio 和 typing）
• 该模块只是普通的临时的脚本用途（如 pathlib 和 ipaddress）
• 该模块被用于一个教育环境（例如，statistics 模块允许进行交互式地探索统计的概念，尽管你可能根本就不会用它来做完整的统计分析）

只通过了前面的 “PyPI 是不是明显不够好” 的检查，一个模块还不足以确保被纳入标准库中，但它已经足以将问题转变为 “在未来几年中，你所推荐的要包含的库能否对一般的入门级 Python 开发人员的经验有所提升？”

标准库中的 ensurepip 和 venv 模块的引入也明确地告诉再分发者，我们期望的 Python 级别的打包和安装工具在任何平台的特定分发机制中都予以支持。

当添加它们到标准库中时，为什么一些 API 会被修改？

现有的第三方模块有时候会被批量地采用到标准库中，在其它情况下，实际上添加的是吸收了用户对现有 API 体验之后进行重新设计和重新实现的 API，但是会根据另外的设计考虑和已经成为其中一部分的语言实现参考来进行一些删除或细节修改。

例如，与流行的第三方库 path.py、pathlib 的前身不同，它们并没有定义字符串子类，而是以独立的类型替代。作为解决文件互操作性问题的结果，定义了文件系统路径协议，它允许使用文件系统路径的接口去使用更多的对象。

为了在 “IP 地址” 这个概念的教学上提供一个更好的工具，ipaddress 模块设计调整为明确地将主机接口定义与地址和网络的定义区分开（IP 地址被关联到特定的 IP 网络)，而最原始的 ipaddr 模块中，在网络术语的使用方式上不那么严格。

另外的情况是，标准库将综合多种现有的方法的来构建，以及为早已存在的库定义 API 时，还有可能依赖不存在的语法特性。比如，asyncio 和 typing 模块就全部考虑了这些因素，虽然在 PEP 557 中正在考虑将后者所考虑的因素应用到 dataclasses API 上。（它可以被总结为 “像属性一样，但是使用可变注释作为字段声明”）。

这类修改的原理是，这类库不会消失，并且它们的维护者对标准库维护相关的那些限制通常并不感兴趣（特别是相对缓慢的发布节奏）。在这种情况下，在标准库文档的更新版本中使用 “See Also” 链接指向原始模块的做法非常常见，尤其是在第三方版本额外提供了标准库模块中忽略的那些特性时。

为什么一些 API 是以临时的形式被添加的？

虽然 CPython 维护了 API 的弃用策略，但在没有正当理由的情况下，我们通常不会去使用该策略（在其他项目试图与 Python 2.7 保持兼容性时，尤其如此）。

然而在实践中，当添加这种受已有的第三方启发而不是直接精确拷贝第三方设计的新 API 时，所承担的风险要高于一些正常设计决定可能出现问题的风险。

当我们考虑到这种改变的风险比平常要高，我们将相关的 API 标记为临时，表示保守的终端用户要避免完全依赖它们，而共享抽象层的开发者可能希望对他们准备去支持的那个临时 API 的版本考虑实施比平时更严格的限制。

为什么只有一些标准库 API 被升级？

这里简短的回答得到升级的主要 API 有哪些：

• 不太可能有大量的外部因素干扰的附加更新的
• 无论是对临时脚本用例还是对促进将来多个第三方解决方案之间的互操作性，都有明显好处的
• 对这方面感兴趣的人提交了一个可接受的建议的

如果在将模块用于应用程序开发目的时（如 datetime），现有模块的限制主要是显而易见的，如果再分发者通过第三方方案很容易地实现了改进，（如 requests），或者如果标准库的发布节奏与所需要的包之间真的存在冲突，（如 certifi），那么，建议对标准库版本进行改变的因素将显著减少。

从本质上说，这和上面关于 PyPI 问题正好相反：因为从应用程序开发人员体验的角度来说，PyPI 的分发机制通常已经够好了，这种分发方式的改进是有意义的，允许再分发者和平台提供者自行决定将哪些内容作为他们缺省提供的一部分。

假设在 3-5 年时间内，缺省出现了被认为是改变带来的可感知的价值时，才会将这些改变纳入到 CPython 和标准库中。

标准库任何部分都有独立的版本吗？

是的，就像是 ensurepip 使用的捆绑模式（CPython 发行了一个 pip 的最新捆绑版本，而并没有把它放进标准库中），将来可能被应用到其它模块中。

最有可能的第一个候选者是 distutils 构建系统，因为切换到这种模式将允许构建系统在多个发行版本之间保持一致。

这种处理方式的其它可能候选者是 Tcl/Tk 图形套件和 IDLE 编辑器，它们已经被拆分，并且一些开发者将其改为可选安装项。

这些注意事项为什么很重要？

从本质上说，那些积极参与开源开发的人就是那些致力于开源应用程序和共享抽象层的人。

那些写一些临时脚本或为学生设计一些教学习题的人，通常不认为他们是软件开发人员 —— 他们是教师、系统管理员、数据分析人员、金融工程师、流行病学家、物理学家、生物学家、市场研究员、动画师、平面设计师等等。

对于一种语言，当我们全部的担心都是开发人员的经验时，那么我们就可以根据人们所知道的内容、他们使用的工具种类、他们所遵循的开发流程种类、构建和部署他们软件的方法等假定，来做大量的简化。

当应用程序运行时作为脚本引擎广泛流行时，事情会变得更加复杂。做好任何一项工作已经很困难，并且作为单个项目的一部分来平衡两个受众的需求会导致双方经常不理解和不相信。

这篇文章不是为了说明我们在开发 CPython 过程中从来没有做出过不正确的决定 —— 它只是去合理地回应那些对添加到 Python 标准库中的看上去很荒谬的特性的质疑，它将是 “我不是那个特性的预期目标受众的一部分”，而不是 “我对它没有兴趣，因此它对所有人都是毫无用处和没有价值的，添加它纯属骚扰我”。

via: http://www.curiousefficiency.org/posts/2017/10/considering-pythons-target-audience.html

作者：Nick Coghlan 译者：qhwdw 校对：wxy、pityonline

本文由 LCTT 原创编译，Linux中国 荣誉推出

在这个关于混合多云陷阱的系列文章的最后一篇当中，让我们来学习一下如何设计一个低风险的云迁移战略。

在这四篇系列文章中，我们了解到了每个组织在做云迁移的时候所应该避免的陷阱 —— 特别是混合多云的情况下。

在第一部分，我们介绍了一些基本的定义以及我们对于混合云以及多云的观点，确保展示了两者之间的区别。在第二部分，我们会对三个陷阱之一进行讨论：为什么成本并不是迁移到云端的显然的推动因素。而且，在第三部分，我们考察了将所有工作向云端进行迁移的可行性。

最后，在这个第四部分中，我们来看看数据上云要做什么。您应该把数据向云端迁移吗？迁移多少？什么数据可以放在云端？又是什么会造成上云风险很大？

数据…数据…数据

影响您对云端数据的所有决策的关键因素在于确定您的带宽以及存储需求。 Gartner 预计 “数据存储在 2018 年将成为一项$173 亿美元的业务”，并且大部分资金是浪费在一些不必要的存储容量上：“但是只需要优化一下工作负载，全球的所有公司就可以节约 620 亿美元的不必要 IT 成本。”根据 Gartner 的研究，非常令人惊讶的是，全球所有的公司“为云服务器平均支付的费用比他们实际的费用多达 36% 。”

如果你已经阅读了本系列的前三个章节，那么你应该不会为此感到惊讶。然而令人更惊讶的是 Gartner 的结论是 “如果全球的公司将他们的服务器数据直接迁移到云端上，仅仅只有 25% 的公司能够做到省钱。”

等一下……工作负载是可以针对云进行优化的，但是只有一小部分公司能通过将数据向云端迁移而节省资金吗？这个又是什么意思？

如果你去认为云服务商会根据带宽来收取云产生的费用，那么将所有的公司内部数据移至云端很快就会成为他们的成本负担。在以下三种情况，公司才可能会觉得值得把数据放在云端中：

• 单个云包括存储和应用程序
• 应用程序在云端，存储在本地
• 应用程序在云端，而且数据缓存也在云端，存储在本地

在第一种情况下，通过将所有的内容都放在单个云服务商来节省带宽成本，但是这会产生一些（供应商）锁定，这个通常与 CIO 的云战略或者风险防范计划所冲突。

第二种方案是仅仅保留应用程序在云端所收集的数据，并且以最小的方式传输到本地存储。这就需要仔细的考虑策略，其中只有最少使用数据的应用程序部署在云端。

第三种情况就是将数据缓存在云端，应用程序和存储的数据被存储在本地。这也就意味着分析、人工智能、机器学习可以在内部运行而无需把数据向云服务商上传，然后处理之后再返回。缓存的数据仅仅基于应用程序对云的需求，甚至进行跨多云的部署缓存。

要想获得更多信息，请下载红帽案例研究，其中描述了跨混合多云环境下的阿姆斯特丹的史基浦机场的数据以及云和部署策略。

数据危险

大多数公司都认识到了他们的数据是在其市场中的专有优势以及知识能力。因此他们会非常仔细的考虑它在云存储的地点。

想象一下这种情况：如果你是一个零售商，全球十大零售商之一。而且你已经计划了很长一段时间云存储战略，并且考虑使用亚马逊的云服务。但是突然间， 亚马逊收购了全食超市，并且准备进入你的市场。

一夜之间，亚马逊已经增长了 50% 的零售规模，你是否还会去信任把零售数据放到他们的云上？如果您的数据已经就在亚马逊云中，你会打算怎么做？您创建云计划时是否考虑过退出策略？虽然亚马逊可能永远不会去利用您的数据潜在价值 —— 该公司可能甚至有针对此的条款 —— 但你能相信世界上任何人的话吗？

陷阱分享，避免陷阱

分享我们在以前经验中看到的一些陷阱来帮助您的公司规划更安全、更持久的云端策略。了解了成本不是显然的推动因素，并非一切东西都应该在云端，而是你必须在云端有效管理数据才是您成功的关键所在。

via: https://opensource.com/article/18/8/data-risky-cloud

作者：Eric D.Schabell 选题：lujun9972 译者：geekmar 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

台上某疑似“钢铁侠”正在宣讲“AI 监管”，遭到了群嘲——怒极之下，却暴露出了其原本是一个“AI”。

via: http://turnoff.us/geek/ai-regulation

作者：Daniel Stori 译者：wxy 合成：Bestony

本文由 LCTT 原创编译，Linux中国 荣誉推出