目录

1、概要

2、数字服务交付的三大支柱

3、动机

4、思考

5、主要参与者

6、主要收获

7、附录：企业软件交付的历史和基础架构

1、概要

面对一系列的竞争，今天的企业正在打乱现在的行业，用以寻求实现与初创企业相同的利益。为此，企业正在学习如何使用数字交付服务的三大基石。

①、使用综合的、可扩展的基础设施平台，例如：公有云

②、软件部署到容器和微服务架构

③、使用一种协调开发和运维的敏捷方法构建软件，称为DevOps

总之、这些能力使得企业能够与云原生创业公司直接竞争。同时，这些特性也不认为是完全陌生的，例如，微服务架构实现了企业一直以来的按模块交付软件的目标。没有一种规模适用所有人，企业们也都是处在采用基于云的模型的不同阶段。这里，我们考虑利用云原生世界中DevOps编排的基本原理，并结合基于容器的基础设施和微服务作为部署目标，以及开发和运维工作流程。

主要发现：

1、企业可以采用云、微服务和DevOps的元素，但最大的好处是将他们联合使用。

2、企业面临着初创企业不具备的限制，包括遗留系统和架构、治理挑战和更加传统的思维和心态。

3、每一个支柱都在走向成熟，变得更加企业化，因此适合传统业务和运营模式。

4、企业可以处于DevOps采用的不同阶段，从处于开始阶段到在某些方面已经实现，到成为真正的数字第一。

5、供应商的布局是复杂的，反映出不成熟和快速增长。决策者需要选择能够推动进度并最小化成本的工具和框架。

近年来，Kubernetes已经成为一种日益流行的基于容器的微服务编排和管理技术。在后面的“主要参与者“章节，我们会关注为基于Kubernetes的环境提供特定附加值得供应商。这就排除了以Kubernetes为目标的供应商。我们认识到这并不是唯一的编排选项，也不是最适合每个场景。

2、数字服务交付的三大支柱

在云原生的世界里，我们如何定义DevOps编排？根据最近的研究表明，云计算被企业视为首要任务，优先级比也受到如此多关注的领域要高，数字化转型。云计算本身并不是终结，正如我们从”云原生“定义可以看出，它为可扩展的应用程序提供了基础。

那么，将可伸缩的应用程序变成现实需要什么？对于新一代的市场扰乱组织，云原生必须是默认选项。我们可以把它看成三根柱子：

1、基于云的部署平台。公有云作为一种丰富、全面和高度可扩展的基础设施平台，使得初创企业能够在不需要昂贵和很快过时的基础设施情况下快速发展。许多供应商现在有了可以部署到私有云环境的功能。

2、利用微服务编排。微服务部署架构基于Docker容器（基本上是独立的、单一的应用软件模块），这些可以使用自动化、健壮和可扩展的编排机制和架构进行部署，如Kubernetes。容器的一个关键特征是应用程序的可移植性，容器可以独立于部署目标而存在。

3、DevOps软件交付。敏捷开发最佳实践和协作方法使得部署和运维进行更多迭代，在满足业务和用户需求的同时加速创新。当敏捷实践独立存在时，自动化工具用来支撑DevOps工作流的各个方面。

通过将这些能力组合在一起，使我们能够继续在数字化原生企业中看到创新，创造出许多传统企业梦寐以求的速度和敏捷。尽管希望实现数字化转型的企业可能会被数字优先模型所吸引，他们经常与自己的遗留系统和流程进行斗争。

什么是”云原生“技术？

云原生技术已经由云原生计算基金会定义为使组织能够『在现代动态环境中构建和运行可扩展的应用程序，例如公有云、私有云和混合云。容器，Service Mesh，微服务，不可变基础设施和声明性API就是这种方法的例子』。为了实现基于数字优先的服务交付目标，部署平台需要能够支持微服务编排的原生能力，以及包括运维性能和服务管理的机制。

好消息是，上述每一项都在走向成熟，变得更加企业化，因此会更适用于传统业务和运维模式。DevOps正在成长为最佳实践采用更高级别的治理（以价值流管理趋势为例）。今天的云机制越来越适用于企业的公共和私有部署。Kubernetes正在成为微服务部署标准，最大限度的减少了重复创建轮子的需求。

基于容器的基础设施和微服务为软件部署提供了边界。为希望提高大规模可扩展、灵活和分布式产品的企业提供了巨大可能。最近，他们开始将Kubernetes作为单一目标架构进行标准化，围绕特定部署目标实施DevOps实践创造机会。

因此，数字优先思维不再局限在初创企业，而在过去，像Netflix这样的应用程序是需要定制化的，我们现在有了一个标准的方法可以被任何规模的组织所采用。在下一节中，我们将深入研究导致这种情况的重要因素。

3、动机

企业为什么要在云原生世界里采用DevOps编排？正如我们所讨论过的，数字优先的总体战略已经从“拥有很不错”转变为“必须拥有”，因为它已经成为差异化竞争的主要来源，特别是在日益增长的以用户为中心的世界里。例如，最近Gigaom研究表明，在涉及到采用DevOps时，以用户为中心的标准是最重要的。

采用数字优先方法的广泛好处如下：

1、更快的上市时间和实现新的业务价值。以数字优先的方式最大的好处是，组织可以在竞争前获得新的未开发的资源。当你拥有了所有可能需要的云基础设施资源时，应用程序构建的方法成为了瓶颈，此时会关注并优化该问题。

2、商业平台的生态系统优势。拥有一个新的商业平台会产生倍增的网络效应（如Airbnb,Salesforce, Uber, Amazon, Alibaba等等）。这个平台拉近了与客户、合作伙伴和员工的距离，提升了员工的心态、协作和领导力。

3、操作更简单、高效。通过部署到一个标准化的基础架构，这个架构原则上是自我编排和管理的。企业也会降低基础设施管理和运营的成本。

4、基础设置选择的灵活性。许多企业希望转向基于云的模型，但一直不愿意或无法采用公有云。通过标准的微服务，很多关于公有云和私有云，混合云和多云的讨论就可以避免。

虽然总体目标可能是“像初创企业一样”，但企业面临着初创企业所没有的限制，包括遗留系统和架构、治理、合规性、风险和传统的思维和心态。组织可以处于DevOps采用的不同阶段，面对自身的特殊情况，包括：

对于任何一个，或者数字优先的所有支柱来说，从战略和战术层面来看，首先要做的是什么？

1、坚持一个企业预置环境：如何采用云原生的DevOps编排，以及迁移至混合云和多云架构的长期规划？

2、尝试云原生模型，但要么过于架构化，要么创建了太多级别的治理：如何简化和释放已经创建的任何瓶颈？

3、已经在DevOps开发端交付，但正在产生多个运营管理费用：如何做好运维端的工作，降低生产成本？

不管一个企业的目标是什么，它都有必须向数字化转型，以重复发挥这些在工作中使用到的技术的强大作用。

4、考虑

那么，企业在实践阶段如何做才能采用DevOps编排和云原生模型？根据最近的研究，我们可以看到DevOps和基础设施直接的相互作用。以下图表也显示了标准化和（潜在的AI驱动）自动化的重要性。

在具体行动方面，考虑到每个企业都有自己的情况，驱动因素，动机，优先顺序也各不相同，但下面的问题有助于确定切入点：

1、你是否是首席信息官，希望实现董事会层面的数字化战略转型？

①、围绕微服务进行标准化是一个很好的起点，因为它创建了一个可管理、可实现的目标，与业务战略相适应。它也直接适合企业应用程序开发的最佳实践。

②、第一步是定义一个可行的（即，符合IT战略标准的），基于Kubernetes的体系架构目标。这可能是基于公有/私有云，或者是基于两者结合的多云策略。

③、在这个体系结构之后，可以与现有的开发工作流和管道集成。注意，这个体系架构不会对语言和工具施加约束。

2、你是否需要证明采用数字优先的方法来交付业务价值是成功的？

①、考虑在工作流程和产生的业务影响方面能够提供管理信息的工具和机制。

②、确保你有使用的运维工具，能够主动处理性能和服务管理问题。

3、你的DevOps实践是否还处在开发阶段？

①、首先要确保CI/CD能力可以与Kubernetes和微服务协同工作，作为一个部署目标。

②、寻找在DevOps生命周期中能够实现自动化测试、安全和治理方面的产品。使得在不牺牲质量的情况下提高交付速度。

4、你是否认为你的组织在DevOps方面相对成熟？

①、寻找包含“基础设施即代码”原则的产品，以便最大化的标准化和自动化。

②、考虑能够利用整个开发周期生成的数据的工具，例如，使用机器学习。

由于这仍然是一个不断发展的领域，供应商的格局也是复杂的，也反映出了不成熟和快速增长。决策者需要选择工具和框架来推动进展和最小化成本。

我们还建议任何企业都要关注新出现的框架和标准。我们并不是说Kubernetes会被淘汰，而是，我们期望一些标准和框架出现，特别是围绕多云管理和DevOps治理的框架。

5、主要参与者

下面的供应商之所以被选中，是因为他们提供了DevOps编排的好处，特别强调Kubernetes上。我们认识到Kubernetes并不是唯一的目标；其他目标体系结构（如serverless）会有不同的优势和限制，因此也需要不同的工具。

这份清单是不详尽的，其他的厂商还有Canonical, Cloudbolt, Fission,

GitLab, Google, Heroku, Jelastic, Kmesh, Kong, Kublr, Lightbend, Mesosphere, Mirantis, Octopus Deploy, Pivotal, Spinnaker, and Xebia Labs 但未包含在内。

Amazon EKS

考虑到AWS产品组合的广度，毫无疑问，Kubernetes是通过Amazon Elastic Container Service for Kubernetes Service(Amazon EKS)作为目标提供的，Kubernetes服务是Kubernetes上游100%的服务。为了满足自身 的需求，AWS专注于通过诸如CodeDeploy，CodePipeline和Jenkins X等工具来改进Kubernetes的部署。

在编排和管理方面，AWS Fargate也值得一提——这是AWS的serverless 容器计算平台，它提供了一个将容器部署到环境中的接口，使工程师能够专注于微服务，而不是底层的基础设施堆栈。此外，AWS App Mesh有助于管理和配置在Amazon ECS,Amazon EKS, AWS Fargate, 和 Amazon EC2 上运行的应用程序的服务间流量，例如，Kubernetes Pods间的互连和通信。

需要注意的是，EKS只是用于微服务编排的一个AWS容器目标：Amazon Elastic Container Service (ECS) 可能更适合某些工作负载———AWS的观点是，客户的需求不同，需要不同的选择满足这些需求。因此，AWS为云原生、混合云和介于二者之间的客户提供了选项。同样，AWS也有一些客户使用CodeStar工具部署到AWS之外的Kubernetes，例如，他们自己的数据中心。

Bitnami

Bitnami围绕应用程序打包建立了自己的商店，这个概念虽然针对未知论者，但却巧妙的将基于微服务的部署映射到Kubernetes的目标环境中。Bitnami提供了一个开源优先的模型，以及其增值产品Stacksmith。在背后，Bitnami的主要收入来源于云服务提供商，他们使用Bitnami预打包常见的应用程序的版本，如WordPress。

对于Kubernetes，公司维护了一系列用于Kuberetes预打包的应用程序（如 Helm charts），并提供Stacksmith，使得工程师团队能够配置、打包和维护自己的应用程序。他还提供了Kubeapps———一种基于web的工具，可以部署和管理部署到Kuberetes集群的应用程序。Kubeapps被广泛使用并简化了部署过程，但需要一定程度的体系结构专业知识。

在用例方面，公司的传统关注点一直是将现有应用程序”重新平台化”，这是一个既适合打包概念又适合微服务方法的功能———即使是相对复杂的应用程序也可以作为一个容器进行部署，既封装了它，又使附加功能能够围绕它构建。这种方法也有助于在不影响灵活性或控制的情况下，将IT环境置于管理之下。

CircleCI

CircleCI是一个持续集成、构建管理和部署的自动化平台，它不仅限于微服务，而且有一些有用的特性使得开发人员专注与目标环境。考虑到微服务部署往往以许多类似的、几乎相同的存储库配置结束，CircleCI创建了【检查】概念——预定义的、经过认证的配置脚本，可以与代码一起管理。

与”配置即代码”一样，供应商提供了一种灵活的分配模型，例如，开发者可以识别一个Docker镜像，设置机器大小，并将其包含在一个大的工作流中。

CloudBees

Cloudbees是与非常流行的配置管理工具Jenkins最密切相关的供应商。公司的Jenkins企业级软件提供了集成功能，使Kubernetes成为基于Jenkins的工作流的目标。基于Jenkins X，该公司提供基于GUI的自动化和管理工具，以使持续集成、交付、部署和存储任务更流畅。

在企业部署方面，Cloudbees以其简单性交付了它的能力。他们的目标是建立适当的防护措施，使软件能够保持持续的交付自动化和协作过程，同时仍然具有治理、可视性和洞察力。因此，Cloudbees主张采用价值流管理方法，在控制新风险的同时实现最佳效率。价值流管理是DevOps系列即将发布的报告的主题。

Codefresh

Codefresh为微服务和基于容器的应用程序提供了“从头开始”构建的CI/CD管道工具。它的策略是帮助组织加快DevOps采用过程，更快地进入Kubernetes，最大限度地减少部署的开销，然后管理目标环境。在云原生组织之外，Codefresh的许多客户都希望将遗留系统迁移到微服务体系结构。因此，功能超越了集成hooks，并面向企业意愿，尤其是与安全性相关的功能，如单点登录和基于角色的访问。

除了无缝部署和自动化之外，支持DevOps编排的Codefresh功能还包括可由用户修改的内置步骤和对特定处理器的支持。该公司还通过一个管理工具来提供运行中集群的概览，其中包括运维监控。另一个好处是帮助组织“左移”——例如，使用codefresh可以启用一次性部署进行测试，完成后关闭它；另一个例子是，在更广泛推出前，它只能用于启动需要测试的微服务。

Docker

Docker这家最初将我们称之为容器的公司并没有闲置，他们认识到容器只是拼图中的一部分，因此提供了Docker Enterprise Platform ，将安全和治理、编排和自动化结合在一起，并支持认证功能来支持企业级应用程序的交付。例如，DockerTrusted Registry管理和保护从开发到生产的容器镜像，Docker Universal Control Plane包括数据路由、身份验证和部署后的功能。

通过支持一系列基础设施，该公司拥有自己的编排产品（Swarm），但认识到Kubernetes周围的兴趣正在加速，并为其提供全面支持。例如，Docker Compose Yaml文件可以针对Swarm或Kubernetes部署；同时，Docker Desktop使工程师能够创建本地环境，并将应用程序部署到笔记本电脑上的Kubernetes。虽然Docker Enterprise Platform的大多数部署都是基于微服务的，但Docker还与希望将遗留应用程序迁移到容器的组织合作，其目标是在迁移之后“让它们继续存在”，或者使它们能够作为基于微服务的应用程序进行后续的重新组合和后续开发。

HashiCorp

HashiCorp提供“API驱动的动态环境变得简单”。HashiCorp的重点是使应用程序能够以自助服务的方式提供到动态基础设施上，例如支持Kubernetes的基于云的平台。虽然HashiCorp提供了自己的基于集群的微服务编排产品Nomad（它与Kubernetes竞争，尽管它也可以调度非容器化的工作任务），但该公司表示，它并没有区分不同的平台，其更大的目标是帮助组织采用微服务，无论它们使用哪个编排平台。

除了作为”基础设施即代码”的产品TerraForm外，该公司还为密码和密钥等敏感数据提供保险库，并为分布式应用程序管理和协调网络服务提供咨询服务。这些功能共同提供微服务方法的可扩展性，以及企业所需的基于策略的治理需求。HashiCorp于2018年10月宣布了Kubernetes对这些产品的支持。

在满足企业需求方面，HashiCorp致力于将组织从更线性、基于ITIL、构建—运营思维，向一个模型移动，在该模型中，开发、安全、网络、运营和其他团队使用一个通用工具平台，以基于服务的方法相互协作。

Microsoft

Azure Kubernetes Service是微软提供的几个目标平台之一，它受益于与其他目标相同的组件，例如通过Azure Active Directory进行访问控制、通过密钥库进行密钥管理、通过Azure Container Registry进行容器镜像管理和分发以及使用Azure Container Network Interface (CNI)进行网络策略管理。除了它自己的基础设施即代码工具（Azure Resources Manager）之外，该公司还利用HasiCorp TerraForm定义和部署kubernetes集群。

正如预期的那样，微软的DevOps为CI/CD的开发者提供了全面的支持。这包括跨计划和源代码控制、持续开发和集成、协作和信息共享，与预期范围的开放源代码和专有DevOps工作流工具集成，如用于构建管理的Jenkins、用于测试的Selenium和用于协作的Trello。同时，Azure Automation允许将”配置即代码”（基于PowerShell运行手册，越来越多地与第三方平台（如Chef或Ansible）协作）进行持续部署、所需的状态一致性检查以及为生产中的应用程序预先定义监控标准。

Puppet

Puppet用描述目标基础设施配置的“清单（manifests）”来表达“基础设施即代码”。虽然Puppet的历史性增长来自于网络规模的公司和初创企业，但近年来，该公司从企业公司那里看到了更多的吸引力，因为他们希望采用DevOps和基础设施自动化实践，将领先的目标环境和遗留系统结合起来。

Puppet对其定义的环境不可知，这使公司在客户寻求此类方法时，将自己的手转向容器（以及最近的serverless方法）成为一种自然的发展，但在大型机环境中工作也同样舒适。Puppet最初的前提是为系统管理员而不是开发人员解决问题，将系统管理员从日常操作的困境中释放出来，以便他们能够继续进行更有价值的活动。因此，从本质上讲，首要目标是发挥自动化的潜力。

特别关注Kubernetes，Puppet提供了Distelli，一个支持部署到Kubernetes集群和虚拟机的持续交付自动化平台。2018年12月，该公司发布了Puppet Enterprise产品的模块，以自动部署到Kubernetes和Helm。这些都得到了kream开发环境的支持，使工程师能够编写针对kubernetes的puppet代码。

Red Hat/Ansible

RedHat提供了Open Shift，一个Kubernetes的目标平台，可以方便部署、运维和管理。这可以部署在内部数据中心或云中，运行在Redhat Enterprise Linux之上。Red Hat Open Shift也可作为托管服务提供。同时，RedHat Ansible允许使用yaml对微服务容器进行打包和配置，CodeReady Workspaces提供了一个预构建的“Kubernetes原生”开发环境。

Red Hat为Knative做出了贡献，并为其宣传。Knative最初是一个用于部署到Kubernetes的Google云项目，现在作为开放源代码提供，由Pivotal、SAP、IBM和其他公司提供支持。Knative组件管理部署期间的数据路由、工作负载伸缩和构建协调等任务。

在帮助企业实现微服务之旅方面，Red Hat与传统组织和面向未来的组织合作。对于前一组来说，第一步是通过Ansible工具开始将”基础设施即代码”方法自动化。这可以与CodeReady Workspaces 配合使用，以帮助组织将基于微服务的方法作为一种规范，而不是一种例外。

Weaveworks

Weaveworks是专门关注kubernetes编排提供商的一个子集。Weaveworks的企业Kubernetes平台改进了开发人员管道元素，确保了云原生平台上的最佳实践。与Prometheus一起，Weave Cloud自动部署到Kubernetes目标环境中进行应用程序性能监控，这两个环境都作为完全管理的SaaS提供。Weaveworks提供了一个企业Kubernetes订阅，Weave Cloud可以用于部署到其他kubernetes发行版，如Open Shift。

在企业采用方面，Weaveworks专注于加速云原生方法，以满足那些希望更快速地开发应用程序但具有可靠性的组织，这得益于Kubernetes的扩展能力。产品和服务面向基础设施方面的运营商，重点关注如何将基于容器的平台的监控与现有的监控和管理功能集成在一起。在开发人员方面，公司提倡Gitops方法，即使用版本控制系统Git作为Kubernetes配置信息的“真实来源”。

6、主要好处

尽管这一领域有明显的复杂性，但它仍然受到一些简单原则的支持，这些原则映射到企业需要创新、以未来安全的方式采用技术、构建灵活和可扩展的面向客户的系统。为了帮助实现这些目标，希望采用数字优先的服务交付方法的组织可以

• 从新的体系结构开始。想想你正在尝试构建的软件，而不是你拥有的软件。Kubernetes是一个安全的目标，所以从体系结构上来说，你要注意：如果你足够努力，你可以使任何东西看起来像一个大型机。
• 不要试图一次就做到这一点。虽然战略可以而且应该是有远见的，但它也应该被视为建立在成功基础上的变革计划。不会有一夜之间的“数字转换”或任何其他简单的改变。
• 从一开始就衡量成功。成功取决于你的组织的发展方向，所以要相应地制定成功的衡量标准。虽然您可以衡量自己是否以正确的方式运营，但更重要的衡量标准将围绕业务价值。
• 将工具视为创新功能。当今的工具链和管道反映了市场的不成熟，因为几乎没有标准化，而且有大量的选择。考虑到可能很难决定支持哪一种工具，最重要的是定义将对任何特定工具的依赖性降至最低的工作流，或者方法。
  
  

归根结底，首先考虑一个目标体系结构为成功提供了一个起点。Kubernetes是一个快速出现的、经过大量测试的编排标准，它为那些希望首先通过流程和云平台实现数字化的组织提供了一个极好的起点。

7、附录：企业软件交付的历史和基础架构

几十年来，我们多次尝试寻找应用程序单元的“goldilocks”大小。在20世纪70年代（可能更早），像Ed Yourdon这样的行业知名人士会讨论在最小化耦合的同时最大化内聚的中间环节：即，确保应用程序代码的“模块”是独立的，对其他应用程序的依赖性最小。面向对象的概念也开始发挥作用，在这个过程中，Yourdon（和其他人）的概念可以与现实实体周围的结构代码相一致，其结果是创建软件单元：

• 易于部署
• 不太可能改变，就它们如何呈现给世界其他方面而言（即，它们的名字或界面而言）
• 能够在不影响其他软件单元的情况下进行更改
  
  

我们已经看到了各种迭代和尝试，从良好的编码实践（例如，三层体系结构和其他设计模式）到Web Services，以及专有的解决方案，例如支持企业Java bean（EJB）的应用服务器。

快进到90年代，我们看到摩尔定律在处理器能力方面达到了一个转折点。

在过去的几十年中，人们普遍认为工作负载将使用尽可能多的处理器资源：需要基本计算以外的任何东西的任务都会将单个机器推向极限。虽然不可能在千禧年之交之前在上面写上日期，但是处理器的功能已经足够强大，可以运行单一的，然后是多个硬件模拟器，每个模拟器都可以运行一个操作系统。这有两种方式：第一，大型机器可以更好地利用可用的周期；第二，较小的工作负载可以更好地分布在可用的服务器上。

一旦这种“虚拟机”模型变得流行起来，硬件和软件都可以进行优化，以尽量减少它造成的开销，例如，导致在芯片级别包含管理程序模型和虚拟化挂钩。虚拟化也是云计算的重要催化剂，它依赖于将高度标准化的硬件与运行在其上的代码分开的能力。

近年来，我们看到了这些需求的一些后果。随着基于容器的软件部署的到来，对“合适大小”的软件单元的持续需求找到了完美的合作伙伴，这种部署很快就成为软件分发的公认标准。开源方法的日益流行使得新的部署模型成为标准，特别是来自谷歌的Kubernetes。

因此，尽管这些原则和需求中的一些已经过时，但标准化的、非专有的机制的可用性还是相对较新的。企业现在可以着手在超大型环境中构建解决方案了。(转自亮哥）

目录

1、概要

2、数字服务交付的三大支柱

3、动机

4、思考

5、主要参与者

6、主要收获

7、附录：企业软件交付的历史和基础架构

1、概要

面对一系列的竞争，今天的企业正在打乱现在的行业，用以寻求实现与初创企业相同的利益。为此，企业正在学习如何使用数字交付服务的三大基石。

①、使用综合的、可扩展的基础设施平台，例如：公有云

②、软件部署到容器和微服务架构

③、使用一种协调开发和运维的敏捷方法构建软件，称为DevOps

总之、这些能力使得企业能够与云原生创业公司直接竞争。同时，这些特性也不认为是完全陌生的，例如，微服务架构实现了企业一直以来的按模块交付软件的目标。没有一种规模适用所有人，企业们也都是处在采用基于云的模型的不同阶段。这里，我们考虑利用云原生世界中DevOps编排的基本原理，并结合基于容器的基础设施和微服务作为部署目标，以及开发和运维工作流程。

主要发现：

1、企业可以采用云、微服务和DevOps的元素，但最大的好处是将他们联合使用。

2、企业面临着初创企业不具备的限制，包括遗留系统和架构、治理挑战和更加传统的思维和心态。

3、每一个支柱都在走向成熟，变得更加企业化，因此适合传统业务和运营模式。

4、企业可以处于DevOps采用的不同阶段，从处于开始阶段到在某些方面已经实现，到成为真正的数字第一。

5、供应商的布局是复杂的，反映出不成熟和快速增长。决策者需要选择能够推动进度并最小化成本的工具和框架。

近年来，Kubernetes已经成为一种日益流行的基于容器的微服务编排和管理技术。在后面的“主要参与者“章节，我们会关注为基于Kubernetes的环境提供特定附加值得供应商。这就排除了以Kubernetes为目标的供应商。我们认识到这并不是唯一的编排选项，也不是最适合每个场景。

2、数字服务交付的三大支柱

在云原生的世界里，我们如何定义DevOps编排？根据最近的研究表明，云计算被企业视为首要任务，优先级比也受到如此多关注的领域要高，数字化转型。云计算本身并不是终结，正如我们从”云原生“定义可以看出，它为可扩展的应用程序提供了基础。

那么，将可伸缩的应用程序变成现实需要什么？对于新一代的市场扰乱组织，云原生必须是默认选项。我们可以把它看成三根柱子：

1、基于云的部署平台。公有云作为一种丰富、全面和高度可扩展的基础设施平台，使得初创企业能够在不需要昂贵和很快过时的基础设施情况下快速发展。许多供应商现在有了可以部署到私有云环境的功能。

2、利用微服务编排。微服务部署架构基于Docker容器（基本上是独立的、单一的应用软件模块），这些可以使用自动化、健壮和可扩展的编排机制和架构进行部署，如Kubernetes。容器的一个关键特征是应用程序的可移植性，容器可以独立于部署目标而存在。

3、DevOps软件交付。敏捷开发最佳实践和协作方法使得部署和运维进行更多迭代，在满足业务和用户需求的同时加速创新。当敏捷实践独立存在时，自动化工具用来支撑DevOps工作流的各个方面。

通过将这些能力组合在一起，使我们能够继续在数字化原生企业中看到创新，创造出许多传统企业梦寐以求的速度和敏捷。尽管希望实现数字化转型的企业可能会被数字优先模型所吸引，他们经常与自己的遗留系统和流程进行斗争。

什么是”云原生“技术？

云原生技术已经由云原生计算基金会定义为使组织能够『在现代动态环境中构建和运行可扩展的应用程序，例如公有云、私有云和混合云。容器，Service Mesh，微服务，不可变基础设施和声明性API就是这种方法的例子』。为了实现基于数字优先的服务交付目标，部署平台需要能够支持微服务编排的原生能力，以及包括运维性能和服务管理的机制。

好消息是，上述每一项都在走向成熟，变得更加企业化，因此会更适用于传统业务和运维模式。DevOps正在成长为最佳实践采用更高级别的治理（以价值流管理趋势为例）。今天的云机制越来越适用于企业的公共和私有部署。Kubernetes正在成为微服务部署标准，最大限度的减少了重复创建轮子的需求。

基于容器的基础设施和微服务为软件部署提供了边界。为希望提高大规模可扩展、灵活和分布式产品的企业提供了巨大可能。最近，他们开始将Kubernetes作为单一目标架构进行标准化，围绕特定部署目标实施DevOps实践创造机会。

因此，数字优先思维不再局限在初创企业，而在过去，像Netflix这样的应用程序是需要定制化的，我们现在有了一个标准的方法可以被任何规模的组织所采用。在下一节中，我们将深入研究导致这种情况的重要因素。

3、动机

企业为什么要在云原生世界里采用DevOps编排？正如我们所讨论过的，数字优先的总体战略已经从“拥有很不错”转变为“必须拥有”，因为它已经成为差异化竞争的主要来源，特别是在日益增长的以用户为中心的世界里。例如，最近Gigaom研究表明，在涉及到采用DevOps时，以用户为中心的标准是最重要的。

采用数字优先方法的广泛好处如下：

1、更快的上市时间和实现新的业务价值。以数字优先的方式最大的好处是，组织可以在竞争前获得新的未开发的资源。当你拥有了所有可能需要的云基础设施资源时，应用程序构建的方法成为了瓶颈，此时会关注并优化该问题。

2、商业平台的生态系统优势。拥有一个新的商业平台会产生倍增的网络效应（如Airbnb,Salesforce, Uber, Amazon, Alibaba等等）。这个平台拉近了与客户、合作伙伴和员工的距离，提升了员工的心态、协作和领导力。

3、操作更简单、高效。通过部署到一个标准化的基础架构，这个架构原则上是自我编排和管理的。企业也会降低基础设施管理和运营的成本。

4、基础设置选择的灵活性。许多企业希望转向基于云的模型，但一直不愿意或无法采用公有云。通过标准的微服务，很多关于公有云和私有云，混合云和多云的讨论就可以避免。

虽然总体目标可能是“像初创企业一样”，但企业面临着初创企业所没有的限制，包括遗留系统和架构、治理、合规性、风险和传统的思维和心态。组织可以处于DevOps采用的不同阶段，面对自身的特殊情况，包括：

对于任何一个，或者数字优先的所有支柱来说，从战略和战术层面来看，首先要做的是什么？

1、坚持一个企业预置环境：如何采用云原生的DevOps编排，以及迁移至混合云和多云架构的长期规划？

2、尝试云原生模型，但要么过于架构化，要么创建了太多级别的治理：如何简化和释放已经创建的任何瓶颈？

3、已经在DevOps开发端交付，但正在产生多个运营管理费用：如何做好运维端的工作，降低生产成本？

不管一个企业的目标是什么，它都有必须向数字化转型，以重复发挥这些在工作中使用到的技术的强大作用。

4、考虑

那么，企业在实践阶段如何做才能采用DevOps编排和云原生模型？根据最近的研究，我们可以看到DevOps和基础设施直接的相互作用。以下图表也显示了标准化和（潜在的AI驱动）自动化的重要性。

在具体行动方面，考虑到每个企业都有自己的情况，驱动因素，动机，优先顺序也各不相同，但下面的问题有助于确定切入点：

1、你是否是首席信息官，希望实现董事会层面的数字化战略转型？

①、围绕微服务进行标准化是一个很好的起点，因为它创建了一个可管理、可实现的目标，与业务战略相适应。它也直接适合企业应用程序开发的最佳实践。

②、第一步是定义一个可行的（即，符合IT战略标准的），基于Kubernetes的体系架构目标。这可能是基于公有/私有云，或者是基于两者结合的多云策略。

③、在这个体系结构之后，可以与现有的开发工作流和管道集成。注意，这个体系架构不会对语言和工具施加约束。

2、你是否需要证明采用数字优先的方法来交付业务价值是成功的？

①、考虑在工作流程和产生的业务影响方面能够提供管理信息的工具和机制。

②、确保你有使用的运维工具，能够主动处理性能和服务管理问题。

3、你的DevOps实践是否还处在开发阶段？

①、首先要确保CI/CD能力可以与Kubernetes和微服务协同工作，作为一个部署目标。

②、寻找在DevOps生命周期中能够实现自动化测试、安全和治理方面的产品。使得在不牺牲质量的情况下提高交付速度。

4、你是否认为你的组织在DevOps方面相对成熟？

①、寻找包含“基础设施即代码”原则的产品，以便最大化的标准化和自动化。

②、考虑能够利用整个开发周期生成的数据的工具，例如，使用机器学习。

由于这仍然是一个不断发展的领域，供应商的格局也是复杂的，也反映出了不成熟和快速增长。决策者需要选择工具和框架来推动进展和最小化成本。

我们还建议任何企业都要关注新出现的框架和标准。我们并不是说Kubernetes会被淘汰，而是，我们期望一些标准和框架出现，特别是围绕多云管理和DevOps治理的框架。

5、主要参与者

下面的供应商之所以被选中，是因为他们提供了DevOps编排的好处，特别强调Kubernetes上。我们认识到Kubernetes并不是唯一的目标；其他目标体系结构（如serverless）会有不同的优势和限制，因此也需要不同的工具。

这份清单是不详尽的，其他的厂商还有Canonical, Cloudbolt, Fission,

GitLab, Google, Heroku, Jelastic, Kmesh, Kong, Kublr, Lightbend, Mesosphere, Mirantis, Octopus Deploy, Pivotal, Spinnaker, and Xebia Labs 但未包含在内。

Amazon EKS

考虑到AWS产品组合的广度，毫无疑问，Kubernetes是通过Amazon Elastic Container Service for Kubernetes Service(Amazon EKS)作为目标提供的，Kubernetes服务是Kubernetes上游100%的服务。为了满足自身 的需求，AWS专注于通过诸如CodeDeploy，CodePipeline和Jenkins X等工具来改进Kubernetes的部署。

在编排和管理方面，AWS Fargate也值得一提——这是AWS的serverless 容器计算平台，它提供了一个将容器部署到环境中的接口，使工程师能够专注于微服务，而不是底层的基础设施堆栈。此外，AWS App Mesh有助于管理和配置在Amazon ECS,Amazon EKS, AWS Fargate, 和 Amazon EC2 上运行的应用程序的服务间流量，例如，Kubernetes Pods间的互连和通信。

需要注意的是，EKS只是用于微服务编排的一个AWS容器目标：Amazon Elastic Container Service (ECS) 可能更适合某些工作负载———AWS的观点是，客户的需求不同，需要不同的选择满足这些需求。因此，AWS为云原生、混合云和介于二者之间的客户提供了选项。同样，AWS也有一些客户使用CodeStar工具部署到AWS之外的Kubernetes，例如，他们自己的数据中心。

Bitnami

Bitnami围绕应用程序打包建立了自己的商店，这个概念虽然针对未知论者，但却巧妙的将基于微服务的部署映射到Kubernetes的目标环境中。Bitnami提供了一个开源优先的模型，以及其增值产品Stacksmith。在背后，Bitnami的主要收入来源于云服务提供商，他们使用Bitnami预打包常见的应用程序的版本，如WordPress。

对于Kubernetes，公司维护了一系列用于Kuberetes预打包的应用程序（如 Helm charts），并提供Stacksmith，使得工程师团队能够配置、打包和维护自己的应用程序。他还提供了Kubeapps———一种基于web的工具，可以部署和管理部署到Kuberetes集群的应用程序。Kubeapps被广泛使用并简化了部署过程，但需要一定程度的体系结构专业知识。

在用例方面，公司的传统关注点一直是将现有应用程序”重新平台化”，这是一个既适合打包概念又适合微服务方法的功能———即使是相对复杂的应用程序也可以作为一个容器进行部署，既封装了它，又使附加功能能够围绕它构建。这种方法也有助于在不影响灵活性或控制的情况下，将IT环境置于管理之下。

CircleCI

CircleCI是一个持续集成、构建管理和部署的自动化平台，它不仅限于微服务，而且有一些有用的特性使得开发人员专注与目标环境。考虑到微服务部署往往以许多类似的、几乎相同的存储库配置结束，CircleCI创建了【检查】概念——预定义的、经过认证的配置脚本，可以与代码一起管理。

与”配置即代码”一样，供应商提供了一种灵活的分配模型，例如，开发者可以识别一个Docker镜像，设置机器大小，并将其包含在一个大的工作流中。

CloudBees

Cloudbees是与非常流行的配置管理工具Jenkins最密切相关的供应商。公司的Jenkins企业级软件提供了集成功能，使Kubernetes成为基于Jenkins的工作流的目标。基于Jenkins X，该公司提供基于GUI的自动化和管理工具，以使持续集成、交付、部署和存储任务更流畅。

在企业部署方面，Cloudbees以其简单性交付了它的能力。他们的目标是建立适当的防护措施，使软件能够保持持续的交付自动化和协作过程，同时仍然具有治理、可视性和洞察力。因此，Cloudbees主张采用价值流管理方法，在控制新风险的同时实现最佳效率。价值流管理是DevOps系列即将发布的报告的主题。

Codefresh

Codefresh为微服务和基于容器的应用程序提供了“从头开始”构建的CI/CD管道工具。它的策略是帮助组织加快DevOps采用过程，更快地进入Kubernetes，最大限度地减少部署的开销，然后管理目标环境。在云原生组织之外，Codefresh的许多客户都希望将遗留系统迁移到微服务体系结构。因此，功能超越了集成hooks，并面向企业意愿，尤其是与安全性相关的功能，如单点登录和基于角色的访问。

除了无缝部署和自动化之外，支持DevOps编排的Codefresh功能还包括可由用户修改的内置步骤和对特定处理器的支持。该公司还通过一个管理工具来提供运行中集群的概览，其中包括运维监控。另一个好处是帮助组织“左移”——例如，使用codefresh可以启用一次性部署进行测试，完成后关闭它；另一个例子是，在更广泛推出前，它只能用于启动需要测试的微服务。

Docker

Docker这家最初将我们称之为容器的公司并没有闲置，他们认识到容器只是拼图中的一部分，因此提供了Docker Enterprise Platform ，将安全和治理、编排和自动化结合在一起，并支持认证功能来支持企业级应用程序的交付。例如，DockerTrusted Registry管理和保护从开发到生产的容器镜像，Docker Universal Control Plane包括数据路由、身份验证和部署后的功能。

通过支持一系列基础设施，该公司拥有自己的编排产品（Swarm），但认识到Kubernetes周围的兴趣正在加速，并为其提供全面支持。例如，Docker Compose Yaml文件可以针对Swarm或Kubernetes部署；同时，Docker Desktop使工程师能够创建本地环境，并将应用程序部署到笔记本电脑上的Kubernetes。虽然Docker Enterprise Platform的大多数部署都是基于微服务的，但Docker还与希望将遗留应用程序迁移到容器的组织合作，其目标是在迁移之后“让它们继续存在”，或者使它们能够作为基于微服务的应用程序进行后续的重新组合和后续开发。

HashiCorp

HashiCorp提供“API驱动的动态环境变得简单”。HashiCorp的重点是使应用程序能够以自助服务的方式提供到动态基础设施上，例如支持Kubernetes的基于云的平台。虽然HashiCorp提供了自己的基于集群的微服务编排产品Nomad（它与Kubernetes竞争，尽管它也可以调度非容器化的工作任务），但该公司表示，它并没有区分不同的平台，其更大的目标是帮助组织采用微服务，无论它们使用哪个编排平台。

除了作为”基础设施即代码”的产品TerraForm外，该公司还为密码和密钥等敏感数据提供保险库，并为分布式应用程序管理和协调网络服务提供咨询服务。这些功能共同提供微服务方法的可扩展性，以及企业所需的基于策略的治理需求。HashiCorp于2018年10月宣布了Kubernetes对这些产品的支持。

在满足企业需求方面，HashiCorp致力于将组织从更线性、基于ITIL、构建—运营思维，向一个模型移动，在该模型中，开发、安全、网络、运营和其他团队使用一个通用工具平台，以基于服务的方法相互协作。

Microsoft

Azure Kubernetes Service是微软提供的几个目标平台之一，它受益于与其他目标相同的组件，例如通过Azure Active Directory进行访问控制、通过密钥库进行密钥管理、通过Azure Container Registry进行容器镜像管理和分发以及使用Azure Container Network Interface (CNI)进行网络策略管理。除了它自己的基础设施即代码工具（Azure Resources Manager）之外，该公司还利用HasiCorp TerraForm定义和部署kubernetes集群。

正如预期的那样，微软的DevOps为CI/CD的开发者提供了全面的支持。这包括跨计划和源代码控制、持续开发和集成、协作和信息共享，与预期范围的开放源代码和专有DevOps工作流工具集成，如用于构建管理的Jenkins、用于测试的Selenium和用于协作的Trello。同时，Azure Automation允许将”配置即代码”（基于PowerShell运行手册，越来越多地与第三方平台（如Chef或Ansible）协作）进行持续部署、所需的状态一致性检查以及为生产中的应用程序预先定义监控标准。

Puppet

Puppet用描述目标基础设施配置的“清单（manifests）”来表达“基础设施即代码”。虽然Puppet的历史性增长来自于网络规模的公司和初创企业，但近年来，该公司从企业公司那里看到了更多的吸引力，因为他们希望采用DevOps和基础设施自动化实践，将领先的目标环境和遗留系统结合起来。

Puppet对其定义的环境不可知，这使公司在客户寻求此类方法时，将自己的手转向容器（以及最近的serverless方法）成为一种自然的发展，但在大型机环境中工作也同样舒适。Puppet最初的前提是为系统管理员而不是开发人员解决问题，将系统管理员从日常操作的困境中释放出来，以便他们能够继续进行更有价值的活动。因此，从本质上讲，首要目标是发挥自动化的潜力。

特别关注Kubernetes，Puppet提供了Distelli，一个支持部署到Kubernetes集群和虚拟机的持续交付自动化平台。2018年12月，该公司发布了Puppet Enterprise产品的模块，以自动部署到Kubernetes和Helm。这些都得到了kream开发环境的支持，使工程师能够编写针对kubernetes的puppet代码。

Red Hat/Ansible

RedHat提供了Open Shift，一个Kubernetes的目标平台，可以方便部署、运维和管理。这可以部署在内部数据中心或云中，运行在Redhat Enterprise Linux之上。Red Hat Open Shift也可作为托管服务提供。同时，RedHat Ansible允许使用yaml对微服务容器进行打包和配置，CodeReady Workspaces提供了一个预构建的“Kubernetes原生”开发环境。

Red Hat为Knative做出了贡献，并为其宣传。Knative最初是一个用于部署到Kubernetes的Google云项目，现在作为开放源代码提供，由Pivotal、SAP、IBM和其他公司提供支持。Knative组件管理部署期间的数据路由、工作负载伸缩和构建协调等任务。

在帮助企业实现微服务之旅方面，Red Hat与传统组织和面向未来的组织合作。对于前一组来说，第一步是通过Ansible工具开始将”基础设施即代码”方法自动化。这可以与CodeReady Workspaces 配合使用，以帮助组织将基于微服务的方法作为一种规范，而不是一种例外。

Weaveworks

Weaveworks是专门关注kubernetes编排提供商的一个子集。Weaveworks的企业Kubernetes平台改进了开发人员管道元素，确保了云原生平台上的最佳实践。与Prometheus一起，Weave Cloud自动部署到Kubernetes目标环境中进行应用程序性能监控，这两个环境都作为完全管理的SaaS提供。Weaveworks提供了一个企业Kubernetes订阅，Weave Cloud可以用于部署到其他kubernetes发行版，如Open Shift。

在企业采用方面，Weaveworks专注于加速云原生方法，以满足那些希望更快速地开发应用程序但具有可靠性的组织，这得益于Kubernetes的扩展能力。产品和服务面向基础设施方面的运营商，重点关注如何将基于容器的平台的监控与现有的监控和管理功能集成在一起。在开发人员方面，公司提倡Gitops方法，即使用版本控制系统Git作为Kubernetes配置信息的“真实来源”。

6、主要好处

尽管这一领域有明显的复杂性，但它仍然受到一些简单原则的支持，这些原则映射到企业需要创新、以未来安全的方式采用技术、构建灵活和可扩展的面向客户的系统。为了帮助实现这些目标，希望采用数字优先的服务交付方法的组织可以

• 从新的体系结构开始。想想你正在尝试构建的软件，而不是你拥有的软件。Kubernetes是一个安全的目标，所以从体系结构上来说，你要注意：如果你足够努力，你可以使任何东西看起来像一个大型机。
• 不要试图一次就做到这一点。虽然战略可以而且应该是有远见的，但它也应该被视为建立在成功基础上的变革计划。不会有一夜之间的“数字转换”或任何其他简单的改变。
• 从一开始就衡量成功。成功取决于你的组织的发展方向，所以要相应地制定成功的衡量标准。虽然您可以衡量自己是否以正确的方式运营，但更重要的衡量标准将围绕业务价值。
• 将工具视为创新功能。当今的工具链和管道反映了市场的不成熟，因为几乎没有标准化，而且有大量的选择。考虑到可能很难决定支持哪一种工具，最重要的是定义将对任何特定工具的依赖性降至最低的工作流，或者方法。
  
  

归根结底，首先考虑一个目标体系结构为成功提供了一个起点。Kubernetes是一个快速出现的、经过大量测试的编排标准，它为那些希望首先通过流程和云平台实现数字化的组织提供了一个极好的起点。

7、附录：企业软件交付的历史和基础架构

几十年来，我们多次尝试寻找应用程序单元的“goldilocks”大小。在20世纪70年代（可能更早），像Ed Yourdon这样的行业知名人士会讨论在最小化耦合的同时最大化内聚的中间环节：即，确保应用程序代码的“模块”是独立的，对其他应用程序的依赖性最小。面向对象的概念也开始发挥作用，在这个过程中，Yourdon（和其他人）的概念可以与现实实体周围的结构代码相一致，其结果是创建软件单元：

• 易于部署
• 不太可能改变，就它们如何呈现给世界其他方面而言（即，它们的名字或界面而言）
• 能够在不影响其他软件单元的情况下进行更改
  
  

我们已经看到了各种迭代和尝试，从良好的编码实践（例如，三层体系结构和其他设计模式）到Web Services，以及专有的解决方案，例如支持企业Java bean（EJB）的应用服务器。

快进到90年代，我们看到摩尔定律在处理器能力方面达到了一个转折点。

在过去的几十年中，人们普遍认为工作负载将使用尽可能多的处理器资源：需要基本计算以外的任何东西的任务都会将单个机器推向极限。虽然不可能在千禧年之交之前在上面写上日期，但是处理器的功能已经足够强大，可以运行单一的，然后是多个硬件模拟器，每个模拟器都可以运行一个操作系统。这有两种方式：第一，大型机器可以更好地利用可用的周期；第二，较小的工作负载可以更好地分布在可用的服务器上。

一旦这种“虚拟机”模型变得流行起来，硬件和软件都可以进行优化，以尽量减少它造成的开销，例如，导致在芯片级别包含管理程序模型和虚拟化挂钩。虚拟化也是云计算的重要催化剂，它依赖于将高度标准化的硬件与运行在其上的代码分开的能力。

近年来，我们看到了这些需求的一些后果。随着基于容器的软件部署的到来，对“合适大小”的软件单元的持续需求找到了完美的合作伙伴，这种部署很快就成为软件分发的公认标准。开源方法的日益流行使得新的部署模型成为标准，特别是来自谷歌的Kubernetes。

因此，尽管这些原则和需求中的一些已经过时，但标准化的、非专有的机制的可用性还是相对较新的。企业现在可以着手在超大型环境中构建解决方案了。(转自亮哥）