导读

自推出以来，HashiCorp Terraform和Amazon CloudFormation都吸引了大量粉丝，而Amazon CDK也正在获得更多关注。然而，持有强烈观点的用户通常只使用过其中一种，有时是两种工具，而且他们的经验并不能反映最新的功能和可能性。在本次会议中，我们将通过快节奏的现场编码示例探索这三种工具，然后深入研究一些具体场景。最后，您将能够做出明智的决策，为特定工作选择最佳工具。

演讲精华

以下是小编为您整理的本次演讲的精华。

演讲者Mattine Faldona首先询问了观众对标题中提到的三种基础设施即代码(IaC)工具的熟悉程度:CloudFormation(CFN)、Terraform和亚马逊云科技云开发工具包(CDK)。他承认虽然大约10-20%的与会者使用了这三种工具，但他预计更多人只偏好使用其中一种工具。Faldona澄清说，他并不偏爱任何特定工具，而是同等地接受这三种工具。

今年早些时候，Faldona意识到在re:Invent活动上讨论这个主题可能会很有价值，随后他获得了机会就这三种IaC工具进行演讲。他花时间练习和准备，却发现这个主题有许多角度和细节需要探讨。Faldona向观众保证，他已尽最大努力选择了当天演讲的最相关主题。

Faldona自我介绍说，他住在荷兰，距离阿姆斯特丹以北大约30分钟的路程，为一家名为Hubert Phillis的公司工作。此外，他还拥有亚马逊云科技英雄的尊贵头衔，并于2017年在荷兰发起了亚马逊云科技社区，组织了各种聚会和亚马逊云科技社区日活动。

Faldona的演讲首先简要概述了基础设施即代码的演变历程，然后进行一个快速学习练习，涵盖所有三种工具:Terraform、CloudFormation和CDK。他承认以正常速度进行学习练习将需要一个半到两个小时，因此他决定加快语速，在60分钟的时间内完成演讲。之后，他打算讨论反模式(即人们做出次优选择或根本不做选择的情况)，最后总结关键要点。

回顾基础设施即代码的演变历程，Faldona追溯到2011-2012年，当时CloudFormation推出，标志着从过去普遍使用bash脚本部署基础设施的做法转变。几年后，在2014年，Terraform问世，Faldona回忆起他当时在伦敦的O’Reilly会议上，Mitchell Hashimoto展示了这个工具。当时，Faldona承认他无法预见Terraform会产生如此深远的影响。2018年，CDK第一版发布，引起了开发人员的极大兴趣，他们渴望探索其潜力。

随着时间推移到2023年和当前的2024年，Faldona强调现在有太多选择，因此在选择适合特定用例的基础设施即代码工具时需要谨慎考虑。

为了说明IaC的演变，Faldona分享了一个2010年用于部署网络和EC2实例的bash脚本示例。他强调了重用这种脚本跨环境的挑战，通常需要手动修改脚本中的变量。这促使他决定将变量合并在文件顶部，从而使同一个脚本可以通过简单调整声明的变量来跨多个环境使用。

为了进一步改进，Faldona转向使用配置文件的方法，其中一个YAML文件在顶部包含变量，并定义要部署的组件。这种方法涉及读取模板、创建计划、部署组件和将输出写入状态文件。后续更新需要对YAML模板进行更改、读取修改、执行更改并更新状态文件。但是，删除操作不需要读取模板，只需依赖状态文件来识别和删除已部署的资源。

在准备他要教授的Python培训时，Faldona意识到有机会让学生进行一个实践练习:构建一个类似于CloudFormation或Terraform的工具。

转入快速学习练习，Faldona介绍了一个虚构的应用程序“TickerBox”，这是一个简单的网站，用户可以在上面创建列表并添加项目，如纪念品、礼物或re:Invent活动的亚马逊云科技连帽衫。该应用程序还允许与他人分享这些列表，类似于分享生日派对的愿望清单。虽然该应用程序尚未上线，但Faldona表示打算在圣诞节前后推出。

Faldona采用了一种不同寻常的架构来部署TickerBox应用程序，与典型的API网关或负载均衡器与容器的方式不同。相反，他选择了一种用户访问CloudFront的架构，CloudFront将流量转发到VPC，在那里一个Lambda函数执行并连接到DynamoDB数据库。虽然不是必需的，因为一切都可以在公有云中部署，但这种架构允许Faldona解释如何组织他的项目并在团队之间共享组件。

Faldona进一步详细说明了部署所需的资源，包括网络组件(VPC、子网、网关和安全组)、DynamoDB表、CloudFront分发以及Lambda函数及其相关角色、策略和环境变量。

Faldona强调，该项目的组织结构反映了他职业生涯中经常遇到的典型结构，其中一组人员构建登陆区域，可能共享基础设施(如Kubernetes集群或用于微服务的API网关)，然后有多个云团队在此基础之上运作。

当Amazon CDK推出时，它引入了L1、L2和L3的概念，Faldona承认这对许多观众来说可能并不熟悉。L1是指使用Python、TypeScript或Node.js等编程语言定义CloudFormation资源，但增加的价值有限。要真正从CDK中获益，需要进阶到L2，它提供了精心设计的构造，如VPC，无需手动定义单个资源。L3则结合了多个构造，如VPC、网关端点和针对组织内应用程序的模式。

Faldona展示了一个比较Terraform、CloudFormation和CDK在L1、L2和L3级别上的表格。在L1级别，这三种工具基本相当。在L2级别，Terraform使用模块，CloudFormation使用一个名为Sceptre的工具(Faldona稍后会演示)，而CDK利用了精心设计的构造。对于L3，Terraform使用堆栈模块，CloudFormation依赖于亚马逊云科技解决方案(Faldona将展示其中一个)，而CDK则包含了模式。

首先进行Terraform L1演示，Faldona定义了配置项目，如提供程序和堆栈名称。然后，他继续定义资源，如VPC、子网、VPC端点及其相互连接。同样，他还定义了DynamoDB表、Lambda函数以及相关的角色、策略和配置。但是，在这个阶段，还没有部署任何资源，因为部署发生在定义资源时，例如将策略附加到角色和Lambda函数本身。

Faldona承认，虽然L1实现很全面，但这并不是构建Terraform模板或项目的推荐方式。相反，他倡导使用L2方法，他接下来将演示，并向Anton Kublinko致敬，感谢他的开源L2构造。

在L2演示中，Faldona从头开始，创建一个main.tf文件，定义提供程序、变量和区域。然后，他使用从Kublinko的GitHub存储库中获取的模块定义网络，指定配置细节，如VPC名称、CIDR块、可用区域和子网类型。Faldona对VPC端点、DynamoDB表和Lambda函数采用了类似的方法，利用抽象了低级资源定义的模块。

转向L3实现，Faldona的目标是在多个团队之间共享架构。他在项目中创建了一个“modules”文件夹，并将main.tf文件中定义的资源移动到单独的模块中，如“cloud-front-lambda”。这些模块可以在其他项目中被引用，无论是本地引用还是固定到GitHub、S3或其他共享位置的特定版本，从而实现受控部署和测试，然后再采用新架构。

介绍完Terraform的L1、L2和L3实现后，Faldona将重点转移到CloudFormation。L1方法涉及在单个YAML(或JSON)模板中定义资源，从注释(仅在YAML中可用)开始，然后指定DynamoDB表、VPC、子网、路由表、VPC端点、安全组和Lambda函数的属性。Faldona承认，要在亚马逊云科技管理控制台中只需几次点击就能配置的资源，在这里需要180行代码来定义。

为了解决默认CloudFormation实现的局限性，Faldona介绍了Sceptre，这是一个开源工具，旨在更有效地构建CloudFormation项目。使用Sceptre，项目被组织到“config”和“templates”两个文件夹中。“templates”文件夹包含VPC、Lambda函数和CloudFront分发等组件的单独模板，而“config”文件夹定义了如何部署这些堆栈，包括参数、依赖关系和导出值。

Sceptre的一个关键优势是能够将模板存储在S3存储桶或其他位置，从而促进跨团队或甚至向更广泛的社区开源共享最佳实践。Faldona演示了如何在配置文件中定义参数，使得相同的项目结构可用于不同的环境，如验收和生产环境。

然后，Faldona透露了一个“惊喜”——使用Terraform来部署CloudFormation模板的能力。在他的项目中，有一个“therm templates”文件夹，其中包含VPC、Lambda函数、CloudFront分发和其他组件的模板。然后，他可以创建指向这些模板的Terraform资源，包括输入变量，如CIDR块和参数。这种方法允许中央团队维护和版本控制模板，而多个项目可以使用这些模板并将其部署到各自的亚马逊云科技环境中。

Faldona展示了一个图表来说明这个概念，其中一个小组维护CloudFormation模板，将它们打包到一个Terraform模块中，然后多个项目可以包含并将该模块部署到它们各自的亚马逊云科技环境中。

转向CDK演示，Faldona承认CDK的普及程度，观众举手的情况证明了这一点。他强调了CDK中L1和L2实现之间的细微差异，后者从构造名称中删除了三个字符(“Cfn”)，但需要定义额外的配置参数。

在L1演示中，Faldona初始化了一个CDK应用程序，并专注于demo-stack文件，在该文件中导入了必要的库。然后，他创建了一个CfnVPC，仅定义了CIDR块，运行“cdk synth”时会部署一个单一资源。

转向L2实现，Faldona将“CfnVPC”替换为“EcVPC”，定义了一个IP地址，并再次运行“cdk synth”。生成的YAML输出显示创建了VPC以及许多相关资源，总共超过200行CloudFormation代码是从几行CDK代码生成的。此外，部署还包括一个Lambda函数来应用最佳实践，展示了L2构造的内置最佳实践和可扩展性。

对于完整的CDK L2项目，Faldona通常会首先定义所需的组件，如DynamoDB表，然后是VPC，使他能够在整个模板中引用这些资源。他强调使用L2构造而不是L1的重要性，因为它们生成更多的CloudFormation代码，而开发人员的输入较少。

Faldona承认偶尔需要引用外部资源，如S3上的文件或公共URL，这最初确实存在挑战，直到他学会了相应的技术。

为了促进跨团队共享和重用，Faldona演示了在项目中创建一个“cdk-constructs”文件夹，他可以在其中复制为“TickerBox”应用程序定义的资源，并创建可重用的构造，如“function-app”或“cloudfront-app”。回到主项目中，他可以导入并使用这些共享构造，遵循代码共享、测试和开发人员协作的最佳实践。

在介绍了三种IaC工具及其各自的L1、L2和L3实现之后，Faldona展示了一个决策树，用于选择合适的工具和方法。第一步是确定是使用CloudFormation还是Terraform。如果选择CloudFormation，下一步是决定是否使用CDK。Faldona指出，虽然CDK是为CloudFormation设计的，但也有CDK TF，它以类似的方式生成Terraform代码。

决策树的最后一步是选择合适的抽象级别:L1、L2或L3。Faldona强烈反对使用L1，因为这将耗费大量时间，而是建议至少使用L2，如果开发团队之间存在共同点，则L3是首选。

接下来，Faldona讨论了他在整个职业生涯中遇到的一些反模式。一种反模式是个人在Terraform代码中构建整个应用程序，实际上将配置文件视为应用程序本身。这种方法存在问题，因为只有一个人(创建者)可以进行更改，导致其他人对该个人进行任何修改都产生依赖，形成“英雄”情况。

Faldona强调的另一种反模式是“fork and forget”问题，团队会创建项目的副本，但未能将他们的更改合并回原始代码库。这导致组织内部出现同一架构的多个版本，违背了标准化和可重用性的目的。

为了避免这些反模式，Faldona建议保持简单和可扩展性，促进团队成员之间的知识共享和协作。他主张创建抽象，但警告不要过于复杂，因为这可能会阻碍支持和采用。相反，他更倾向于简化解决方案，使其他人更容易重用现有实现，而不是重新发明轮子。

Faldona将创建过于复杂和固执己见的解决方案的负面方法与构建简单、灵活且维护良好的可重用资产的积极方法进行了对比，后者可以让其他人轻松采用和贡献。

Faldona讨论的其他反模式包括:

1.           “让专家选择”:这种情况通常发生在选择IaC工具的个人已经对该工具有了丰富的经验，花费数年时间攀登陡峭的学习曲线。然而，他们的同事将从头开始，这将导致对专家的依赖，并阻碍他们独立构建或改进解决方案的能力。

2.           “让狂热分子选择”:Faldona警告不要让对某个工具有强烈偏好的个人进行选择，因为他们可能会由于熟悉和偏好一直在使用的工具而忽视其他工具的优势。

3.           要求客户构建自己的Terraform或CloudFormation代码，但不提供访问AWSAPI的权限:Faldona强调允许客户在沙盒或游乐场环境中迭代和学习的重要性，就像工程师在自己的学习过程中所做的那样，而不是期望他们针对“黑盒子”工作。

4.           过度工程化:Faldona警告不要让平台团队花费数千小时创建过于复杂的模板，并举例说明，有些情况下努力超过了潜在的重用，导致时间和资源的浪费。

5.           风险集中:在组织内部坚持使用单一IaC工具可能会限制业务机会，如果潜在客户要求使用不同的工具。此外，它还可能限制获取人才，因为精通其他工具的工程师可能会被忽视。

6.           忽视人力投入:Faldona指出，围绕工具选择的讨论往往仅关注产品功能，而忽视了学习、创建抽象和集中开发所需的人力投入。他将此与比较私有云和公有云的情况作了类比，后者提供了开箱即用的功能，但在成本分析中常常被忽视。

7.           低估知识差距:Faldona警告不要低估新手达到与专家相同水平所需的时间和努力，并强调在入职过程中知识共享和支持的重要性。

转向关键要点，Faldona强调了考虑IaC工具将如何使用(在L1、L2或L3级别)的重要性。他主张简化解决方案并使其易于采用，经常使用“always simplify”或“make the writing the easy thing”这样的标签。这种方法鼓励其他人重用现有实现，而不是重新发明，从而促进协作和知识共享。

Faldona的最后一个关键要点强调了合作伙伴和客户之间的根本区别。作为IT合作伙伴，他的公司可以构建开箱即用的解决方案，如登陆区域，客户可以从中受益，而无需内部重新发明或维护。另一方面，客户可能更愿意“锁定”合作伙伴的成熟解决方案，而不是投入大量资源构建和维护自己的解决方案。

Faldona引入了“粘性”的概念，作为“锁定”一词的更积极替代。他鼓励创建令人信服的产品和服务，让客户愿意坚持使用，而不是通过知识障碍或专有模块将他们锁定。分享知识并使解决方案可访问将有助于培养客户忠诚度和长期合作伙伴关系。

最后，Faldona感谢审阅并提供反馈的人员，并邀请观众分享他们的想法和反馈。他分享了一个二维码，链接到他的个人简介，其中包含他的联系信息和整个演讲中使用的演示代码的GitHub存储库。Faldona还邀请观众与他一起共进午餐，进一步讨论所涉及的主题或任何其他相关主题。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。