基础设施即代码或云平台—由您决定！

基础设施即代码或云平台——由您决定！

翻译自 Infrastructure as Code or Cloud Platforms — You Decide! 。

了解两种流行的云基础设施管理方法。

让我们比较云基础设施管理的两种常见方法。首先是我们广泛归类为基础设施即代码（IaC）的方法，其中工程师使用编程/脚本语言构建一组脚本，以在云平台上实现所需的拓扑结构。 Terraform、Cloud Formation、Chef、Puppet 和 Ansible 是一些流行的工具。

这项技术由编写脚本的语言和可以运行脚本的控制器组成。一旦满意结果，用户将保存脚本在代码存储库中。随后，如果需要进行更改，则会编辑文件并重复相同的流程。

第二类是云编排器或平台。通常，这是对本地云 API 的轻量级抽象，作为 Web 服务与用户交互，用户将通过 UI 或 API 连接到该服务，并在该 Web 服务中构建云拓扑。

构建的拓扑将由编排器应用并保存在自己的数据库中。用户不需要显式保存配置。当必须进行更新时，用户将再次登录系统并进行更改。

对于规模较小的用例，使用平台可能太重了。但是在规模上，IaC 方法往往会演变成为内部平台。在这种情况下，更好的策略是使用现成的平台，在需要定制时可以使用 IaC 脚本进行增强。像 Facebook 和 Netflix 这样的大型数据中心是一种不同的情况，不在此上下文中考虑。

对于较小规模的用例，平台可能太重了。但在规模上，IaC 方法往往会演变成一个内部平台。在这种情况下，更好的策略是使用现成的平台，在需要定制时可以使用 IaC 脚本对其进行增强。属于 Facebook 和 Netflix 的超大规模数据中心是另一回事，因此不在本文考虑范围之内。

‘长时间运行的上下文’

平台化方法提供的基本价值是我们所谓的“长时间运行的上下文（long-running context）”。人们也可以称之为“项目”或“租户”。上下文可能映射到一个应用程序或一个环境，如演示、测试、生产或开发人员沙盒。在更新拓扑时，用户总是在这个上下文中操作。平台会将更新保存在该上下文的自己的数据库中，然后将其应用于云。简而言之：您始终可以保证该数据库中存在的内容是应用于云的内容。

在 IaC 方法中，这样的上下文并没有原生地提供，而是留给用户自己定义。通常，这可能会转化为“哪些脚本需要针对哪个上下文运行？”或者可能是代码库中表示给定租户或项目配置的文件夹。将上下文定义为代码集合更加困难，因为许多脚本可能在不同租户之间共享。因此，最终取决于开发人员对代码库的理解。

平台方法是解决这个问题的更具声明性的方法，因为它需要很少或没有编码，系统会根据意图生成代码，而无需了解低级实现细节。而在 IaC 的情况下，任何更改都需要对代码库有很好的理解，特别是在大规模操作时。在平台方法中，用户可以在几天后回来并登录到相同的上下文，而无需深入挖掘代码以了解之前做了什么，就可以继续之前的工作。

代码库与应用于云的内容之间的差异

两者之间的第二个根本区别在于，IaC 是一个多步骤过程（编写脚本、运行脚本并将其合并到仓库中），而平台是一个一步过程（登录到上下文并进行更改）。使用 IaC ，用户可能会更新脚本，但可能会忘记或推迟将其保存到代码仓库中。与此同时，另一个工程师可能已经为他们自己的拓扑做出了代码库的更改并进行了合并。现在，由于许多代码片段在两种用例中共享，第一个开发者可能会发现自己陷入了冲突，即使通过合并代码来解决，也会出现这种情况，即在云中运行的内容与代码库中的内容不同。现在，开发人员必须重新运行合并的代码进行验证，而忽略引起回归的可能性。为避免这种风险，我们现在需要在 QA 环境中测试脚本。

所有“其他”的东西

IaC 工具可以实现部署，但运行云软件的基础设施还有很多其他方面需要考虑。我们需要一个应用程序配置机制，一种收集和隔离每个应用程序日志和指标的方法，监控健康状况并提醒警报，创建审计追踪记录，以及一个身份验证系统来管理用户对基础设施的访问。有几个工具可以解决这些单独的问题，但需要将它们缝合在一起并集成到应用程序环境中。Kubernetes、Splunk、CloudWatch、Signalfx、Sentry、Elk 和 Oauth 提供商都是这些工具的例子。但是，如果开发人员想要以合理的规模运行，他们需要一个统一的“平台”来将所有这些内容整合在一起。这带我们到下一个重点。

很多基础设施即代码(IaC)实际上是一个自制的云平台

当与许多工程师交流时，我们听到了这样的观点：基础设施即代码结合 BASH 脚本甚至常规编程语言（如 Go、Java 和 Python）提供了克服上述挑战所需的所有钩子。当然，我同意这个观点。通过这种代码，你可以构建任何东西。但是，你可能正在构建已经存在的相同类型的平台。为什么不从现有平台开始，通过脚本添加自定义功能呢？

第二个观点是，基础设施即代码更灵活，允许进行深度定制，而在平台中，您可能必须等待供应商提供相同的支持。我认为随着我们技术的发展，到了汽车自动驾驶的程度——曾经被认为纯属幻想！——平台比它们被认为的要先进得多，并具有强大的机器生成技术，以满足大多数，如果不是全部，使用案例。此外，一个好的平台不会阻止用户通过脚本工具定制超出其自身范围的部分。一个设计良好的平台应该提供正确的钩子，以消耗在平台之外编写的脚本。因此，这个观点不能证明为大多数标准任务构建代码库的合理性。

“没有适合我们需求的平台”

这也是一个常见的论点。我同意：一个好的平台应该努力解决这个普遍存在的问题。在 DuploCloud，我们相信我们已经构建了一个平台，解决了大多数使用情况，同时赋予开发人员能力，将在系统外创建和管理的策略集成到系统内部。

‘圣马特奥(San Mateo)线！’

一种有点令人惊讶的支持自主构建平台的论点是，对于工程师来说，这只是一个非常酷的项目，特别是对于那些来自系统背景的工程师。我住在硅谷，并发现在与这个地区的客户交谈时有一个非常有趣的趋势。

当我们与基础设施工程师交谈时，我们发现他们更强烈地想要在内部构建平台，并且他们非常清楚地知道他们正在为他们各自的组织构建一个“平台”，而不是像他们认为的那样“编写脚本”。对于这样的公司来说，定制化是反对现成工具的常见论点，而混合云和本地部署是重要的使用案例。像 Kubernetes ， Consul 等开源组件是常见的，因此我经常听到认为不必重新发明轮子的说法。然而，团队规模和为解决方案分配的时间相当大。在某些情况下，构建平台的重点会掩盖公司本应销售的核心业务产品。虽然不完全科学，但我倾向于在圣马特奥以南的地区看到这些公司。

这些公司的工程师们则更多地专注于纯软件即服务应用程序的开发。这些应用程序使用了很多本地云软件，例如 S3、Dynamo、Amazon Simple Queue Service (SQS) 和 Amazon Simple Notification Service (SNS)，因此很难采用混合云。他们很乐意通过 API 或 UI 将容器交给 Amazon Elastic Container Service (Amazon ECS) 来部署，而且不喜欢部署或学习 Kubernetes。因此，他们内部定制的趋势和深度要少得多。

多少次，多少人会写同样的代码来实现同样的功能？最终上市时间会占上风。