平台工程的兴起
微服务、容器编排等的兴起带来了新的工程挑战。许多组织已经组建了平台工程团队来承担这些责任。在某些方面，平台工程师的角色并没有与其他DevOps相关角色有很大的不同。注意到“平台工程师”这个头衔只不过是一个新的头衔，这是有道理的。然而，许多因素正在并将继续导致站点可靠性工程师(SRE)的传统职责转移。
这些因素包括云提供商、Kubernetes和作为代码的基础设施的日益普及和可扩展性。由这些因素引入的范例为组织带来了许多超能力，例如服务发现和轻松地横向扩展的能力，这可能会带来更多的银行资金。
拥有传统基础设施的成熟公司正在动员起来，为向云的大规模迁移做准备，云提供商也准备张开双臂接受它们。但是，随之而来的是对云和容器编排方面的专业知识的需求。因此，组织开始质疑他们是否应该组建一个平台工程团队。在云出现之前或云期间最近诞生的公司没有那么多这样的顾虑；要与之抗衡的遗留系统(如果有的话)更少。对于公司来说，开始并保持在云提供商那里而从未管理过本地系统的情况非常常见。
正如前面提到的，“平台工程师”这个角色被一些人认为只是对传统上由基础设施团队执行的工作的不同称谓。为了理解为什么这不是完全正确的，让我们更仔细地看看今天的平台工程是什么样子的。
这是一个很难回答的问题。问十个工程师同样的问题可能会得到十个不同的答案。也就是说，可能会有许多类似的主题。最突出的主题可能类似于弥合软件和硬件之间差距的想法。换句话说，平台工程师使应用程序开发人员能够更轻松地将软件交到用户手中。这一宽泛的笔触以许多不同的方式表现出来。其中一些方法可能是标准化组织的Kubernetes部署，确保基础设施是可审计的，自动化各种部署过程，以及为应用程序开发人员编写文档。
平台工程团队的职责不应与DevOps团队的职责混为一谈。它们在某些方面相似，尽管在其他方面有所不同。检查平台工程和DevOps的不同之处可以帮助解释这个新团队越来越受欢迎的原因。首先，DevOps的概念早于平台工程的概念，并与技术进步同步成熟。最初，DevOps是相当特别的。例如，如果组织内的某个团队想要托管一个新网站，则该团队与DevOps团队之间的协调是必要的。将这与平台工程的概念进行对比。平台工程师构建的系统允许团队在此基础上进行构建。继续这个例子，如果同一个团队有一个负责托管网站的平台，那么这个团队和平台工程团队之间就不需要协调了。
另一个重要区别是API边界的角色，以及该边界在每个角色的职责上下文中的显式程度。这与DevOps倾向于比平台工程更特别的建议是一致的。DevOps和平台工程团队关注部署、服务客户和基础设施。然而，DevOps团队没有构建为应用程序开发人员提供显式API和抽象的平台；平台团队正在构建这些类型的平台。
为了进一步描述平台工程在组织中扮演的角色，让我们考虑一个示例。假设一家成立于20世纪80年代的保险公司已经开始将其基础设施转移到云端。现在，假设在该组织中，软件工程师分为两类：应用程序开发和基础设施。在云时代之前，基础设施工程师类似于提供API的后端团队是很常见的。
这些职责通常通过使用基础设施即代码(IAC)来履行。作为代码工具的一些常见基础设施有Terraform、Vagant、Chef、Puppet和AWS CloudForment。这些工具中有许多是开源的。平台工程师搭建的平台一般都是由这些开源工具组成的。组织的平台工程师将基础设施作为代码工具进行定制，以满足组织的应用程序开发人员的需求。下图说明了作为代码和平台工程师的基础设施如何融入开发团队，以及这些工具最终是如何产生更多功能的。
基础设施即代码是帮助提升集体良知中的平台工程师概念的众多因素之一。但是，它支撑了这些额外因素中的许多，所以它值得更仔细地研究。在基础设施作为代码的时代之前，人类必须手动配置基础设施。
回过头来看，手动配置基础架构是有问题的；人为错误的因素总是有风险的。人类比计算机更容易出错，也更昂贵。哦，而且人类的速度要慢几十亿倍。基础架构作为代码消除了人为错误的风险，降低了成本，并提高了组织内团队迭代的速度。参与系统过程的人越少越好。
基础设施作为代码的一个显著好处是它能够签入到版本控制中。这对于可能正在快速提升云基础设施的企业尤其有益。版本控制平台，如GitHub，通过促进和记录变更以及同样重要的审核过程，为系统的基础设施提供上下文。GitHub的Pull请求审查流程就是一个很好的例子；它是一个可以进行讨论的地方。这种类型的审查是否适用于所有类型的Pull请求都是值得商榷的。但是，对于作为代码的基础设施来说，这是一个巨大的好处。
与许多技术一样，将基础设施作为代码使用也有不同的方法。最常见的是声明性模型和命令性模型。声明性框架(如Kubernetes提供的框架)要求用户定义所需的状态。用户不指定应如何实现此状态。在声明性模型中，系统制定达到并维护指定状态的计划。命令性框架要求用户以特定的顺序指定命令，以达到所需的状态。
起初，命令式模型可能更直观，因为许多流行的编程语言都被认为是过程化的，比如Go。但是，这并不是将基础设施作为代码的流行方法。首先，命令性模型不具有可伸缩性。复杂性最多与系统中的组件数量呈指数级增长；用户必须以正确的顺序为更多的计算机执行正确的命令。将此与声明性模型进行对比：用户描述所需的结束状态。然后，框架有责任制定并执行一项计划，以达到这一期望状态。复杂性与系统中组件的数量成对数关系，或者至少远好于线性关系；框架负责所有繁重的工作。
在某些情况下，命令性模型提供的灵活性比抽象它的声明性模型更可取。值得庆幸的是，有一些工具可以提供将基础设施作为代码的命令性方法，从而将复杂性降至最低，例如Terraform、Vagant和CloudForment。如果您有兴趣了解有关这些技术的更多信息，请查看本期“软件工程日报”。本期节目是与Hashicorp创始人米切尔·哈西莫托(Mitchell Hasimoto)的对话，讨论应用程序开发以及为什么自动化的重要性随着基础设施的复杂性而变化。
在考虑构建平台工程团队时，组织通常会考虑一些权衡。一方面，构建平台工程团队减损了构建业务逻辑和开发功能的资源。但是，平台工程团队可能会构建工具和基础设施来提高工程生产力。如果没有合适的平台团队，很可能是一些工程师自己承担了类似平台工程师的角色。在组织上，这可能会成为一项挑战，并给组织中的所有工程师带来负担。如果没有一组明确的工程师负责组织的平台，流氓工程师在平台工程能力中的行为可能不会有效。简而言之，考虑建立一个平台工程团队可以被认为是权衡短期收益和长期收益。
建立平台工程团队说起来容易做起来难。以下内容可能会让生活在旧金山湾区的读者大吃一惊：遗留基础设施在企业组织中很常见，可能会导致很多关于平台工程的混乱。在云时代成立的初创公司的平台工程看起来与云时代之前的企业的平台工程有很大的不同。与云时代诞生的初创公司不同，许多云时代之前的企业拥有尚未迁移到云上的本地系统。此外，似乎迁移到云还不够有挑战性，云时代之前的企业往往会有更多的繁文缛节和官僚作风阻碍组织变革。创建平台工程团队的短期不利因素可能会被这些类型的组织障碍放大。
组织应该考虑创建平台工程团队可能造成的短期损失。观察到不同的产品团队构建相似的功能或试图完成相似的任务，这是一个强烈的迹象，表明一个组织的平台工程团队将是有益的。如果成立了平台团队，产品团队可以体验到生产力的提高。平台工程之所以有趣，是因为它可以提高整个组织的效率。在注销对平台工程团队的需求之前，应该考虑到这一点。
如果企业组织确实组建了平台团队，那么继续或开始迁移到云的努力几乎是不可避免的。迁移到云迫使组织选择使用哪个或多个云供应商。让我们研究一下使用单个云供应商(而不是多个云供应商)之间的选择可能会对组织产生什么影响。
制定云战略的第一步是确定是否需要多云战略。最好的多云战略可能是不使用不同供应商的服务，而是接受所有必须提供的服务。当然，使用单一云提供商是有缺点的，但事实证明，它比任何多云方法都要简单得多。这并不是说使用多云的好处没有超过使用单一云供应商的简单性。检查多云架构的优点和缺点可以阐明多云可能会如何影响给定的组织。
采用多云的好处包括能够为给定任务使用可用的最佳服务，并限制任何给定地理区域的停机风险。多云倡导者最常吹捧的好处是它提供的自由：您不会被限制在任何单一供应商的生态系统中。供应商锁定是指供应商是组织的依赖项之一，不能替代替代解决方案。令人担忧的是，用一种依赖关系替代另一种依赖关系的相关工作成本太高。
人们可以用不同的方式来解释云供应商锁定的概念。一方面，使用单一供应商的组织可能会认为关键服务低于标准，并想要另一种选择。或者，假设这项关键服务的成本开始高于预期。在这种情况下，很难决定下一步应该是什么。然而，有人可能会说，这项服务实际上对组织来说并不重要。流行的云供应商提供各种各样的产品；所谓的关键服务可以简单地替换掉。此外，这些云供应商还提供了平台迁移指南。
是的，使用多云有一些好处。这也有一些不利之处。缺点之一是组织结构更加复杂，这一点很难否认。例如，必须管理每个平台的安全帐户。除了组织复杂性之外，很难找到精通多个云平台的工程师。如果部署了多云系统，可能需要为新员工分配更多的上线时间。多云环境的另一个缺点是增加了潜在威胁的表面积。根据组织处理的数据类型，组织可能会以不同的方式权衡这一不利因素。但是，一般来说，假设您的组织重视安全性是安全的。
为了结束对多云选项的研究，让我们更仔细地了解一下仅使用单个云的情况。当然，存在锁定和无法为给定任务使用最佳服务的风险。然而，在许多情况下，使用一个云供应商可以极大地简化系统。在云供应商上全力以赴将不可避免地减少组织和工程开销。云的独特产品和功能是选择供应商的主要原因，而不是选择多个云供应商中最不常见的一个。最后，担心一个零件是否
在本期“软件工程日报”中，亚马逊的首席技术专家Abby Fuller指出，“…。民间(组织)总要有现代化的规划。“。总的来说，现代化计划在所有行业无处不在，但它们往往对正在使用的技术升级产生影响。企业组织对现代化的需求源于许多因素，所有这些因素都与云计算的兴起有很强的联系。这些因素包括大数据的兴起，微服务的日益普及，以及容器编排空间Kubernetes背后的动能。
容器编排的概念及其困难催生了库伯内斯。库伯内斯赢得了管弦乐之战。这使得工程师可以发展可转移的技能。Mindshare继续围绕Kubernetes构建，许多云之前的组织已经开始迁移到Kubernetes。因此，许多迁移到云并使用微服务的组织都在考虑使用Kubernetes作为他们的容器编排框架。它不仅简化了容器编排过程，还可以吸引更多对前沿技术感兴趣的开发人员。这群开发人员往往对那些对将更多的基础设施迁移到云上感兴趣的前云组织很有吸引力。
组建平台工程团队是组织开始实现其工程文化现代化的一种方式。前面提到的趋势，比如云供应商的突出地位和向微服务架构的转变，使得组建平台工程团队变得更加有吸引力。但是，工程文化的现代化也可以通过其他方式来实现。不能为了拥有平台工程团队而创建平台工程团队。与技术领域的大多数事情一样，这要视情况而定。
一篇文章很可能不足以让组织形成关于平台工程团队是否有益的强烈意见。建立和维护对技术环境的认识可以帮助组织形成更强的观点。如果您有兴趣更多地了解软件平台在组织中的角色，请查看软件工程日报的这一集，其中介绍了Cruise的平台工程方法。