基于CNCF的定义来解释什么Cloud Native？

根据云原生计算基金会（CNCF）对Cloud Native战略的定义，它是关于规模和弹性的：“分布式系统应该具备有扩展到成千上万台节点的能力，并且这些节点具有多租户和自愈能力。（https://www.cncf.io/about/charter/）”这对于像Uber和Netflix这样的公司，他们把产品运行在一个超大规模部署的环境中是非常有用的，因为这可以帮助他们可以减少运营成本，增加利润。那么Cloud Native是关于能量和规模的吗？

对于有些公司来说，他们想要云提供的东西完全不同：比如速度。对于这些公司来说，Cloud Native 可以把一个新产品或者服务更快速的推向于市场。一个初创公司或者一个企业他们想要更快速的发展，他们用Cloud Native架构是为了更快速的创新。那么Cloud Native是关于速度的？

所以，什么才是Cloud Native呢？是一种更快捷的方式？还是一种能够降低投资和运营成本的方法？或者是其他什么？如何用一种手段实现这些不同的目标呢？

在这篇介绍Cloud Native的文章中，我们将探讨它的多重含义，以及如何绕开那些废话（waffle）去为我们的需求表述正确的Cloud Native战略。我们将讨论所有这些目标（快速更新，可扩展性和降低成本）是可以实现的，但他们需要仔细思考。Cloud Native有巨大的潜力，但它同时也存在风险。

速度：各种规模的公司现在都看到了快速行动，把想法变成产品并快速的投放到市场所带来的好处。根据这个定义，我们把想法付之于实现的周期从数月到数天，甚至是数小时。这个实现的一部分是商业文化的转变，把过于庞大的项目变成持续的改进。另一部分是关于管理的风险。最好的做法是降低风险的同时加速变革，因此这会让公司变得积极的放权和更加敏捷。

规模：随着业务的增长，支持更多的用户数变成了战略的必须，更多的地点，更宽的网络流量，同时保持及时地响应速度，成本管控，并和有容灾能力。

利润：在IaaS的世界里，策略的目的就是在需要的时候，也就是在有客户上线的时候，才去采取、购买资源。支出的方式从预先的CAPEX（按对需求的预估购买新的设备）到OPEX（按实际发生的需求购买）。而且这不是全部，因为机器能及时地买到但并不会被有效的利用（译者注：我觉得这句话因该是说，硬件设备采购起来比较容易和方便，但是使用的时候确往往存在着浪费）。

Cloud Native的另一个优点是在主机上花费更少。它核心战略是减少技术风险。过去，我们理解的避免危险的方法是慢速和小心。Cloud Native的方法是快速前进但是采用的是小的，可逆的和低风险的步骤。这可以是非常强大的，但它不是免费的而且不容易。这是一个巨大的哲学和文化的转变，也是一个技术挑战。

• 使用IaaS：运行的服务器可以灵活的按需分配。
• 使用或演变为微服务架构设计系统：每个组件都很小并且互相解耦。
• 自动化和编码：取代用人工去执行脚本和代码。
• 容器化：把应用进行封装处理，使他们测试和部署时更加容易。
• 编排：使用现成的管理和编排工具抽象化生产环境中的服务器个体。

虽然这些可以带来很多的好处，但是他们基本上都是与降低风险相关的。十年前，我为一个小企业为工作时，晚上睡不着，想知道生产服务器上到底在运行什么程序，我们是否能复现它们，以及我们如何依赖单个人的能力去处理繁杂的工作。那时我经常要为采购多少项目上需要的硬件而焦虑，这些是我那时候最不能管控的风险。终于，新的部署实现打破了我现有的服务体系，这就像缠在一起的一罐意大利面条。这并没有给思考未来留下多少时间（或睡眠）。

在IaaS出现之前，infrastructure-as-code（用脚本创建环境），自动的测试，容器和微服务（它依赖于现代化的高速硬件设备和网络）我别无选择，只能花很多的时间在计划，测试和文档上。在那时，这是绝对正确的事。但现在我们有了这些新工具，问题是：“这种像以前一样的方式还是我们唯一的选择吗？”“事实上，甚至它是最安全的选择了吗？

我们没有考虑用Cloud Native是因为它虽然很时尚，但我们有一个更务实的想法，该方法适用于持续交付（价值在于它很快），它扩容方便并且运营起来效率很高。然而，最重要的是，它可以用一种新的方式去降低风险-小并且很快。这有实际原因的，我们将在稍后的博客系列中讨论它。

原文链接：http://container-solutions.com/what-is-cloud-native/

文章翻译：DockOne社区-王晓轩

本文链接：https://www.yunweipai.com/16109.html