本文来自微信公众号“开源云中文社区”。
让我们比较一下两种流行的云基础设施管理方法。
第一类是基础设施即代码（IaC），工程师使用编程/脚本语言构建一组脚本，以在云平台上实现所需的拓扑结构。Terraform、Cloud Formation、Chef、Puppet和Ansible是其中受欢迎的产品。
这项技术包括一种编写脚本的语言，以及一个可以运行脚本的控制器。一旦对结果感到满意，用户就会将脚本保存在代码存储库中。随后，如果要进行更改，则会对文件进行编辑，并重复相同的过程。
第二类是云编排器或平台。这通常是原生云API上的精简抽象，它将作为web服务与用户交互，用户连接到该服务（通过UI或API）并在该web服务本身中构建云拓扑。
构建的拓扑将由编排器应用，并保存在其自己的数据库中。用户不需要显式保存配置。当必须进行更新时，用户将再次登录到系统并进行更改。
对于较小规模的用例，平台可能太重。但在大规模应用时，IaC方法往往会演变成一个内部平台。在这种情况下，更好的策略是使用现成的平台，当需要定制时，该平台可以通过IaC脚本进行增强。像Facebook和Netflix这样的大型数据中心是另一回事，在此不考虑。
“长期运行的上下文”
基于平台的方法提供的基本价值是我们所说的“长期运行的上下文”。人们也可以称之为“项目”或“租户”。上下文可以映射到应用程序或环境，如演示、测试、产品或开发人员沙盒。当对拓扑进行更新时，用户总是在这种上下文中进行操作。在将更新应用于云之前，该平台将在此上下文中将更新保存在自己的数据库中。简而言之：总是可以保证这个数据库中存在的内容就是应用于云的内容。
在IaC方法中，这样的上下文不是原生提供的，而是留给用户。通常，这会转化为类似“需要为哪个上下文运行哪些脚本？”的内容，或者可能转化为代码库中代表给定租户或项目配置的文件夹。将上下文定义为代码集合比较困难，因为许多脚本可能在租户之间是通用的。因此，最有可能归结为开发人员对代码库的理解。
平台是解决这个问题的一种更具声明性的方法，因为它只需要很少或根本不需要编码，因为系统将根据意图生成代码，而不需要了解低级实现细节。同时，在IaC的情况下，任何更改都需要对代码库有很好的理解，尤其是在大规模操作时。在平台方法中，用户可以在几天后返回并登录到同一上下文，然后继续之前停止的地方，而不必深入研究代码来理解以前做了什么。
代码库和应用到云之间的差异
两者之间的第二个根本区别是，IaC是一个多步骤的过程（编写脚本、运行脚本并在存储库中合并），而平台是一个一步的过程（登录上下文并进行更改）。使用IaC，用户可能会更新脚本，但也可能会忘记或推迟将其保存在存储库中。与此同时，另一位工程师本可以为他们自己的拓扑对代码库进行更改并将其合并。现在，由于这两个用例共享了许多代码，第一位开发人员可能会发现自己陷入了冲突，即使通过合并代码来解决，也会使他们陷入云中运行的内容与存储库中的内容不同的境地。开发人员必须重新运行合并后的代码进行验证，尽管可能会导致回归。为了避免这种风险，需要在QA环境中测试脚本。
其他
IaC工具将支持部署，但运行云软件的基础设施还有很多。需要一种应用程序供应机制，一种收集和隔离每个应用程序的日志和指标、监控运行状况和发出警报、创建审计跟踪以及管理用户对基础设施的访问的身份验证系统的方法。有几种工具可以解决这些单独的问题，但它们需要缝合在一起并集成到应用程序上下文中。Kubernetes、Splunk、CloudWatch、Signalfx、Sentry、Elk和Oauth提供商都是这些工具的示例。但如果开发者想以合理的规模运营，需要一个连贯的“平台”来将所有这些结合在一起。
IaC的大部分基本上是一个本土的云平台
在与许多工程师交谈时，我们听到这样的观点，即基础设施即代码与Go、Java和Python等常规编程语言的BASH脚本相结合，提供了克服上述挑战所需的所有钩子。有了这种代码，可以构建任何东西。然而，可能正在构建与现有平台相同的平台。为什么不从现有的平台开始，通过脚本添加自定义？
笔者听到的第二个论点是，“基础设施即代码”更灵活，允许深度定制，而在平台中，可能需要等待供应商提供相同的支持。笔者认为，随着技术上的进步，平台比人们所认为的要先进得多，并且具有出色的机器生成技术，即使不是全部，也能满足大多数用例。此外，一个好的平台不会阻止用户通过脚本工具自定义超出其范围的部分。一个设计良好的平台应该提供正确的钩子来使用在平台之外编写的脚本。因此，这个论点并不能证明为大多数标准任务构建代码库是合理的。
“没有适合我们需求的平台”
这也是一个常见的论点。笔者同意：一个好的平台应该努力解决这个普遍存在的问题。DuploCloud平台，可以解决大多数用例，同时让开发人员能够集成系统外创建和管理的策略。
有一个有点令人惊讶的支持构建本土平台的论点是，对于工程师来说，这只是一个非常酷的项目，尤其是如果这些工程师来自系统背景的话。笔者住在硅谷，在与该地区的客户交谈时发现了一个非常有趣的趋势。
当与基础设施工程师交谈时，我们发现他们更强烈地希望在内部构建平台，而且他们非常清楚，他们正在为各自的组织构建一个“平台”，而不是他们认为的“脚本”。对于这些公司来说，定制是反对现成工具的常见论点，而混合云和内部部署是重要的用例。Kubernetes、Consul等开源组件很常见，因此笔者经常听到这样的断言，即轮子不需要重新发明。然而，团队的规模和分配给解决方案的时间是巨大的。在某些情况下，对构建平台的关注掩盖了公司应该销售的核心业务产品。虽然不完全是科学的，但颇有一些公司这么做。
与此同时，一些公司的工程人才正在构建纯软件即服务的应用程序。这些应用程序使用了太多的原生云软件——S3、Dynamo、亚马逊简单队列服务（SQS）、亚马逊简单通知服务（SNS）——很难混合使用。他们很乐意通过API或UI将容器交给亚马逊弹性容器服务（Amazon Elastic container Service，Amazon ECS）进行部署。他们对部署或学习Kubernetes并不感兴趣。因此，内部定制的趋势和深度要少得多。
多少次，多少人会编写相同的代码来实现相同的用途？上市时间最终决定了一切。
原文链接：
https://thenewstack.io/infrastructure-as-code-or-cloud-platforms-you-decide/
