Datawire团队最近的一次交流，是关于“PaaS”这一术语的真正含义，以及它与开发人员体验(DevEx)和工作流之间的关系，带来了许多可以分享的内部对话。从和客户一起工作，到会议上与人的聊天中，我感觉到，其他团队对于部署应用程序时“平台”和工作流之间的关系也有些不确定，我希望以建设性的方式，能提供一些清晰的认知，或者至少能够学到一些东西。
基础设施、平台、工作流三者缺一不可
Daniel Bryant是一名独立的技术顾问，专注于通过价值流识别、管道的创建和有效的测试策略实施，来实现组织内的持续交付。Daniel的技术专长在于DevOps工具、云/容器平台和微服务实现。他还参与了几个开源项目，为InfoQ、O 'Reilly和Voxxed撰稿，并定期出席OSCON、QCon和JavaOne等国际会议。
从基本原则开始说起，所有基于web的软件开发都涉及到三层：
基础设施：这一层提供原始计算资源的抽象，如裸金属、vm、操作系统、网络、存储等，这些资源最终将负责处理与应用程序相关的代码和数据。这里避免使用“物理”这个术语，因为尽管所有的东西最终都是在硬件上运行的，但是我们越来越多地看到基础设施的抽象转移到软件定义的所有东西(Software-Defined-Everything，SDx)。
平台：这一层提供了粗粒度的系统级构建块，它可能是运行时特定的，比如一个集成的JVM或CLR的计算实例，还有数据存储、中间件、IAM、审计等等。值得一提的是，相信你总是将应用程序部署到某种形式的平台上，即使没有有意识地组装它。
工作流：这一层是如何设计、构建、测试、部署、运营应用程序的总和。每个开发人员都有一个工作流(即使它是隐性的)，从个人的独立网站构建者，到一个在复杂的企业系统中工作的数千人团队。
当我和朋友和客户谈论这个模型时，我通常会就概念和结构达成某种形式的协议。当开始讨论这些概念之间的耦合时，特别是与PaaS有关时，分歧就开始了。
这些是你正在寻找的平台
我经常听到“PaaS有一个内置的工作流程”，或者“如果你正在运行一个PaaS，那么你不需要知道基础设施。”我并不特别同意这些说法，并且在努力建立共同的理解。PaaS经历了几代模式的发展：
第一代：Heroku和它的朋友们。这种类型的PaaS隐藏了底层云基础设施（通过可部署的slugs和“Dynos”），并提出了非常有见地的工作流程，与平台耦合。对于简单的单体Ruby应用程序，这非常棒，可以在几分钟内熟练部署工作流程，并且所有知识都可以转移到下一个项目复用。
第二代：Cloud Foundry（DEA版）和它的朋友们。这种类型的PaaS可以部署在企业的基础设施上，并且带来企业自己的buildpacks和运行时。工作流仍然集成在一起，但是该平台开始通过上下文路径路由（context path routing ）等概念启用多服务应用程序（和工作流程）。
第三代：Cloud Foundry（Diego版）以及当前版本的Google App Engine和AWS Elastic Beanstalk（两者分别从第一代和第二代PaaS演变而来）。这些PaaS对基础架构的依赖更低，企业可以携带自己的容器，并且文档清楚了解运行时和计算环境的限制。这里的工作流程正在转向支持分布式系统（微服务），并鼓励开发人员从目前“推荐的做法”中构建自己的持续交付管道的工作流程，可能使用Concourse或Spinnaker等工具。
第四代：Kubernetes，Docker Swarm，Mesos，HashiCorp Nomad，AWS ECS等等（我明白这些并不是真正的PaaS）。这种类型的平台基础设施是不可知的。谁没有参加过会议并且看到Kubernetes在Raspberry Pi集群上运行？而且总是接触到构成集群的底层计算和网络基础设施（AWS Fargate例外）。也可以部署任何类型的容器或流程。这个平台出现了构建“云原生”应用的愿望，这些应用程序本质上是分布式的。这里的“最佳实践”工作流程尚未定义，或者更准确地说，目前仍与技术协同发展 - 并且我们正在对CI / CD进行最新的了解并改进。
因此，这是一个有趣的开源和商业工具正在出现的领域：想一下Datawire的Forge和Telepresence 工作流工具，Ambassador的交通转移/部署，Weaveworks的Flux和Scope，Heptio和Bitnami的ksonnet，微软的Draft 和 Helm，Containous traefik负载均衡器/ API网关。
我相信平台与工作流程耦合之间产生了混淆，因为很多企业部署了粗粒度（单体？）风格的应用程序，其中工作流与平台紧密结合。即第一代和第二代PaaS，或者工作流松散耦合，但定义明确，我们没有注意到这种摩擦 - 即在传统基础架构或第三代PaaS上构建和部署特定语言的组件。
第四代平台面临挑战，技术仍在成熟，架构及相关组织最佳实践也在共同发展中--分别考虑微服务和无服务器，以及 inverse Conway maneuver。业务对速度，稳定性和可见性的压力也越来越大，这通常是通过将业务流程（形成跨职能业务部门）分解并将决策权下放给一线工作团队来实现的。这以商业运动为代表，例如 holacracies 和 Teal organizations。
回顾上面的软件开发层面，需要指出的一个关键点是，基础设施和平台正在变得越来越分散和分离，但它们是通过集中化的力量实现的 - 例如基础设施中的AWS，以及平台中的Kubernetes（Apps SIG）社区，它定义了常用的协议，标准和接口。工作流程也变得分散，但我认为现在还没有集中的力量，即一种通用的描述性语言，一套工具和预定义（可插入）的工作流程步骤。
随着拥抱Kubernetes的组织越来越多，团队创建定制的开发者体验工作流程，通常在单个组织内的团队中存在差异，导致解决方案很脆弱，以及有限的共享学习。这些团队试图将他们的工作流程编写成最终在Kubernetes之上建立一个平台。部署到平台上至关重要，但平台和工作流的概念应该分开考虑和设计。紧密耦合平台和工作流程会导致不灵活的开发人员工作流程。
相信Kubernetes的“平台”在2018年已经变得越来越清晰。Kubernetes本身已经很好地成熟了，而Envoy，Conduit和Cilium等公司的服务网格正在填补平台的一些缺失的部分。但是，围绕开发人员的体验还有很多想法需要去做。我们看到Weaveworks GitOps和Atlassian BDDA（Build-Diff，Deploy-Apply）等方法论中将最佳实践编纂在内，相信在应用程序开发（AppDev）领域会出现类似的东西。
Kubernetes可能会接管应用程序的整个生命周期
今天形成了Kubernetes无处不在的云原生景观。三家主要云提供商，AWS、Google和微软Azure都支持Kubernetes，甚至Docker和Cloud Foundry也在使用它。
是什么使Kubernetes独一无二？传统意义上，通常是开源技术创造了商品化的产品替代主流闭源技术。 但Kubernetes一直是个例外。 “Linux是UNIX的竞争者，Apache web服务器是Apache IIS的竞争对手。那么谁是Kubernetes的竞争对手？并没有与之竞争的闭源产品，”CoreOS首席技术官兼联合创始人Brandon Philips 说。
实质上，Kubernetes在与人们创建的所有脚本进行竞争，以将他们在笔记本电脑上开发的源代码部署到生产环境中。有成千上万的方法可以做到这一点：CI / CD工作流程，bash脚本，配置管理工具等。为了获得生产所需的所有东西，数周的开发一直是个痛苦的周期。这就是Kubernetes来拯救的地方。它通过创建 API 来缩短这个周期，提供了适用于任何类型的一致性和可重复性。
“这是Kubernetes的重点，”Philips表示，“随着时间的推移，我们可能会接管应用程序的整个生命周期，从idea到监控到应用程序工作流程，到最终退出应用程序。我们已经看到用户在扩展Kubernetes api。Philips认为，这将继续，“天空是我们所依赖的抽象的极限。 “看看它在未来几年的发展将会很有趣。”
原文链接：
1、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow
https://thenewstack.io/kubernetes-paas-force-developer-experience-workflow/
2、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications
https://thenewstack.io/time-kubernetes-may-take-entire-lifecycle-applications/
Datawire团队最近的一次交流，是关于“PaaS”这一术语的真正含义，以及它与开发人员体验(DevEx)和工作流之间的关系，带来了许多可以分享的内部对话。从和客户一起工作，到会议上与人的聊天中，我感觉到，其他团队对于部署应用程序时“平台”和工作流之间的关系也有些不确定，我希望以建设性的方式，能提供一些清晰的认知，或者至少能够学到一些东西。
基础设施、平台、工作流三者缺一不可
Daniel Bryant是一名独立的技术顾问，专注于通过价值流识别、管道的创建和有效的测试策略实施，来实现组织内的持续交付。Daniel的技术专长在于DevOps工具、云/容器平台和微服务实现。他还参与了几个开源项目，为InfoQ、O 'Reilly和Voxxed撰稿，并定期出席OSCON、QCon和JavaOne等国际会议。
从基本原则开始说起，所有基于web的软件开发都涉及到三层：
基础设施：这一层提供原始计算资源的抽象，如裸金属、vm、操作系统、网络、存储等，这些资源最终将负责处理与应用程序相关的代码和数据。这里避免使用“物理”这个术语，因为尽管所有的东西最终都是在硬件上运行的，但是我们越来越多地看到基础设施的抽象转移到软件定义的所有东西(Software-Defined-Everything，SDx)。
平台：这一层提供了粗粒度的系统级构建块，它可能是运行时特定的，比如一个集成的JVM或CLR的计算实例，还有数据存储、中间件、IAM、审计等等。值得一提的是，相信你总是将应用程序部署到某种形式的平台上，即使没有有意识地组装它。
工作流：这一层是如何设计、构建、测试、部署、运营应用程序的总和。每个开发人员都有一个工作流(即使它是隐性的)，从个人的独立网站构建者，到一个在复杂的企业系统中工作的数千人团队。
当我和朋友和客户谈论这个模型时，我通常会就概念和结构达成某种形式的协议。当开始讨论这些概念之间的耦合时，特别是与PaaS有关时，分歧就开始了。
这些是你正在寻找的平台
我经常听到“PaaS有一个内置的工作流程”，或者“如果你正在运行一个PaaS，那么你不需要知道基础设施。”我并不特别同意这些说法，并且在努力建立共同的理解。PaaS经历了几代模式的发展：
第一代：Heroku和它的朋友们。这种类型的PaaS隐藏了底层云基础设施（通过可部署的slugs和“Dynos”），并提出了非常有见地的工作流程，与平台耦合。对于简单的单体Ruby应用程序，这非常棒，可以在几分钟内熟练部署工作流程，并且所有知识都可以转移到下一个项目复用。
第二代：Cloud Foundry（DEA版）和它的朋友们。这种类型的PaaS可以部署在企业的基础设施上，并且带来企业自己的buildpacks和运行时。工作流仍然集成在一起，但是该平台开始通过上下文路径路由（context path routing ）等概念启用多服务应用程序（和工作流程）。
第三代：Cloud Foundry（Diego版）以及当前版本的Google App Engine和AWS Elastic Beanstalk（两者分别从第一代和第二代PaaS演变而来）。这些PaaS对基础架构的依赖更低，企业可以携带自己的容器，并且文档清楚了解运行时和计算环境的限制。这里的工作流程正在转向支持分布式系统（微服务），并鼓励开发人员从目前“推荐的做法”中构建自己的持续交付管道的工作流程，可能使用Concourse或Spinnaker等工具。
第四代：Kubernetes，Docker Swarm，Mesos，HashiCorp Nomad，AWS ECS等等（我明白这些并不是真正的PaaS）。这种类型的平台基础设施是不可知的。谁没有参加过会议并且看到Kubernetes在Raspberry Pi集群上运行？而且总是接触到构成集群的底层计算和网络基础设施（AWS Fargate例外）。也可以部署任何类型的容器或流程。这个平台出现了构建“云原生”应用的愿望，这些应用程序本质上是分布式的。这里的“最佳实践”工作流程尚未定义，或者更准确地说，目前仍与技术协同发展 - 并且我们正在对CI / CD进行最新的了解并改进。
因此，这是一个有趣的开源和商业工具正在出现的领域：想一下Datawire的Forge和Telepresence 工作流工具，Ambassador的交通转移/部署，Weaveworks的Flux和Scope，Heptio和Bitnami的ksonnet，微软的Draft 和 Helm，Containous traefik负载均衡器/ API网关。
我相信平台与工作流程耦合之间产生了混淆，因为很多企业部署了粗粒度（单体？）风格的应用程序，其中工作流与平台紧密结合。即第一代和第二代PaaS，或者工作流松散耦合，但定义明确，我们没有注意到这种摩擦 - 即在传统基础架构或第三代PaaS上构建和部署特定语言的组件。
第四代平台面临挑战，技术仍在成熟，架构及相关组织最佳实践也在共同发展中--分别考虑微服务和无服务器，以及 inverse Conway maneuver。业务对速度，稳定性和可见性的压力也越来越大，这通常是通过将业务流程（形成跨职能业务部门）分解并将决策权下放给一线工作团队来实现的。这以商业运动为代表，例如 holacracies 和 Teal organizations。
回顾上面的软件开发层面，需要指出的一个关键点是，基础设施和平台正在变得越来越分散和分离，但它们是通过集中化的力量实现的 - 例如基础设施中的AWS，以及平台中的Kubernetes（Apps SIG）社区，它定义了常用的协议，标准和接口。工作流程也变得分散，但我认为现在还没有集中的力量，即一种通用的描述性语言，一套工具和预定义（可插入）的工作流程步骤。
随着拥抱Kubernetes的组织越来越多，团队创建定制的开发者体验工作流程，通常在单个组织内的团队中存在差异，导致解决方案很脆弱，以及有限的共享学习。这些团队试图将他们的工作流程编写成最终在Kubernetes之上建立一个平台。部署到平台上至关重要，但平台和工作流的概念应该分开考虑和设计。紧密耦合平台和工作流程会导致不灵活的开发人员工作流程。
相信Kubernetes的“平台”在2018年已经变得越来越清晰。Kubernetes本身已经很好地成熟了，而Envoy，Conduit和Cilium等公司的服务网格正在填补平台的一些缺失的部分。但是，围绕开发人员的体验还有很多想法需要去做。我们看到Weaveworks GitOps和Atlassian BDDA（Build-Diff，Deploy-Apply）等方法论中将最佳实践编纂在内，相信在应用程序开发（AppDev）领域会出现类似的东西。
Kubernetes可能会接管应用程序的整个生命周期
今天形成了Kubernetes无处不在的云原生景观。三家主要云提供商，AWS、Google和微软Azure都支持Kubernetes，甚至Docker和Cloud Foundry也在使用它。
是什么使Kubernetes独一无二？传统意义上，通常是开源技术创造了商品化的产品替代主流闭源技术。 但Kubernetes一直是个例外。 “Linux是UNIX的竞争者，Apache web服务器是Apache IIS的竞争对手。那么谁是Kubernetes的竞争对手？并没有与之竞争的闭源产品，”CoreOS首席技术官兼联合创始人Brandon Philips 说。
实质上，Kubernetes在与人们创建的所有脚本进行竞争，以将他们在笔记本电脑上开发的源代码部署到生产环境中。有成千上万的方法可以做到这一点：CI / CD工作流程，bash脚本，配置管理工具等。为了获得生产所需的所有东西，数周的开发一直是个痛苦的周期。这就是Kubernetes来拯救的地方。它通过创建 API 来缩短这个周期，提供了适用于任何类型的一致性和可重复性。
“这是Kubernetes的重点，”Philips表示，“随着时间的推移，我们可能会接管应用程序的整个生命周期，从idea到监控到应用程序工作流程，到最终退出应用程序。我们已经看到用户在扩展Kubernetes api。Philips认为，这将继续，“天空是我们所依赖的抽象的极限。 “看看它在未来几年的发展将会很有趣。”
原文链接：
1、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow
https://thenewstack.io/kubernetes-paas-force-developer-experience-workflow/
2、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications
https://thenewstack.io/time-kubernetes-may-take-entire-lifecycle-applications/
913
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
