“云原生”应用如何改变IT，为什么花了这么长时间

对于诸如 “云原生” 的工业控制系统（ICS），内容管理系统（CMS）或医院管理系统（HMS）等主要应用  ，其整个生命周期必须存在于云平台上。它是在此处开发或组装的，在此处进行了测试和测试，在此处进行了部署，调试，并在此不断进行更新。它不是作为某种永久居留权“安装”在数据中心的服务器上。它并不会转换为虚拟机映像，只是使其可以跨服务器移植。它是为云设计的，它不仅要求对其架构进行根本性的更改，而且还要求对支持它的整个IT经济进行根本性的更改。

此外：  IT工作：解决日益严重的数字技能鸿沟

从某种意义上说，服务器端应用程序的发展正在恢复到PC时代之前的过程，当时x86处理器将大型机和小型计算机从数据中心中淘汰出来。甲  云的本机应用程序是为系统由该主机它，而不是必须被转换或在虚拟环境中上演隐藏从它的云的性质。

分时的回归

“在我们现有的系统上，大约35位用户可以获得良好的同时服务，每个人都错觉自己完全控制了机器。每个用户坐在电传打字机上，键入程序，并不断输入更正，直到程序最终生效为止。这使得使用计算机既方便又愉快。”

-John G. Kemeny和Thomas E. Kurtz
达特茅斯分时计算系统，1967年4月

自从计算开始以来，就已经为指定运行它的机器开发了软件。那不应该让任何人感到惊讶。达特茅斯（Dartmouth）的约翰·凯梅尼（John Kemeny）和托马斯·库尔兹（Thomas Kurtz）通过设计一种旨在经受反复试验的编程语言：BASIC实质上发明了现代计算。第一个真正的云计算平台以及当今最成功的此类平台都是其工作的直接后代。他们的原则是，应该在这些机器内培养和开发可以充分利用它们所运行的机器的程序，而不是事先在纸上散列出来并单独编译。

平台即服务

“云本地”计算是相同的原理，扩展到涵盖云平台。如果说实话（现在是个好时机），那么我们应该承认“云”是一台机器，至少从运行在那里的应用程序的角度来看。这实际上不是一个有雾或超凡脱俗的环境，而是一簇由高速网络链接的处理器集群，它恰好跨越了地球。专为在这类大型机器上设计云原生应用而设计的语言是Dartmouth BASIC的直接后代。

另外：  使用云作为数字化转型的平台

首先，云的诞生提出了组织选择在何处托管其应用程序的问题，这是一个长期存在的问题。云应用程序平台旨在实现可移植性。当今的云基础架构通常带有一个应用程序平台，例如Cloud Foundry（由Pivotal 托管），Apprenda或Red Hat OpenShift。

很快，“云原生”一词可能会被废弃，例如1990年代和2000年代初期的电视节目标有“高清电影”！

理解所有抽象

自从C ++和高级编程语言问世以来，软件的设计就通过一层或多层抽象与其底层硬件分开了。程序员-现在被称为开发人员-通常无需考虑硬件的体系结构或支持它的基础结构。

另外：  Linux现在主导了Azure

“云”（现在重命名为时已晚）是一台机器，尽管它跨越了整个星球。建立了一些最早的云服务，包括早在2008年的原始“ Windows Azure”，便是一种新软件的登台方式，其设计目的是在那里运行。尽管暗示了最初的品牌含义，但其目的是要分发而不是集中化的软件（换句话说，要在Web上而不是在充当服务器的PC上运行）采用自己的设计。

2013年的Docker革命同时实现了三种理想情况：

• Docker通过设计标准类的可移植，基于软件的容器，将应用程序与运行它们的服务器分离。
• 它建立了一种自助服务部署机制，使开发人员可以在本地进行本地构建，然后在全球范围内采取行动-在单台计算机上暂存分布式应用程序，然后以简单，自动化的方式将其推送到云中。
• 它永远改变了基于服务器的应用程序的体系结构，从而创建了至少一种特别适合于在云中部署的编程风格（也许更多）：云原生应用程序。

这就是我们之前讨论的“云”吗？

在继续使用该短语之前，让我们解决我们认为“云”今天的问题。我们以技术为生的人倾向于在企业数据中心和云服务提供商之间划定硬性界限，将组织可能拥有和自己经营的东西指定为“此处”，将云指定为“上方”。

这并不是  云概念的真正含义，或者曾经真正含义的含义。如果您的组织拥有或租用运行它们的服务器，则该组织可能拥有自己的云本机应用程序，而前提是该组织拥有或租用托管服务提供商（例如Equinix或Digital Realty）。我们一直称其为“混合云”，好像它是一个奇怪但可行的替代方案，现在是其服务可能部分拥有并从服务提供商（例如亚马逊，微软，谷歌或IBM，无论这些服务位于何处。

此外：  企业开发人员不断接触云 

让我们尝试用另一种方式，用一开始就有意义的术语，然后再将其重新定义为其他含义：云可以是位于地球上任何地方的资源的任意组合，其网络连接性使它们可以协同工作。服务器的单个组装。一个组织可以整体上拥有和运营自己的云，尽管通常不是这样。商业云服务提供商（其中三个最大的提供商是  Amazon AWS，Microsoft Azure和Google Cloud））为组织提供了在我们现在称为公共云的空间中部署其任何或所有应用程序所需的资源。一些企业并不拥有或运营自己的任何计算资源，而是选择完全从公共云服务提供商那里租用那些资源。

因此，当我们说应用程序对这种类型的云是“本机”时，我们的意思不仅是为在此处部署而构建的，而且还可以在此云所涵盖的空间的任何部分中移植。云将应用程序及其资源（包括数据库）的多个暂存区域缝合在一起，形成一个单一的景观。云原生应用程序将这种情况视为自己的情况。更重要的是，它不必深入研究托管该格局的部分内容的服务器或数据中心的基础结构。

如何构建原生云应用程序

举例来说，一家企业管理一个VMware vSphere环境。最初，vSphere旨在承载行为类似于物理服务器但呈现为软件的虚拟机（VM）。现在，借助称为vSphere Cloud Foundation的扩展产品，它还可以托管和管理新型的容器化应用程序，这些应用程序具有更高的可移植性，并且存在于VM之外。

正如VMware去年11月宣布的那样，这种容器化的应用程序将能够利用Amazon AWS的资源，例如计算能力，存储和数据库服务。VMware去年与Google Cloud达成了类似的协议。结果，组织的混合云可能由从公共提供商及其自己的数据中心收集的资源组成。VSphere将这些资源视为用于管理应用程序的单个空间。

此外：  成为“云原生”企业的8个步骤 

因此，为此类环境（也许在此环境中）设计的应用程序将是“云原生”的。与为独立Windows Server或Linux环境编写的基于服务器的应用程序相反，云原生版本将能够随时在该空间中的任何位置进行部署。

This kind of arrangement is by no means exclusive to vSphere. If an organization had its own OpenStack cloud on-premises, it could integrate its own private resources to some degree with AWS, Microsoft Azure, or Google Cloud. (Whether it does so with simplicity is a matter of open debate, but at least it’s open.)  An organization with Microsoft’s Azure Stack can build and deploy applications using Visual Studio (or its outstanding open source counterpart, VS Code) on its own servers in its own data centers, and integrate those resources with those available from the public Azure cloud as necessary.

基于我们今天掌握的信息，我们认为订阅AWS Outposts的企业应该能够构建适用于Amazon EC2的应用程序，并将其部署到位于客户房屋内的AWS服务器上。这将是云本地应用程序，但不一定要在公共云中使用，除非并且直到客户有意将其移动到那里或部分移动到那里。

为什么云诞生突然变得如此重要

简而言之，这里的概念是：本地云应用程序至少要在要运行的云计算平台上组装，并且最多是完全组成的。它的整个生命周期（包括管理它的所有过程和服务）都在这里进行。它的数据库位于此处。在那里启用了其网络连接。而且构建和维护它的人员很可能是云服务提供商的客户，而不是其自己的员工或承包商。

另外：  适用于小型企业  CNET的最佳云服务

由于以下原因，服务器端应用程序的云原生今天尤其重要：

• 它更改了应用程序“版本”的定义。  熟悉Windows 8，Windows 8.1和Windows 10的每个人都熟悉对软件版本进行编号的，通常是随意的方式。从较早的应用程序的角度来看，“演进”是一帆风顺的，并且在少数情况下是信念的巨大飞跃。真正的云原生应用程序可以按照智能手机应用程序的发展方式进行演变：逐渐，增量地（每天多次），而用户不必担心其内部版本号。
• 它改变了整个计算领域。  云原生模型可以对构成计算机程序的内容进行彻底而彻底的重新考虑。没有明确的理由（甚至不是经济的理由）为何必须在PC或移动设备上安装任何类别的应用程序，但也许是为了解决缺乏连接性的问题，而当今几乎没有人真正缺乏这种连接性。
• 它为寻求建立云计算中心（5G无线模型的必要组成部分）的电信公司打开了一个新的潜在市场，这些公司需要补充收入来帮助他们付款。一家电信公司可以为企业客户提供从“附近的云”到其服务的服务，这也许是一个较小的平台，可为小型企业提供登台，部署和管理定制应用程序的低成本平台。
• 它使丢失的艺术得以复兴，并为最有可能为此做出贡献的人们重新注入活力。在IBM PC到来之前，微型计算机软件是由业余程序员开发的，他们在BBS，在线服务和Web出现之前的数年间，通过用户组彼此共享代码。至少在目前以及只要这种情况得以维持的情况下，云原生计算的开源性质就鼓励从业者相互学习如何构建更好的系统，功能和数据库。
• 它按下软件行业的重置按钮。  操作系统占据统治地位的世界，以及“网络就是平台”的世界，与第二次世界大战来自革命战争和南北战争时在云周围建立的计算生态系统不同。

比较本地应用程序与迁移应用程序

曾经生产的大多数服务器端软件（即，不是在PC或电话上运行的应用程序都是“客户端”）被设计为在常规机器上运行-装有处理器，自己的内存的盒子，一些本地存储和PC操作系统。当较旧的软件类在云中运行时，将为其创建一个虚拟机（VM），它本身就是一种程序。出于应用程序的考虑，VM伪装成传统的计算机，而这通常并不知道它们之间的区别。但是虚拟机是可移植的，易于管理。如果它已损坏，则可以从较早的映像中克隆它的另一个实例以取代它的位置（“实例化”）。

另外：  为什么原生应用程序并没有真正注定失败，目前还是  TechRepublic

云原生应用程序不需要假装。如果它确实像许多VM一样在VM中运行，那么它就能知道运行它的云平台，这使它可以更好地控制其在整个网络中的管理和分发方式。

这产生了两种思想流派，这两种思想都是云原生方法学的同等有效前提：

• 最后，应用程序可以敏锐地意识到其环境。  作为虚拟机的来宾，应用程序永远不会真正知道支持它的基础架构的真实性质的详细信息。结果，它无法学习如何提高自身性能。现在，通过充当容器内的远程代理的组件（一个突出的示例是NGINX Plus），正在运行的应用程序的组件可以获取有关某些方面的实时数据，其中某些方面确实深奥着其配置和性能。至少从理论上讲，有了这些数据，应用程序就可以对其配置和进一步的分布做出某些决定，编排其自身的某些功能，并以此来发展以适应不断变化的目的和情况。
• 最后，该应用程序不需要了解其环境。  近几个月来，人们提出了一个更加直言不讳的思想，即吹捧开发人员构建应用程序的好处，同时只专注于程序的需求及其用户的利益，而将底层硬件的管理留给环境和分发软件交付给业务流程协调员（最近通常是Kubernetes）。这些是所谓的无服务器体系结构的倡导者。他们说，第一个分时系统从程序的功能中抽象出了计算机操作的细节，并且这种抽象在今天可能同样有效和必要。

您是否需要微服务才能真正成为云原生？

时至今日，尽管后者的核心哲学尚未彻底凝结，但后者是迄今为止最具说服力的思想。无服务器价值主张的核心是这样的信息：抽象使开发人员可以自由思考并完全在他们要解决的问题领域中工作。这与组织的IT基础结构是其业务核心的观念背道而驰，并为组织的业务模式设定了步伐。组织的业务部门和技术部门之间的所有这种“战略一致性”不再是必需的。

另外：  确保您确实需要微服务的8种方法

但是从那里开始，拥护者们继续主张支持单片应用程序的分解，以支持基于微服务的模型，在该模型中，各个组件可以实现共同的目标。确定这些共同目标是什么，就需要无服务器的拥护者说避免的战略协调类型，以便利益相关者可以在同一页面上聚在一起。

一些拥护者也支持他们称为“云原生DevOps”的概念，该概念将使DevOps（开发人员和运营专业人员）的发展与向无服务器和微服务架构的转变保持一致。整个构想的关键问题是，缺乏任何证据表明该运动的Ops部分已经签署了该构想。如果开发人员像无服务器的拥护者所描述的那样“解放”以追求自己的想法和时间表，那么这种分离将与与Ops联盟的概念背道而驰，后者的职责包括设定时间表，并确保开发人员注意他们的基础设施。

现实世界中向云原生的演变

让我们停止在摘要中讨论所有这些内容，并在服务器端应用程序的最常见类之一的历史背景下，更实际地了解其实际含义：

内容管理系统（CMS）是相当复杂的数据库管理器，至少部分地伪装成文字处理器。最初，它将网页存储和呈现为静态文档。但是，由于消费者需要Web具有比存档更多的功能，因此CMS体系结构变得围绕两个处理引擎为中心：

• 一种是从存储库中检索内容的元素，然后将它们组装为HTML组件，这一点称为内容交付应用程序。和，
• 另一个使管理员和编辑者可以创建核心组件或其原型，以及创建这些组件将遵循的样式的内容管理应用程序。

整体架构的模型

第一个真正的CMS系统基于存储库中不断更新，替换和修改的元素，自动生成网页。这种系统的“门户”（例如Vignette）安装在作为用户和管理员的人员的PC上。结果，当整个系统呆滞或贫乏时，它的用户最先遭受苦难，而解决这些疾病则需要用户直接与IT部门进行交流，而在手持会议上，谁都不知道是谁的手领导谁。

另外：  云计算：要注意的五个关键业务趋势

回想起来，这些第一个CMS系统的体系结构以及他们启发的“知识管理系统”被称为整体式。当应用程序完全驻留在PC上时，其开发人员可以确保在分发应用程序之前所有组件都能正确组合在一起。在网络系统中，存储库位于服务器后面，并且在服务器及其客户端之间，会遇到很多中间件。因此，这些部分并不总是很合适。

对于任何整体应用程序，创新都需要经过高度计划，协调的步骤。协调一致的产品计划的一个例子是Kentico，这是一种用于营销和电子商务的CMS。自2004年首次出现在现场以来，Kentico很快就采用并保持了每年大约一个版本的主要发布节奏。这是Kentico的功劳，因为其客户群将其视为系统连续性的象征。正如一位博客作者在2017年底写道： “每个新版本都值得一提。我可以说这不仅是因为我是Kentico的狂热者，而是因为Kentico的每个主要版本都趋向于增加社区要求的东西。”

发行策略的历史

在客户机/服务器体系结构时代，主要版本的发布时间本身已成为一种艺术形式。正如资深分析师Kurt Bittner和顾问Ian Spence在2006年为他们的书《管理迭代的软件开发项目》所建议的那样，应用程序的开发人员应在其业务规划的早期阶段就其发布节奏进行规划，其中包括通过分散分布来最小化风险的其他原因。随时间演变。Bittner和Spence写道：

所需的演变（主要版本）的数量通常由业务问题决定，可以平衡企业吸收新功能的速度与对新功能的需求。。。每个主要发行版都为每个人提供了一个明确的终点，如果将开发计划为无差异的一系列正在进行的迭代，则通常会遗漏该终点。

他们警告说，如果发布计划太频繁，开发人员可能会冒引入如此多新开销的风险，以至于很快用户将无法意识到这些功能为自己的组织增加的价值。在历史的这个时期，发布计划是一项精心设计的工作，因为大多数人都清楚，这些应用程序的引擎（当然是CMS的情况）是其业务的核心。

潜在停机的经济风险以及连续性问题的确定性，对于任何组织来说都太大了，除非并且直到即将发布的功能的潜在价值（无论他们等待了多长时间）才能胜过它们。（提醒我告诉您某个发布者等了多少年才感到足够自信，以便切换到新系统使其能够使用粗体显示其第一段内容。）这就是为什么Spence和Bittner警告说计划发布周期的原因应谨慎选择适合业务需求的时间。

另外：  什么是DevOps？执行指南

但是，这些作者的推测是，CMS的每个实例都可以根据其独家客户的独特需求进行调整-这并不是市场最终运作的方式。

由于多种原因，包括出售其母公司，以及对该产品进行大量的重命名和重新发布，其后继产品Open Text的Vignette版本7和版本8之间的差距大约为7年。但是在那段时间里，数量惊人的客户紧紧抓住了这一点，无论如何都不高兴，而且在某些情况下，它似乎受到了胁迫。一旦主要发行商承诺提供多达七个主要发行版，一些人便认为无法采用替代平台。正如2011年AdWeek的 “后端麻烦”的故事所记录的那样，发行商正在放弃其品牌CMS套件，而是围绕开源Drupal框架构建自己的平台。。。并发现成功。

在某些情况下，维护旧版Vignette实例稳定性的努力使跳转到版本8的风险太大。正如Government Technology在2012年报道的那样，佐治亚州技术管理局将这次外逃定为“强身健体”。

无头混合动力的攻击

大约在这个时候，Web体系结构的兴起和HTML5的出现通过引入所谓的“ RESTful设计”解决了整体问题。在这里，门户被基于浏览器的前端所替代，该前端通过API调用与后端的服务器进行通信。我们可能会花大量时间研究这种方法如何改变前端架构。我们会错过的是后端发生的事情：系统不再需要两个（或更多）引擎来处理来自两个（或更多）用户类别的输入。相反，身份验证和权限服务可以验证，过滤API调用并将其路由到适当的处理程序。此外，通过使用复杂的反向代理（如NGINX），这些API调用处理程序可以在服务器节点之间进行多路复用和分布，从而使CMS能够更好地响应各种工作负载。

另外：  2019年将对DevOps进行三种微调

此时出现了一种新的，有趣的CMS体系结构。它被称为“ 无头设计 ”（如果您问我，这是一个冒险的绰号），它完全消除了门户，在其位置上提供了一个在其自身与控制程序之间没有标准接口的引擎。这将使开发人员有空通过Web或其他地方构建所需的任何类型的前端，并独立于后端继续其前端的开发轨道。可以想象，通过这种方式，与可管理性和生产力相关的功能可以更快地实现，而不必等待CMS存储库的下一个主要版本或无头架构师所说的“内容中心”。

最后，出现了云原生模型

然而，转向无头模式并不是无缝过渡，而是外逃。既然我们已经确定了下一个进化的飞跃已经跨越了一个相当大的鸿沟，那么与完全重写相比，组织正在质疑将其现有CMS方法和资产转移到无头模型并在云平台上暂存该模型的相对价值。他们的模型使用云原生框架。

后一条路径将使组织可以自由地尝试无服务器性，这似乎与无服务器性紧密相关。而且，通过采用微服务，组织还可以继续采用另一个已引起广泛关注的概念：持续集成和持续交付（CI / CD）。在这样的系统下，组织将其发布节奏定为比采用传统的Bittner和Spence方法的公司快2500倍（是的，这些是零，而不是被误读的％标记），从而显着提高了生产率，获利能力，甚至享受他们的工作。

为了解决这些新出现的问题，包括Contentful在内的新公司正在生产他们称为“可组合模块”的东西-可以像在云平台上构建一样组装的组件。将这些模块视为组织构建自己的云原生CMS的预混合，预先测量的要素，或者更确切地说，是一种用于管理其出版物的系统，该系统取代了我们所知道的CMS。

最近发布的一个案例研究[ PDF ]描述了大英博物馆如何聘请软件开发公司将Contentful的模块组装成一个实体，博物馆的所有出版部门都可以以自己的方式使用-就像每个分支，包括网络广播一样和印刷，都有自己的CMS。Contentful系统主要是根据当时用户的需求，以一种便捷的方式而不是谨慎的方式为组装和发展应用程序的新方法指明了方向。

另：  分析DevOps成功的六个步骤

侦察

这就是云原生应用程序模型正在改变讨论的方式，并且已经开始改变数据中心：

• 无论功能多么琐碎或多么广泛，自动化功能和组件的部署都可以消除传统上实施版本更新所涉及的风险因素。
• 由于这些风险不再存在，组织可以自由地进一步思考-负责他们希望自己的信息管理系统成为什么样的人，并希望他们表现得很好。
• 现在，组织可以负担聘请小的开发人员团队来为大型项目做出贡献和修改，从而为他们提供“滚动自己的”应用程序套件的所有好处，而无需每次都进行彻底的改造。
• 通过在公共场所和私人场所扩展的云平台，组织可以自由地租用或拥有自己当时可以管理的数据中心资产，无论其多少，也可以将它们的整个应用程序环境扩展到两个平台。
• 是的，是的，组织可以尝试无服务器的微服务，这些奇妙的新概念使Netflix成为了它已成为动态组织。但是，对于大多数企业而言，云本身已经是一片陌生的风景，微服务之类的概念也可能是说未知语言的超凡脱俗的情报。可以想象，CI / CD引入的交付管道模型可以为这些企业提供所需的广泛泊位，使他们可以按照自己的节奏尝试新事物，快速迭代，而且需要很少的尝试。