https://pivotal.io/cloud-native
什么是本地云应用程序？
本地云是一种构建和运行应用程序的方法，充分利用了云计算交付模式的优势。本地云是关于如何创建和部署应用程序，而不是在哪里。虽然今天的公共云会影响几乎每个行业的基础设施投资的思维，但是云类交付模式并不是公共环境所独有的。公共云和私有云都适合。最重要的是能够按需提供几乎无限的计算能力，以及为开发人员提供的现代化数据和应用服务。当公司以本地云的方式构建和运行应用程序时，他们可以更快地将新想法推向市场，并更快地响应客户需求。
组织需要一个构建和运行本地云应用程序和服务的平台，以自动化和集成DevOps，持续交付，微服务和容器的概念：
DevOps是软件开发人员与IT运营部门之间的合作，旨在不断提供高质量的软件，以解决客户的挑战。它创造了一个文化和环境，在这个环境中，构建，测试和发布软件的过程更为迅速，频繁，更一致。
由敏捷产品开发实践支持的持续交付，就是通过自动化不断将小批量软件运送到生产环境。持续交付使企业能够释放沉闷和可靠的信息，从而使企业能够以较低的风险频繁交付，并从终端用户那里获得更快的反馈。
微服务是一种将应用程序开发为一系列小型服务的体系结构方法; 每个服务都实现业务功能，运行在自己的进程中，并通过HTTP API或消息传递进行通信。每个微服务都可以独立于应用程序中的其他服务进行部署，升级，扩展和重新启动，通常作为自动化系统的一部分，能够在不影响最终用户的情况下频繁更新现场应用程序。
与标准虚拟机（VM）相比，容器提供了更高的效率和速度。使用操作系统（OS）级别的虚拟化，单个操作系统实例在一个或多个隔离容器之间动态分配，每个容器都具有唯一的可写入文件系统和资源配额。创建和销毁容器的低开销与单个虚拟机中的高封装密度相结合，使得容器成为部署单个微服务的理想计算工具。
“我们所学到的一件事是，如果你不能更快地把它推向市场，毫无疑问，市场将会发生变化，无论你设计，构建或部署它有多好，训练你的人，这不会是正确的，因为这太晚了。“
James McGlennon
Liberty Mutual保险集团执行副总裁兼首席信息官
为什么云本地应用程序很重要
云原生应用程序是专门为云模型构建的。这些应用程序通过小型专用功能团队迅速构建并部署到易于向外扩展和硬件解耦的平台上，从而为企业提供跨云环境的更大灵活性，弹性和可移植性。
云作为竞争优势。
云原生意味着将云计算目标从IT成本节省转移到业务增长的引擎。在软件时代，能够快速构建和交付应用程序以响应客户需求的企业将主宰其行业。
使团队专注于弹性。
基础设施失败 服务在负载下喘息。在一个云原生的世界里，团队拥抱现实，特别是韧性建筑师。以云为本的重点可帮助开发人员和架构师设计可保持在线状态的系统，而不受环境中任何地方的打嗝。
获得更大的灵活性
公有云提供商继续以合理的成本提供令人印象深刻的服 但大多数企业还没有准备好只选择一个基础设施。通过支持云本地方法的平台，企业可以构建在任何（公共或私有）云上运行的应用程序，而无需进行修改。团队可以在最有商业意义的地方运行应用程序和服务，而无需锁定到一个供应商的云中。
使业务与整体业务保持一致。
通过实现IT运营的自动化，企业可以转变为一个精益，专注的团队，以推动业务优先事项。他们消除了由于人为错误而导致失败的风险，因为员工专注于自动化改进，以取代常规的日常管理任务。通过在所有级别的堆栈中进行自动化的实时修补和升级，它们可以减少停机时间，并减少操作专家对“专心致志”的需求。
|
云原生应用程序
|
传统的企业应用
|
|---|---|
| 可预测。云本地应用符合旨在通过可预测行为最大化弹性的框架或“合同”。云平台中使用的高度自动化，容器驱动的基础设施驱动着软件写作的方式。这个“合同”的一个很好的例子就是最初被记录为12个因子的12个原则。 | 不可预料的。传统应用程序无法实现在云本地平台上运行的所有优势，因为它们都是以独特的方式进行架构或开发的。这种类型的应用程序往往需要更长的时间来构建，大批量发布，只能逐渐扩展，并假定依赖服务的高可用性。 |
| OS抽象。云原生应用程序体系结构允许开发人员使用平台作为从底层基础架构依赖性中抽象出来的一种手段。团队专注于他们的软件，而不是配置，修补和维护操作系统。最有效的抽象手段是一个形式化的平台，例如Pivotal Cloud Foundry，适用于在基于云的基础架构（如Google Cloud Platform（GCP），Microsoft Azure或Amazon Web Services（AWS））上运行。 | OS依赖。 传统的应用程序体系结构允许开发人员在应用程序和底层操作系统，硬件，存储和后台服 这些依赖关系使跨越新基础架构的应用程序迁移和扩展变得复杂并且风险很大，这与云模型相悖。 |
| 合适的容量。云原生应用平台自动化基础设施供应和配置，根据应用的持续需求在部署时动态分配和重新分配资源。基于云本地运行时构建优化应用程序生命周期管理，包括扩展以满足需求，资源利用率，跨可用资源的编排以及从故障中恢复以最大限度地减少停机时间。 | 容量过大 传统IT为应用程序设计专用的定制基础架构解决方案（“雪花”），延迟应用程序的部署。这个解决方案往往是基于最差情况下的容量估算过大，很少能够扩展以满足需求。 |
| 协作。Cloud-native促进了开发人员，人员，流程和工具的组合，使开发和运营功能紧密协作，加快并平稳地将完成的应用程序代码转换为生产。 | 孤立。传统的IT运行从开发者到操作的完成的应用程序代码的越界切换，然后在生产中运行它。组织优先事项优先于客户价值，导致内部冲突，交付缓慢和妥协，员工士气低落。 |
| 持续交付。 IT团队一旦准备好就可以立即发布个别软件更新。快速发布软件的组织得到更严格的反馈循环，并能更有效地响应客户的需求。持续交付与其他相关方法（包括测试驱动开发和持续集成）最为一致。 | 瀑布发展。 IT团队定期发布软件，通常几个星期或几个月，当代码已经构建到发行版中时，尽管发行版的许多组件已经准备就绪，除了人工发布车辆之外没有任何依赖关系。客户想要或需要的功能被延迟，企业错过了竞争的机会，赢得客户并增加收入。 |
| 独立。 微服务架构将应用程序分解为小型，松散耦合的独立操作服务。这些服务映射到较小的独立开发团队，并可以在不影响其他服务的情况下实现频繁，独立的更新，扩展和故障转移/重新启动。 | 相关。 单片架构将许多不同的服务捆绑到单个部署包中，从而导致服务之间不必要的依赖关系，并导致在开发和部署期间丧失敏捷性。 |
| 自动化的可扩展性。规模化的基础设施自动化消除了由于人为错误造成的停机。计算机自动化不面临这样的挑战，始终如一地在任何规模的部署中应用相同的规则。云本地化也超越了传统的面向虚拟化的业务流程之上的专门自动化。全云原生架构是关于自动化系统，而不是服务器。 | 手动缩放。手动基础架构包括手动创建和管理服务器，网络和存储配置的人工操作员。在规模上，由于复杂程度高，运营商对问题的正确诊断速度较慢，容易导致规模无法正确实施。手工制作的自动化配方有可能将人为错误硬编码到基础架构中。 |
| 快速恢复。 容器运行时和编排器在虚拟机之上提供动态，高密度的虚拟化覆盖，与托管微服务相匹配。编排动态管理跨虚拟机群集的容器放置，以便在应用程序或基础架构发生故障时提供弹性伸缩和恢复/重新启动。 | 缓慢恢复。 基于虚拟机的基础架构对于基于微服务的应用程序来说是一个缓慢而低效的基础，因为单个虚拟机启动/关闭的速度很慢，即使在向其部署应用程序代码之前，开销也很大。 |
考虑云本地应用程序？
要记住什么
运营将在云端世界中转变。
您的运营团队将从现状的管理者毕业，成为流程改进和自动化的佼佼者，直接为企业创造价值。云原生平台负责应用程序的第1天发布和第2天的操作，自动监视和修复以前需要手动干预的问题。
您的工作量需要优先考虑。
不是每个工作负载都应该转换为云本地。业务和IT专业人士需要共同努力，确定遗留和新建工作负载的优先级，以确定技术可行性，战略重要性，从而确定每种情况下云原生方向的投资回报。除了绿地开发之外，还有各种各样的重建模式可以帮助进行评估。
开发人员需要编码到合同。
要获得云原生平台的好处，开发人员可能需要更多的纪律来遵循12因子原则，并将其平台和服务标准化。今天有了这么多的选择，每个应用程序都会吸引新的技术和模式。智能团队拥有一组有限的约束条件，因此他们可以自由地专注于创新软件，而不是重新发明基本功能。
你将需要一个平台; 建立或购买？
许多团队从开源自动化和容器技术的组合中探索构建自己的平台。然而，他们很快就发现他们需要比他们想象的更多的组件 - 所有这些都不是为了一起工作而设计的，他们的努力将会延迟开始构建应用程序的实际工作。除此之外，一旦球队有一个工作平台，他们必须维护它。将此体验与使用经过验证的集成平台（如Pivotal Cloud Foundry）进行比较。从第一天开始，团队可以专注于构建推动业务的应用程序，并对平台能够处理操作和基础架构的能力充满信心。
你不必一个人去。
通过沉浸式学习，例如与Pivotal Labs合作，可以彻底浸润敏捷的产品开发实践（如持续交付），并强化新的开发习惯。关于这个模型有大量的信息：消费和试用。如果这个75％的团队觉得自己的组织不够灵活，那么这个团队就有机会尝试新的东西。