感谢这么多的开源开发人员，日常使用 Linux 比以往任何时候都容易得多。

自 2004 年开始从事 IT 工作以来，我一直是 Mac 的忠实粉丝。但是几个月前，由于种种原因，我决定将 Linux 用作日常使用的系统。这不是我第一次尝试完全采用 Linux，但是我发现它比以往更加容易。下面是促使我转换的原因。

我在个人电脑上的首次 Linux 体验

我记得，我抬头看着投影机，而它和我面面相觑。我们俩都不明白为什么它不显示。VGA 线完全接好了，针脚也没有弯折。我按了我所有想到的可能的按键组合，以向我的笔记本电脑发出信号，想让它克服“舞台恐惧症”。

我在大学里运行 Linux 只是作为实验。而我在 IT 部门的经理是多种口味的倡导者，随着我对桌面支持和编写脚本的信心增强，我想了解更多 Linux 的信息。对我来说，IT 比我的计算机科学学位课程有趣得多，课程的感觉是如此抽象和理论化：“二叉树有啥用？”，我如是想 —— 而我们的系统管理员团队的工作却是如此的真真切切。

这个故事的结尾是，我登录到 Windows 工作站完成了我的课堂演讲，这标志着我将 Linux 作为我的日常操作系统的第一次尝试的终结。我很欣赏 Linux 的灵活性，但是它缺乏兼容性。我偶尔会写个脚本，脚本通过 SSH 连接到一个机器中以运行另一个脚本，但是我对 Linux 的日常使用仅止于此。

对 Linux 兼容性的全新印象

几个月前，当我决定再试一次 Linux 时，我曾觉得我遇到更多的兼容性噩梦，但我错了。

安装过程完成后，我立即插入了 USB-C 集线器以了解兼容性到底如何。一切立即工作。连接 HDMI 的超宽显示器作为镜像显示器弹出到我的笔记本电脑屏幕上，我轻松地将其调整为第二台显示器。USB 连接的网络摄像头对我的在家工作方式至关重要，它可以毫无问题地显示视频。甚至自从我使用 Mac 以来就一直插在集线器的 Mac 充电器可以为我的非常不 Mac 的硬件充电。

我的正面体验可能与 USB-C 的一些更新有关，它在 2018 年得到一些所需的关注，因此才能与其他操作系统的体验相媲美。正如 Phoronix 解释的那样：

“USB Type-C 接口为非 USB 信号提供了‘替代模式’扩展，在规范中该替代模式的最大使用场景是支持 DisplayPort。除此之外，另一个替代模式是支持 Thunderbolt 3。DisplayPort 替代模式支持 4K 甚至 8Kx4K 的视频输出，包括多声道音频。

“虽然 USB-C 替代模式和 DisplayPort 已经存在了一段时间，并且在 Windows 上很常见，但是主线 Linux 内核不支持此功能。所幸的是，多亏英特尔，这种情况正在改变。”

而在端口之外，快速浏览一下 笔记本电脑 Linux 的硬件选择，列出了比我 2000 年代初期所经历的更加完整的选择集。

与我第一次尝试采用 Linux 相比，这已经天差地别，这是我张开双臂欢迎的。

突破 Apple 的樊篱

使用 Linux 给我的日常工作流程增加了一些新的麻烦，而我喜欢这种麻烦。

我的 Mac 工作流程是无缝的：早上打开 iPad，写下关于我今天想要做什么的想法，然后开始在 Safari 中阅读一些文章；移到我的 iPhone 上可以继续阅读；然后登录我的 MacBook，这些地方我进行了多年的微调，已经弄清楚了所有这些部分之间的连接方式。键盘快捷键已内置在我的大脑中；用户体验一如既往。简直不要太舒服了。

这种舒适需要付出代价。我基本上忘记了我的环境如何运作的，也无法解答我想解答的问题。我是否自定义了一些 PLIST 文件以获得快捷方式，是不是记得将其签入我的 dotfiles 当中？当 Firefox 的功能更好时，我为何还如此依赖 Safari 和 Chrome？为什么我不使用基于 Android 的手机代替我的 i-系列产品呢？

关于这一点，我经常考虑改用基于 Android 的手机，但是我会失去在所有这些设备之间的连接性以及为这种生态系统设计的一些便利。例如，我将无法在 iPhone 上为 Apple TV 输入搜索内容，也无法与其他用 Apple 的朋友用 AirDrop 共享密码。这些功能是同类设备环境的巨大好处，并且是一项了不起的工程。也就是说，这些便利是被生态系统所困的代价。

我喜欢了解设备的工作方式。我希望能够解释使我的系统变得有趣或容易使用的环境配置，但我也想看看增加一些麻烦对我的观点有什么影响。用 Marcel Proust 的话来说，“真正的发现之旅不在于寻找新的土地，而在于用新的眼光来看待。”技术的使用是如此的方便，以至于我不再对它的工作原理感到好奇，而 Linux 使我有机会再次有了新的眼光。

受你的启发

以上所有内容足以成为探索 Linux 的理由，但我也受到了你的启发。尽管所有操作系统都受到开源社区的欢迎，但 Opensource.com 的作者和读者对 Linux 的喜悦是充满感染力的。它激发了我重新潜入的乐趣，我享受这段旅途的乐趣。

via: https://opensource.com/article/19/10/why-switch-mac-linux

作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy

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

各个公司发现，物联网与最近其他许多流行的企业级计算技术有着良好的合作关系，以支持加密货币而闻名的创新的分布式信任系统的区块链也不例外。然而，在物联网应用中实施区块链可能具有挑战性，并且需要对技术有深入的了解。

区块链是一个跟踪各种交易的分布式账本。链上的每个“块”都包含要防止篡改的交易记录或其他数据，并通过加密散列链接到前一个，这意味着对块的任何篡改都将使该链接无效。节点（几乎可以是其中装有 CPU 的任何节点）通过分布式的对等网络进行通信，以共享数据并确保链中数据的有效性。

北卡罗来纳大学格林波若分校的管理学教授 Nir Kshetri 表示，区块链系统之所以有效，是因为所有的块都必须就它们所保护的数据的细节达成一致。如果有人尝试更改给定节点上先前的事务，则存储在网络上的其余数据会回推回来。“数据的旧记录仍然存在，” Kshetri 说。

这是一项强大的安全技术 —— 如果没有坏人成功控制给定区块链上的所有（LCTT 译注：应为“大部分”）节点（著名的“51％ 攻击”），那么该区块链保护的数据就不会被伪造或以其他方式弄乱。因此，对于在物联网世界某些角落的公司来说，使用区块链是一种有吸引力的选择也就不足为奇了。

物联网安全初创企业 NXMLabs 的首席技术官兼联合创始人 Jay Fallah 认为，除了区块链能够在网络上安全地分发可信信息的能力这一事实之外，部分原因还在于区块链在技术堆栈中的地位。

“区块链站在一个非常有趣的交叉点。在过去的 15 年中，在存储、CPU 等方面，计算技术一直在加速发展，但是直到最近，网络技术并没有发生太大变化。”他说，“ 区块链不是网络技术、不是数据技术，而是二者兼具。”

区块链和物联网

区块链作为物联网世界的部分意义取决于你在和谁交谈以及他们在出售什么，但是最接近的概括可能来自企业区块链供应商 Filament 的首席执行官 Allison Clift-Jenning。

她说：“在任何地方，人们都想互相信任，并且用的是非常古老的方式，这通常是进入场景的好地方。”

直接从 Filament 自己的客户群中挑选出来的一个例子是二手车销售。Filament 与“一家主要的底特律汽车制造商”合作，创建了一个受信任的车辆历史平台，该平台基于一种设备，该设备可插入二手车的诊断端口，从那里获取信息，并将该数据写入区块链。像这样，二手车的历史记录就是不可变的，包括它的安全气囊是否曾经打开过，是否被水淹过等等。任何不道德的二手车或不诚实的前车主都无法更改数据，甚至拔掉设备也将意味着记录中存在可疑的空白期。

SAP 物联网高级副总裁兼全球负责人 Elvira Wallis 表示，当今大多数区块链物联网方案都与信任和数据验证有关。

她说：“我们遇到的大多数用例都在项目的跟踪和溯源领域，”她举例说明了高端食品的农场到餐桌跟踪系统，该系统使用安装在板条箱和卡车上的区块链节点，这样就可以为物品在运输基础设施中创建无懈可击的记录。（例如，该牛排在这样的温度下冷藏了多长时间，今天运输了多长时间，等等。）

将区块链与物联网一起使用是个好主意吗？

不同的供应商针对不同的用例出售不同的基于区块链的产品，这些产品使用不同的区块链技术实现，其中一些与加密货币中所使用的经典的、线性的、挖矿式交易区块链不太一样。

这意味着你目前需要从供应商那里购买特定功能。451 Research 高级分析师 Csilla Zsigri 表示，很少有客户组织拥有可以实施区块链安全系统的内部专家。

她说，区块链技术的任何智能应用的想法都是发挥其优势，为关键信息创建可信赖的平台。

Zsigri 说：“这就是我真正看到增值的地方，只是增加了一层信任和验证。”

专家们一致认为，尽管相当了解基于区块链的物联网应用程序的基本概念，但它并不适用于每个物联网用例。 将区块链应用于非交易系统（尽管有例外，包括 NXM Labs 的用于物联网设备的基于区块链配置的产品）通常不是正确的举动。

如果不需要在两个不同的参与方之间共享数据，而是简单地将数据从传感器移到后端，那么区块链通常就没有意义，因为它实际上并没有为当前大多数物联网实现中的数据分析增加任何关键的增值。

“今天，我们仍处于区块链的早期拨号时代。”Clift-Jennings 说，“它比典型的数据库要慢，它甚至无法读取，也常常没有查询引擎。从本质上讲，你并没有真正获得隐私。”

via: https://www.networkworld.com/article/3386881/why-blockchain-might-be-coming-to-an-iot-implementation-near-you.html

作者：Jon Gold 选题：lujun9972 译者：wxy 校对：wxy

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

两者之间的差异对我们如何构建软件开发过程产生了影响。

制定标准规范和开源软件的开发有许多共同之处：两者都是竞争者可以合作的机制；两者都可以促进互操作性；两者都可用于促进新技术的采用；两者都可用于聚合或协调成熟技术。

一项技术可以同时使用标准和开源：有时一个先于另一个；在其他情况下，它们可以并行进行。它们越来越多地使用类似的工具和流程实践（例如，细粒度版本控制；利用问题跟踪器一起推动某些开发讨论）。

相似程度可能导致过度概括，错误地暗示一切都是可互换的（混合与搭配），在这儿选择一种做法；在那儿将它与一个过程相结合。实际上，获取在一个领域中获得的经验并查看它提供的好处是否可以在其他环境中获得，可能是有价值的。但是，对于某些实践而言，背景更为重要。

虽然有相似之处，但也存在显著差异。在前面的文章《没有规则的治理：复刻潜力如何帮助项目》中，我讨论了在利用 复刻 （ forking ） 潜力作为一种可以促进轻量级治理的力量方面，开源软件开发和标准开发治理能力的不同。另一个不同之处在于专利规则的选择。

如何对待专利

参与者专利权的处理通常在开源软件开发和标准开发中以不同方式排列。这种差异有一个理由。而且，这种差异会对构建开发过程产生影响。

• 开源：在为开源项目做出贡献时授予的专利许可通常由每个贡献者的贡献确定。
• 标准：参与者在标准制定方面做出的专利承诺通常由整个最终规范确定。

开源项目：基于贡献的专利规则

基于贡献的专利规则是什么意思？如果专利所有者提供软件，由于软件添加到项目中，项目软件侵犯了该贡献者拥有的专利，那么贡献者不应该返回来期望获得使用它所贡献的软件的专利许可费。当然，有许多不同的许可文本可以让我们忙于分析每个许可的解释，并讨论情况中的不确定性和细微差别。在另一篇文章中，我在 MIT 许可协议的背景下谈到了这个问题（《为什么 MIT 的专利许可不讨人喜欢？》）。我认为，基本上来说，开源开发中的共同期望就像我上面所描述的那样：当你为开源做出贡献时，你将为你提供的软件提供所有必需的权限，之后你将无法返回来再要求获得使用你所贡献软件的许可费。

标准制定：基于标准规范的专利规则

相比之下，在制定标准时，通常会有更高的期望：参与者应对专利做出承诺，这些专利对整个最终规范至关重要，而不仅仅是对其贡献。这些专利承诺并不取决于确定谁对规范提出了什么想法；对于那些参与开发规范的人来说，他们的承诺是整个标准规范。

包括在其中的专利

确定相关专利的分析在软件和规范之间也有所不同。软件通常包括与相应的标准规范相比不需要的实现细节；在提供软件时，将包括对这些细节使用任何专利的许可。相反，规范开发的专利承诺仅限于对规范“必要”或“必需”的专利。当然，这取决于规范的内容。对于互操作性标准，规范应仅包括实现互操作性所需的详细级别，从而允许实现细节在标准的竞争性实现之间有所不同。对必要专利的承诺不包括实施细节方面的专利，这些专利可用作竞争优势。

专利规则差异的基础

为什么在专利处理方面存在这种差异？鉴于标准和开源软件的开发方式存在差异，这种不同的处理方式很有意义。

更有限的与贡献范围相关的专利符合大多数协作软件开发的渐进式、开放式特性。开源项目经常持续发展，其方向可能会随着时间的推移而演化。虽然可以设置路线图和里程碑并发布快照版本，但这些不太常见，并且比标准项目中常见的范围限制和版本目标具有更少的限制性影响。

可以看出，考虑到标准规范开发结构的差异，标准开发的更高期望值（整个最终规范，不仅仅是贡献）是有意义的。标准规范通常采用具有明确范围的强版本导向演进。规范开发通常适用于特定的快照版本。标准开发活动通常具有一组目标功能（通常在诸如章程之类的文档中表示）。与许多软件开发活动的情况相比，这为可能应用到标准开发活动的技术范围提供了更清晰的公共的进展预期。这种范围的明确性有助于潜在参与者在开始参与时评估参与标准制定项目的专利影响。相比之下，开源软件开发项目更为开放，通常不会排除采用任何特定技术的可能性。

对开源项目和标准管理的影响

这些对待专利的不同措施需要不同的项目管理方法。

开源项目通常准备接受来自新贡献者的补丁。贡献者可能会随着时间的推移而来去。一些贡献者留下来。其他人可能会为该项目来解决一个有限的问题。通过软件贡献，可以更容易地了解谁贡献了什么软件，而不是准确理解谁以一种更抽象的方式“参与”。

另一方面，参与标准制定活动通常具有大量的正式手续。而且，在涉及专利承诺时，这种参与的正式性非常重要。当一个人参与该规范的大部分开发时，对最终规范的专利承诺是有意义的。标准制定过程是否可以从提供单一、有限贡献的人那里获得完整的最终规范承诺？重要的是要有一个过程，以便清楚地了解谁参与谁，谁不参与。需要明确参与者以支持来自实际专利所有者的专利承诺，实际专利所有者通常是由坐在桌旁（比喻，尽管这可能涉及实际的谈判桌）的个人所代表的公司。

如何获得基于规范的承诺？软件标准中典型的免许可费专利承诺最常被作为获得标准组织成员资格或负责规范开发的特定委员会成员资格的条件。为了使这一机制发挥作用，成员资格必须是一个定义明确的概念，以便有一个明确的成员资格决策点（即，用于触发专利承诺的明确行动）和承诺的受益人可以依赖的明确的记录文件。除了参与清晰度之外，为了促进持怀疑态度的专利参与者的参与，项目需要具有明确的范围和明确的开始和结束（明确指出专利承诺将适用的“最终规范”）。这种参与模式与典型的开源项目有很大不同，典型的开源项目可能有一个连续的参与，其范围包括维护几个主要的驱动程序到只提交一个补丁。

专利政策

虽然我所描述的差异通常是这种情况，但某些特定活动遵循不同模式可能有一些原因。例如，考虑作为标准开发活动附带的参考实现的软件。可能有一个强有力的理由期望参与者对完整的最终参考实施提供承诺，而不仅仅是限定于他们对它的贡献。当然，可能存在其他边缘情况；可能存在严格安排的开源开发；可能会有连续的、随心所欲的规范开发。

标准制定的专利政策可分为合理和非歧视（RAND）或免许可费（RF）：基本上来说，实施标准的专利许可费包括需要交（RAND）或不需要交（RF）。制定与软件相关的标准（本文的重点）更多地使用免许可费政策。关于专利许可费预期问题是许可或承诺范围政策之外的另一个维度。

结论

标准的制定和开源软件的开发通常具有不同的参与者专利期望范围（仅限于贡献或整个最终可交付成果）。这些不同的选择基于通常如何进行开发的显著差异，而不是任意差异。

作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

在当今的专业 IT 媒体中有一个非常突出的话题，那就是在软件生命周期中的“第 0 天/第 1 天/第 2 天”。在演讲和会议讲话当中，通常着重于使软件开发过程有效且易于管理，为此，有必要明确定义所使用的概念。通常，如果直观地理解基本术语“ 第 0 天 （ Day 0 ） / 第 1 天 （ Day 1 ） / 第 2 天 （ Day 2 ） ”，这在谈论软件生命周期时可能会引起一些歧义。因此，我决定更准确地定义它们，以展示软件开发的整个过程以及它们在实际项目中的使用方式。这篇简短的博客文章提供了“天”的定义，这些“天”被理解为软件生命周期的各个阶段。它还描述了云如何改变了有关软件开发和维护过程的传统思维方式。毕竟，正如《RightScale 2019 云状态报告》所确认的那样，我们正处于“云时代”。该报告解释说，有 94％ 的调查受访者正在使用云（私有云或公有云）。因此，闲话少说，让我们探讨一下“天”和云如何结合在一起。

“天”究竟是什么？

在 IT 中，术语“第 0 天/第 1 天/第 2 天”指的是软件生命周期的不同阶段。用军事术语来说，“第 0 天”是训练的第一天，新兵进入训练阶段。在软件开发中，它代表设计阶段，在此阶段中指定项目需求并确定解决方案的体系结构。

“第 1 天”涉及开发和部署在“第 0 天”阶段设计的软件。在此阶段，我们不仅创建应用程序本身，还创建应用程序的基础设施、网络、外部服务，并实现所有部分的初始配置。

“第 2 天”是产品出厂或交付给客户的时间。在这里，大部分工作都集中在维护、监控和优化系统上。分析系统的行为并做出正确的反应至关重要，因为所产生的反馈循环将一直持续到应用程序生命周期结束为止。

在云时代之前的日子里，这些阶段是分别处理的，彼此之间没有重叠。今天，情况已不再如此。让我们看一下所有这些如何应用于现代应用程序的生命周期。

第 0 天：无聊但必不可少

第 0 天经常被忽略，因为它可能很无聊，但这并不会降低其重要性。成功的软件产品是经过全面规划和设计过程的结果。必须仔细计划系统或应用程序的体系结构以及启动和运行所需的资源（CPU、存储空间、RAM）。其次，你应该定义可衡量的里程碑，以实现项目目标。每个里程碑应有一个准确的日期。这有助于衡量项目的进度，并确定你是否延迟了计划运行。所有项目时间估算都应基于概率，而不仅仅是按最佳情况预估。进行计划时，最好添加缓冲余量，因为意外事件甚至可能使精心策划的计划陷入困境。测试阶段也起着重要的作用，也应该包括在初始项目计划中。这些是基本要求，它们在“云时代”中同以往一样重要。

尽管如此，在计算资源的第 0 天计划中，云还是改变了两件事。由于云可以在项目的任何地方获得不同的资源或新资源（CPU、存储空间、RAM），因此比本地基础设施要容易得多。因此，可以避免在计划阶段犯下的一些错误。另一方面，在计划阶段对特定云供应商的承诺可能会在以后导致供应商锁定。这可能会花费你的金钱，并且需要时间来进行更改，因此选择云供应商时要明智一些。

其次，正如我们当前在向云的迁移中观察到的那样，与运维相关的工作依旧保持不变，但不再专注于基础设施。现在，正是软件在推动着自动化和价值。

第 1 天：实现创意的阶段

对于开发人员和项目负责人而言，第 1 天绝对是最有趣的阶段。最初的设计得以实现，并根据项目的规范创建了基础设施。为了成为真正的云原生，必须遵守最佳实践。可以遵循诸如 十二要素应用程序方法 （ Twelve-Factor Apps methodology ） 之类的准则。此外，使用云端意味着你应该遵循重要的 DevOps 惯例：持续集成/持续交付（如果你想了解有关 CI/CD 的更多信息，请参阅我们的博客文章）。

云为我们带来了从传统方法到软件开发的重要变化：将第一行代码拼凑在一起以进行概念验证后，应用程序即开始运行。你可以从持续集成实践开始，以测试你的应用程序的健全性，但是你很快会让企业迈入到持续交付。在开发应用程序时，我们开始引入一些运维元素，尤其是在使用多个环境的情况下。注意这些运维要素将使维护团队在维护阶段（第 2 天）的工作更加轻松。

在第 1 天期间可以使用几种工具。可以将它们按解决的问题分组。这个列表的顶部应提及“ 基础设施即代码 （ Infrastructure-as-a-code ） ”（IaaC）。 IaaC 就像应用程序或代码一样管理运维环境。这种方法允许将 DevOps 最佳实践（包括版本控制、虚拟化测试和持续监视）应用于驱动基础设施的代码。这里有很多工具可供我们使用，例如 Terraform、Ansible 或 Puppet 等。第二类工具与容器的自动化部署和管理的容器编排系统有关。Kubernetes 及其实现（例如 Google Kubernetes Engine 和亚马逊的 Elastic Kubernetes Service）至关重要。最后，还有诸如 Jenkins、Zuul 和 CircleCI 之类的 CI/CD 系统，可帮助工程师自动化软件的构建、测试以及交付或部署。

第 2 天：日常运维环节

一旦软件准备就绪，它就会上线，客户开始使用它。第 2 天始于此，并引入了包括软件维护和客户支持在内的各个元素。该软件本身将不断发展，以适应不断变化的需求和客户需求。在第 2 天期间，主要重点是建立反馈循环。我们监控该应用程序的工作方式，收集用户反馈并将其发送给开发团队，该团队将在产品中实施该应用程序并发布新版本。军事术语“ 观察-导向-决定-行动 （ Observe-Orient-Decide-Act ） ”（OODA）恰当地抓住了这一阶段发生的事情。

• 观察：从监视系统获取信息（资源使用情况和指标，应用程序性能监控）。
• 导向：执行问题的根本原因分析。
• 决定：找到解决问题的方法。
• 行动：实施解决方案。

与战斗中一样，该循环不断重复。

监控程序基于 服务水平协议 （ Service Level Agreement ） （SLA）中定义的要求。 SLA 基于 服务水平目标 （ Service Level Objectives ） （SLO），代表我们的 服务水平指标 （ Service Level Indicators ） （SLI）的状态。自动化和监控是解决第 2 天职责的关键。

有几种工具可帮助完成第 2 天的工作。 应用程序性能监控 （ Application Performance Monitoring ） （APM）类软件可以帮助 IT 管理员监控应用程序性能，从而提供高质量的用户体验。在这里，我们可以点名 Datadog、Dynatrace、SignalFX 或 Nutanix Xi Epoch。 还有一些自动化和编排工具，例如 Ansible 或 Kubernetes，可帮助管理应用程序环境。你可能已经注意到，这些工具的应用与第 1 天的工作重叠。最后，工单系统（例如 Servicedesk 或 Zendesk）可以处理客户服务，使用户可以报告故障以及与他们正在运行的应用程序有关的问题。

云将改变游戏规则

在前云时代，这些阶段之间的分隔清晰可见，但是今天，随着云的日常运行，事物在不断变化。使用云和现代软件开发实践，可以更轻松地处理软件生命周期中不断变化的要求。持续集成/持续开发方法使我们能够动态响应客户反馈并实时改进应用程序，而无需等待主要版本进行改进。

基于云和原生云的软件中的 DevOps 实践有助于实现 向左移动 （ shift left ） （LCTT 译注：环节前置的意思），这意味着传统上一直保留到最后的步骤现在可以更快地执行。除此以外，这导致第 1 天和第 2 天现在相互重叠。此外，传统软件开发的最大痛点在于从第 1 天到第 2 天的过渡：从开发人员到运维人员的过渡。现在，DevOps 展示了如何解决此问题：及早启动流程，并使流程一直运行到应用程序生命周期结束。最后但同样重要的是，工具链正在完善，这使得执行第 1 天的任务和适应第 2 天的更改成为可能。 可以根据我们的需求对所使用的工具进行建模，并且过程中涉及的每个人都可以使用同一套工具。

不仅可以部署简单的应用程序，还可以用 Kubernetes 运维器应对第 2 天运营。

在我的第一篇文章 为什么说 Kubernetes 是一辆翻斗车 中，我谈到了 Kubernetes 如何在定义、分享和运行应用程序方面很出色，类似于翻斗车在移动垃圾方面很出色。在第二篇中，如何跨越 Kubernetes 学习曲线，我解释了 Kubernetes 的学习曲线实际上与运行任何生产环境中的应用程序的学习曲线相同，这确实比学习所有传统组件要容易（如负载均衡器、路由器、防火墙、交换机、集群软件、集群文件系统等）。这是 DevOps，是开发人员和运维人员之间的合作，用于指定事物在生产环境中的运行方式，这意味着双方都需要学习。在第三篇 Kubernetes 基础：首先学习如何使用 中，我重新设计了 Kubernetes 的学习框架，重点是驾驶翻斗车而不是制造或装备翻斗车。在第四篇文章 帮助你驾驭 Kubernetes 的 4 个工具 中，我分享了我喜爱的工具，这些工具可帮助你在 Kubernetes 中构建应用程序（驾驶翻斗车）。

在这最后一篇文章中，我会分享我为什么对在 Kubernetes 上运行应用程序的未来如此兴奋的原因。

从一开始，Kubernetes 就能够很好地运行基于 Web 的工作负载（容器化的）。Web 服务器、Java 和相关的应用程序服务器（PHP、Python等）之类的工作负载都可以正常工作。该平台处理诸如 DNS、负载平衡和 SSH（由 kubectl exec 取代）之类的支持服务。在我的职业生涯的大部分时间里，这些都是我在生产环境中运行的工作负载，因此，我立即意识到，除了 DevOps 之外，除了敏捷之外，使用 Kubernetes 运行生产环境工作负载的强大功能。即使是我们几乎不改变我们的文化习惯，也可以提高效率。调试和退役变得非常容易，而这对于传统 IT 来说是极为困难的。因此，从早期开始，Kubernetes 就用一种单一的配置语言（Kube YAML/Json）为我提供了对生产环境工作负载进行建模所需的所有基本原语。

但是，如果你需要运行具有复制功能的多主 MySQL，会发生什么情况？使用 Galera 的冗余数据呢？你如何进行快照和备份？那么像 SAP 这样复杂的工作呢？使用 Kubernetes，简单的应用程序（Web 服务器等）的第 0 天（部署）相当简单，但是没有解决第 2 天的运营和工作负载。这并不是说，具有复杂工作负载的第 2 天运营要比传统 IT 难解决，而是使用 Kubernetes 并没有使它们变得更容易。每个用户都要设计自己的天才想法来解决这些问题，这基本上是当今的现状。在过去的五年中，我遇到的第一类问题是复杂工作负载的第 2 天操作。（LCTT 译注：在软件生命周期中，第 0 天是指软件的设计阶段；第 1 天是指软件的开发和部署阶段；第 2 天是指生产环境中的软件运维阶段。）

值得庆幸的是，随着 Kubernetes 运维器 Operator 的出现，这种情况正在改变。随着运维器的出现，我们现在有了一个框架，可以将第 2 天的运维知识汇总到平台中。现在，我们可以应用我在 Kubernetes 基础：首先学习如何使用 中描述的相同的定义状态、实际状态的方法，现在我们可以定义、自动化和维护各种各样的系统管理任务。

（LCTT 译注： Operator 是 Kubernetes 中的一种可以完成运维工程师的特定工作的组件，业界大多没有翻译这个名词，此处仿运维工程师例首倡翻译为“运维器”。）

我经常将运维器称为“系统管理机器人”，因为它们实质上是在第 2 天的工作中整理出一堆运维知识，该知识涉及 主题专家 Subject Matter Expert （SME、例如数据库管理员或系统管理员）针对的工作负载类型（数据库、Web 服务器等），通常会记录在 Wiki 中的某个地方。这些知识放在 Wiki 中的问题是，为了将该知识应用于解决问题，我们需要：

1. 生成事件，通常监控系统会发现故障，然后我们创建故障单
2. SME 人员必须对此问题进行调查，即使这是我们之前见过几百万次的问题
3. SME 人员必须执行该知识（执行备份/还原、配置 Galera 或事务复制等）

通过运维器，所有这些 SME 知识都可以嵌入到单独的容器镜像中，该镜像在有实际工作负荷之前就已部署。 我们部署运维器容器，然后运维器部署和管理一个或多个工作负载实例。然后，我们使用“运维器生命周期管理器”（Katacoda 教程）之类的方法来管理运维器。

因此，随着我们进一步使用 Kubernetes，我们不仅简化了应用程序的部署，而且简化了整个生命周期的管理。运维器还为我们提供了工具，可以管理具有深层配置要求（群集、复制、修复、备份/还原）的非常复杂的有状态应用程序。而且，最好的地方是，构建容器的人员可能是做第 2 天运维的主题专家，因此现在他们可以将这些知识嵌入到操作环境中。

本系列的总结

Kubernetes 的未来是光明的，就像之前的虚拟化一样，工作负载的扩展是不可避免的。学习如何驾驭 Kubernetes 可能是开发人员或系统管理员可以对自己的职业发展做出的最大投资。随着工作负载的增多，职业机会也将增加。因此，这是驾驶一辆令人惊叹的 在移动垃圾时非常优雅的翻斗车……

你可能想在 Twitter 上关注我，我在 @fatherlinux 上分享有关此主题的很多内容。

via: https://opensource.com/article/19/6/kubernetes-potential-run-anything

作者：Scott McCarty 选题：lujun9972 译者：wxy 校对：wxy

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

在云原生技术实践峰会召开前夕，匆匆奔赴北京的我，见到了刚刚从美国飞回来，却毫无时差之扰的陈恺——灵雀云的 CTO。

虽然我早就和灵雀云有了联系，也有好几位朋友在灵雀云任职，不过作为国内新锐云原生厂商灵雀云的创始人之一的陈恺，我之前并没有直接接触过。虽然我们是初次相识，但是在聊到了开源，聊到云技术，我们以云做老酒，以开源为佐酒菜，很快就俨然如同老友般进入了旁若无人的状态——旁边的朋友被我们暂时性忽视了，虽然这张合影就是她帮我们照的。 :D

滥觞始于云计算。

缘起

陈恺和左玥等人在创立灵雀云之前，他们都曾在微软 Azure 从事云计算领域的专业研究。回忆起那时候，陈恺说，那时他们也在想象云里面的应用应该长什么样子，设计最早版本的“云服务模型”、“云服务运行时”，而现在回过头看，其实云计算的发展已经千差万别。

2013 年 Docker 出现以后，左玥和陈恺他们第一时间就意识到容器技术会很有影响力，它重新了定义云技术之后发展的路径，这恍然在他们面前掀开了一个新的时代，于是灵雀云诞生了。

云技术领域发展演变的非常快，事实上，在云计算早期并不能预见到如今的云计算格局。“早期我们尝试过很多东西，总的想法是觉得容器就像是一种轻量级虚拟机，一种新的虚拟化技术。就像虚拟机需要虚拟机平台去作为它的管理平台一样，容器也需要一个容器云平台，所以我们早期想做的就是容器云平台，这一点一直没变，现在也是在做企业级的容器平台。”陈恺说，“我们最早的技术选型是 Mesos 技术栈，经历了几次大的改变，包括从 Mesos 转到支持当时的三种主流的调度系统，然后开始倾向于Kubernetes，到最后全面转向 Kubernetes，以及最近在架构上和 Kubernetes全面对齐，把我们的平台做成一个 Kubernetes 原生的平台，技术上一直在做升级。”

云原生吞噬一切，Kubernetes 编排一切

不知不觉之间，云原生已经吞噬了整个世界，如今，云原生已经是技术界最时髦的词汇之一。而应运而生并推动了这一切发生的云原生计算基金会（CNCF）也在不同的时期、不同的场所，对云原生做了不同角度的解读。那么作为一家很早就涉入云计算领域的新锐力量，陈恺对云原生的理解是什么呢？

陈恺说，“CNCF 旗下涵盖这么多云计算的技术、产品和服务，所以它对‘云原生’的定义必然会比较宽泛，但的确，‘云原生’不是一个特定的技术或者一种方法，很难把它精确的定义，也不应该把它和具体的技术对等，比如说把它直接跟 Kubernetes 挂钩，跟 Kubernetes 没关系就不是云原生？跟 Kubernetes 有关系就叫云原生？这两者都是不对的。”

他接着补充说，“我对云原生定义的观点也是比较宽泛的，（云原生）就是让应用能够最大化的释放云计算生产力的一系列的思维方式、最佳实践和技术体系，这里的关键词是让应用去释放云计算最大的生产力。这是关键。所有的云原生我觉得都是首先应该围绕应用的。什么叫‘云原生’？主要是以应用为中心的。‘原生’这个名字看起来起的不是很好，听上去似乎是只有在云上生出来的才叫‘云原生’，或者只有在公有云上才叫‘云原生’，并不是。关键不是说你在哪里跑你的应用，而是你是不是能够释放云的生产力——广义的云的生产力。”

在容器编排市场尚三分天下的时候，很多容器服务商都同时支持三种主流的编排系统，当时有一些观点认为这种三分格局会持续比较久，然而 Kubernetes 迅速崛起，很快就一家独大地统治了容器编排市场。

陈恺说，“我觉得当时 Kubernetes 可以很快的从编排之争当中胜出，并没有那么让人吃惊。为什么我们比较早的时候就开始往 Kubernetes 发力？其实第一个触发的点比较偶然。那时经常会有人问起三种容器编排系统各自的优势是什么？我们做了一些研究，业界有一些对比，当时我印象比较深的是一个细节，我觉得这才是关键——有一项对比的是基于这三种技术有哪些商业版？基于 Docker Swarm 的有一个商业版 Docker EE；Mesos 有一个商业版 MesosPhere；基于 Kubernetes 有好多商业版——这是本质的区别。这一点对它们的社区的发展速度和后续影响很广，因为它是开放式的治理。Kubernetes 虽然是谷歌发明的，但是它是开放式治理，背后有很多商业版。如果从开源软件本身社区发展角度看，很关键一点是上面有多少商业版，商业版越多说明从开源软件里面可以获利的公司越多，这样就有了正向的良性循环，会有更多资源投进来，社区里面参与的人就会更多，最后的发展会更好，生态会很繁荣。当时从这一点我们就觉得这个生态肯定会赢。”

Kubernetes 一统容器编排市场的今天，业界一些专家对此有所忧虑，担心这种垄断会形成市场压制。从长期来看，如果 Kubernetes 的发展会形成类似 Android 一样的巨头化，那么作为下游厂商，灵雀云是如何看待和应对这种发展变化的呢？

陈恺说，“回到垄断这个问题，如果是商业软件的话会有垄断这个问题，如果是开源软件的话，它的治理模式有可能是封闭式的，也有可能是开放式的，而 Kubernetes 是一个开放式的治理模式，会有一些厂商有更大的影响力，但不是被一家完全控制，所以我觉得从这个角度来说，谈不上垄断，更多的是一个标准。它可能更多像 Linux 而不像是 Android。从标准的角度来说，肯定是利大于弊，而且是远大于弊。因为有了标准，大家都围绕着标准做投入，风险就大大降低，可以放心去投入，也就会有越来越多的技术厂商会向它靠拢。”

灵雀云的 Kubernetes 生态

灵雀云在围绕 Kubernetes 生态方面也做了自己的发行版，他们是如何在符合 Kubernetes 标准的基础上形成差异化的服务和产品的呢？

“Kubernetes 发行版首先必须是跟 Kubernetes 兼容的。在 Kubernetes 上可以增加各种各样的能力，但它本身的第一属性一定是一个真正的 Kubernetes。如果为了做差异性，把它做得不像 Kubernetes，不兼容会是个很大的问题。”陈恺说，“我们走的比这个更深一步，我们的 ACP 2.0 是把整个平台都做成 Kubernetes 原生的，因为 Kubernetes 本质上是声明式 API 加上基于控制器模型的架构设计范式，容器编排相当于它的一个副产品，是它基于这个架构的一种应用，当然也可以把这种架构应用到对任意资源的编排。前一段时间有一篇很多人转发的《Kubernetes 编排一切》的文章，讲的就是这个事情，它不光可以用来编排容器，可以做各种各样的事情。我很赞同这个观点。”

灵雀云是从 2017 年底的时候决定这样做的，当时的做法是一些新的产品开始在新的架构上做一些实践，比如 DevOps 平台、基于 Istio 的 Service Mesh 等产品，完全基于新的架构来做。今年年初，灵雀云认为所有方面都成熟了：第一，方向肯定没问题，Kubernetes 编排一切；第二，对如何基于 Kubernetes 的架构构建上层产品有了更多的经验和体会。灵雀云于是把以前产品上的所有功能都逐渐迁移到 Kubernetes 原生架构上，重新融合到统一的架构里面，这就是 ACP 2.0。在此之上灵雀云还做了一些差异化。

灵雀云在这里的技术栈分为三层：

最底层的产品是一个 Kubernetes 发行版，Kubernetes 是一个开源的技术，并不是一个平台，大多数企业做不到直接把它当一个平台用。灵雀云的做法是将 Kubernetes 技术变成一个企业就绪的 Kubernetes 发行版。

再往上是 ACP 层，定位是云原生应用赋能平台。包含有三个子产品：容器平台、DevOps 平台和基于 Istio 的 Service Mesh 产品。容器平台和发行版最接近，但对发行版进行了大量扩展，比如在发行版之上增加了多集群管理和企业级多租户。ACP 把单一的 Kubernetes 集群变成企业平台级的产品，经过了三年多 100+ 企业客户生产环境的考验，而且考虑到更多开发者的场景。DevOps 也基于 Kubernetes 原生，用 Kubernetes 去编排所有的工具，定位是一个开放式 DevOps 工具链集成和编排的平台。

在此之上还有一层是灵雀云新的 ACE 3.0，它的定位是一个企业级的 PaaS 平台，或者用现在更时髦的说法，可以称之为企业技术中台，集成了更多企业需要的其他服务，比如第三方的中间件、开发框架等。它是个完整的技术中台，以容器平台为底座，以云原生黄金三角为核心，其他服务在上面做成一个个插件。这部分主要是和生态合作伙伴合作，国内外的一些最优秀的 PaaS 类服务都可以放在里面，为企业提供完整的解决方案。

云原生之于微服务和 DevOps

我们知道微服务、DevOps 等模式在云原生概念发展起来之前就已经存在，但是随着云原生的发展，似乎给它们注入了更多的活力。

陈恺认为云原生显著地推动了 DevOps、微服务的发展，对于这一现象他还专门用了一个词汇来形容：后 Kubernetes。这是在容器和 Kubernetes 出现之后开始对 DevOps 侧的微服务反过来的助推。

他认为，微服务架构的本质是用运维复杂度为代价去换取敏捷性。企业至少要考虑两件事：第一是否真的有这么高的敏捷性需求，值得用那么大的运维代价去替换，第二，假设你有着敏捷性需求，那么多出来的复杂度怎么办？早期微服务落地会很痛苦，因为大家没有准备好怎么去应付这个复杂度，而且会低估它。这复杂度是未知的，用未知的复杂度去替代已知的复杂度，这通常都是不好的，所以才会有各种各样的治理框架出来。其实它需要底下有一个好的基础设施来支撑它。

容器和微服务天生一对，容器 Kubernetes 的出现，对微服务有非常明显地推动。Kubernetes 作为底层的应用管理平台非常合适，而且很多微服务里面要考虑的与业务无关的能力也可以慢慢推到 Kubernetes 里面去。而进一步，Service Mesh 等其上的技术栈就重新定义了微服务技术栈，微服务治理方式发生了变化，反过来作用到微服务上，形成了新的最佳实践。

因此，要做微服务应该先容器化，才能解决运维复杂度的问题，容器化的服务应该跑在 Kubernetes 之上；如果进一步做服务治理，应该往 Service Mesh 方向走，Service Mesh 是基于 Kubernetes 平台的微服务治理的最佳实践。

云原生之于 DevOps 也是如此。早期大家很多的精力在持续集成上面，比如 Jenkins 最初是作为 CI 工具出现的，而有了容器和 Kubernetes 之后，持续集成变得简化了，最终生成 Docker 镜像就好。重心开始转到部署，转到 CD 上。而且，现在的 DevOps 实践或 CI/CD 通常会把 Kubernetes 作为最重要的部署目标。也就是说CI会围绕容器镜像，CD 会围绕 Kubernetes。这是容器和 Kubernetes 带给 DevOps 的影响，基础设施越强大，对 DevOps、微服务就越有帮助。以 Kubernetes 为核心的基础设施变成新的标准，DevOps 和微服务的一些最佳实践都会围绕它去改变。

源于开源，茁壮于开源

云计算构筑在开源之上，灵雀云的基础设施和服务也构建在开源之上，那么灵雀云是如何拥抱开源和贡献开源的？

陈恺说，“有几个开源社区跟我们是非常相关的，最早的时候是 Docker 社区，现在 Kubernetes 则是跟我们关系最大的开源社区。我们核心的产品是容器、DevOps 和微服务三部分。Jenkins、Istio 等相关开源项目是我们的重点，我们非常重视在开源社区的投入。我们的许多工程师会参与其中，对社区进行贡献，也会开源一些项目，我们在一步一步持续地做这件事情。我们首先会选择一些偏底层的技术或者机制，选择那些有足够亮点，真的被需要的项目和技术开源出来。”

目前灵雀云已经开源了的项目，包括基于 OVN 的网络插件 Kube-OVN，它是把 OVN 的网络和 Kubernetes 所集成的网络插件。现在该项目在国内外都受到关注，也有来自外部贡献者参与。另外一个开源的项目叫 Captain，是一个基于 Helm v3 标准的 Kubernetes 控制器，对 Helm 应用分发进行改进。

后续灵雀云还计划将更完整的东西放出来，比如灵雀云的 Kubernetes 发行版，供社区用户用来管理自己的 Kubernetes 平台，可以达到和使用灵雀云产品接近的体验。另外灵雀云也计划将其 ACP 释放社区版或者开源版本出来。陈恺说，“我们很乐意把它开源出来，因为这是一个标准的产品，我们让它较早期的接触更多用户，也能得到更多反馈，甚至吸收一些外部的贡献者参与进来。”

尾声

我采访过很多技术领袖和技术专家，不过陈恺的这场采访让我有一点不同的感受。一场对话下来，陈恺给我的感觉如同多年的老友一样言无不尽，而他对于我提到的每个话题，都非常认真、仔细的做了阐述，让人感到浓浓的专业技术风格。我想，这就是陈恺的技术初心，也是灵雀云一直以来的风格吧。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。