探讨基础设施即代码所带来的挑战
Posted apl359
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了探讨基础设施即代码所带来的挑战相关的知识，希望对你有一定的参考价值。
原文地址：https://lukeshaughnessy.medium.com/infrastructure-as-code-is-not-the-answer-cfaf4882dcba
以下是译文
当然，你听过销售宣传。如果你在 DevOps、平台或 SRE 领域工作，那么你可能已经自己推销过它。基础设施即代码（Infrastructure as Code）！其好处多种多样且不言自明：
• 它是可复制的！
• 它是自文档化的！
• 它是可见的！
• 它可以防止错误发生！
• 它能降低成本！
• 它可以防止偏移（drift）发生！
• 它可以避免重复劳动，增加工作乐趣！
• 自助服务！
毫无疑问，所有这些事情都可能是真的可以实现的。在理想的世界里，所有这些好处都将显而易见，并且对于愿意投入前期资金将基础设施部署转换为代码和配置管理的任何组织都将大有裨益。而我们大多数人也确实如此。但是，那些不在理想世界中的事情呢？采用 IAC 存在哪些实际成本、风险和困难？在现实的光芒下，华丽销售宣传在哪里开始融化了呢？让我们看一下上面提到的一些优点，并检查其中的一些假设。
它是可复制的！
嗯，有点道理。我会说基础设施代码在一段时间内是非常可复制的 —— 但是随后...事情变得不稳定了。软件包过时了。功能被弃用并停止工作。代码语法发生了变化。镜像不再可用。Dockerhub 要你付费。某些用户账户已经建立，而他们已经不再在这里工作了。许多相互依存的依赖关系使得部署正常运行，但它们随时间改变。重点是部署代码具有一定的寿命，如果你不不断地更新它，当你突然需要它时，它将不起作用。
译注：意思是虽然基础设施的代码是被版本化的，是稳定的。但是它所依赖的东西却可能是不稳定的。
它是自文档化的！
同样，有点道理。然而，这个论点有几个缺陷。第一个问题与上面提到的问题有关。你的代码在一段时间后开始变得陈旧不堪。这意味着，第一次查看你的代码的工程师可能会开始追寻兔子洞，试图使一些旧模块在新的云环境中运行，在那里许多关于如何完成任务的假设已经不再适用。我有同事花了数天时间来追查失败的部署，并一步步调试，因为他们在代码中看到的内容与现实不符而感到完全困惑。事实上，如果他们重新开始编写新代码，可能会更快、更好。
译注：是代码就会有代码质量问题。作者所言的问是他使用的老模板的依赖发生了变化，导致老模板的失败。
第二个问题是，我认为代码真的不适合作为文档。我自己写过代码，六个月后回来看，我完全想不起我当时做了什么。在编写代码时，你可能会使用各种各样的技巧、半成品和明显错误的东西，因为很可能在做的时候还在学习相关知识。回头再看这些代码时，你会发现其中存在许多混乱和难以理解的部分。基础设施代码同样存在这些问题，它可能会包含各种不稳定的假设和方法。这些假设和方法可能会使其他工程师在查看时感到困惑或无法理解。
译注：只要是代码，都会遇到同样的问题。作者说的是代码的可读性问题。
它是可见的！
是的，它是可见的 —— 就像我在 CTO 的办公室角落用西里尔字母喷涂标语一样。这会很酷也很叛逆，但没有人知道它说了什么。问题在于代码，嗯，是 _代码_。这不是非工程师可以轻易阅读的内容，甚至对于不熟悉 Terraform 或其他技术的工程师来说也不容易阅读。理解其中的信息需要实践和培训，有时即使经验丰富的工程师也需要一些时间才能完全弄清楚所有信息的位置，特别是如果你有很多嵌套文件、依赖项和调用脚本的脚本。重点是，是的，你可以看到它，但这并不意味着你可以迅速或轻松地理解它。
译注：其实，这并不是什么问题，我们可以想办法根据代码生成基础设施的图。
它可以防止错误发生！
或者，它可以像氢弹核心周围的重氢外套一样放大它们。我曾经听过一个故事，说有个工程师在他的笔记本电脑上运行了“terraform destroy”命令——但是在错误的标签页上。他处于“Prod”目录下，并开始对生产环境进行摧毁。意识到自己的错误后，他按下了Control-C退出了命令，但为时已晚。很多东西已经消失了，除此之外，终止进程也让状态文件处于混乱状态。他们通过手动修复状态文件并重新运行terraform来恢复了它，并在几个小时内解决了这个问题。但这是一个非常容易犯的错误，任何人都可能会犯。
译注：作者说的案例是流程上问题。即使不使用基础设施即代码也会发生同样的问题。但是这个问题从侧面说明的是基础设施即代码需要配上一定的操作流程。
它能降低成本！
如果一切都完美地运作，从不发生变化，而且您一直做同样的事情，那当然可以。但根据我的经验，保持代码更新需要花费工程师大量时间和精力。工程师每天需要花费数小时进行调试、故障排除、学习和编写代码。如果你只是登录控制台并点击一些框，可能只需要几分钟就能完成的任务，可能需要数天的工作才能自动化完成。如果您经常使用自己的代码，那么它值得投资。但您需要认真考虑自己有多少次实际上会部署新的RDS实例或新的Cloudfront分发？其中许多任务只需完成一次，您可能永远不会再做了。你真的需要花费数天时间来自动化这个过程吗？
译注：作者说的是基础设施的规模问题。也就是我们在实践基础设施即代码时，需要考虑基础设施的规模。
它可以防止偏移（drift）发生！
只有当您创建代码以更改环境中的内容时，这才是正确的。一旦一个人拥有控制台的访问权限，你就可能会遇到“漂移”问题。那么这个神经病般的罪犯是谁，在控制台上不断进行变更呢？嗯，有时候就是你自己。因为出现了故障，你需要在负载均衡器中添加新的证书，或者因为你正在受到DDOS攻击，需要添加CloudFront分发来吸收传入请求。或者因为你需要将某些东西进行规模扩展以处理意外负载。现在显然，你可以事后回过头来重新编写你的代码，以反映你所做的更改。这看起来很愚蠢，但在我的经验中，这种情况在现实世界中经常发生。
译注：作者说的基础设施即代码中经常遇到的问题：界面操作先于代码操作。这种情况在实际情况会有发生，但是要看频繁程度和规模。如果经常发生，且界面上进行大量的操作，那么，这其实需要在流程上控制，且说明之前的基础设施的设计就存在问题。
它可以避免重复劳动，增加工作乐趣！
你想处理一些琐碎乏味的任务吗？比如将Terraform 0.10版本升级到1.3版本？这个过程中有相当多的语法变化，尽管一些自动化工具可以帮助处理。但是旧版本的Terraform需要很多奇怪的解决方法，而这些问题在新版本中已得到改进并增加了新功能。因此，仅仅使用自动化工具来重新处理语法是不够的，你需要全面重构整个代码库。我有同事已经进行了一年以上的Terraform迁移工作。这是一个需要投入许多工程师小时数才能更新的巨大工作。有时候很难说服老板这么做，特别是如果你已经消耗了所有的好感度以及花费几个月时间创建代码。
译注：这段文本谈到了如何将Terraform代码库从0.10版本升级到1.3版本，需要进行全面重构和大量工程师时间的投入。此外，这也涉及到旧版本的一些语法变化和解决方案，而新版本已经增加了新功能和改进。这种更新过程可能会被认为是琐碎乏味的任务，但它是必要的，因为它可以提高代码质量和可维护性。然而，向老板证明这种更新的必要性有时可能很难，尤其是当团队已经花费了大量时间创建代码并消耗了所有好感度时。
自助服务！
平台团队的终极目标是为整个公司打造一个自助PAAS（平台即服务）系统。所有基础设施和服务都经过了彻底的自动化，以至于非DevOps工程师可以拉取git存储库，编辑一些模板文件，然后将其推回，并且你的CI/CD系统会自动部署它们。所有的日志记录、警报、指标和安全策略都已经内置。我真的很喜欢这个想法，我正在努力让我的当前公司达到这个状态。但这又与现实相冲突。例如，我们曾经有一个非常复杂的自动化系统来管理Github中的用户账户。我们会编辑文件，将它们推送到CI中，然后用户和repo就会被填充。然而，我们意识到这是不必要的复杂性，显著减缓了新员工的入职进度，因为他们需要等待技术人员编辑自动化文件。直接确保团队经理经过审核并接受了安全策略的培训并获得直接访问Github，比起使用自动化管理用户账户更容易快速。我们相信他们会正确地点击来添加新账户并授予权限。
译注：作者举了一个Github用户授权管理的例子，想说明的是并不是基础设施并不一定要所有都通过“Code”来实现，有时通过界面点点可能效率更高。
总结
这是否意味着我们放弃IAC的整个想法而重新回到在控制台上点击操作呢？当然不是。我认为这是最好的答案。就像过去的好主意一样——比如敏捷开发、Scrum、DevOps、无服务器计算、微服务——它们都可以带来很大的价值。你不能固执地认为你必须全身心地致力于这个想法。IAC有其使用场景，但仅仅是一个使用场景而已。并非每种情况都相同，总存在一些魔鬼般的细节需要应对。一个好的工程师或工程经理会知道何时该放弃自动化完美的柏拉图式理念，允许人们在必要时灵活一些。
也许你想了解更多Everything as Code:
请关注我：
主题演讲探讨视频行业与技术的更多挑战与机会
在过去的一年中，我们可以看到多媒体特别是音视频技术的能力在严峻的挑战下，为各行各业带来了巨大的变化。疫情过后，又会有哪些多媒体新技术、新实践呈现在大众的视野当中？为行业的发展与应用带来哪些新的趋势与机会？
10月29日-30日，LiveVideoStackCon 2021 音视频技术大会 北京站，一同探讨视频行业与技术发展的挑战与更多机会。
文末福利：往届(部分)精彩演讲视频及内容整理
主题演讲
SPEAKER
of 2021
黄琦 /
快手
短视频架构负责人
黄琦，2021年加入快手，目前作为短视频架构负责人，致力于通过视频基础架构的研究与设计为用户打造极致视频体验。2012-2021年，曾就职于Facebook，先后参与了Haystack存储系统、CDN缓存、Gorilla时序数据库、TAO图谱存储、XDC跨数据中心系统、以及SVE流媒体引擎等的设计与开发；并作为第一个工程师创建了Facebook视频基础架构团队，带领团队实现Facebook全系产品媒体处理架构的持续演进与升级。在此之前，先后于华中科技大学与康奈尔大学获得学士与博士学位。
TOPIC：
.视频大时代下基础架构的演进趋势.
过去十年，随着端上算力和通讯能力的提升，我们见证了一个业务玩法日趋复杂、用户覆盖遍及全球的视频大时代的诞生。随着多个市值千亿以上的泛视频行业公司得到更多的关注，其背后支撑业务高速迭代、承载核心技术的视频基础架构也慢慢浮出水面。视频基础架构包含哪些核心能力，在过去和现在经历着什么样的演进，对于未来我们又该如何期许？在本次主题演讲中，我们将结合快手自身实践与行业观察，和大家一起探讨。
SPEAKER
of 2021
叶琰 /
阿里巴巴研究员，阿里云智能视频云视频标准与实现负责人
叶琰是阿里巴巴研究员，阿里云智能视频云视频标准与实现负责人。她负责视频云在 ITU-T VCEG 、 ISO/IEC MPEG 、AVS等国际和国家视频标准组织的技术开发，涉及视频编解码、AI视频质量评估、VR/AR等先进技术的研发工作。在加入阿里巴巴之前，她曾在 InterDigital、杜比和高通等公司就职。叶琰多年从事视频编解码标准制定，她参与了多项视频编解码与流媒体的国际标准制定工作，包括 H.266/VVC，H.265/HEVC ，SHVC，MV-HEVC，SCC，H.264 SVC，MPEG DASH和MPEG CMAF 等标准。她曾担任VVC 测试模型文档、 360Lib 算法描述文档、HEVC 可扩展和HEVC SCC 扩展标准的编辑。她目前担任INCITS L3.1（MPEG development activity）主席以及MPEG visual quality assessment顾问组360全景视频主席。她是50多篇学术论文的作者，130多篇美国授权专利以及230多篇美国专利申请的发明人。她是IEEE高级会员。她在中国科技大学获得本科及硕士学位，在加州大学圣地亚哥分校获得博士学位。
TOPIC：
.编解码再进化：Ali266与下一代视频技术.
过去的一年见证了人类百年不遇的大事记，也见证了多种视频应用的厚积薄发。而因此所带来的视频数据量的爆发式增长更加加剧了对高效编解码这样的底层硬核技术的急迫需求。正是在这样的大环境下，在ITU-T VCEG和ISO/IEC MPEG两大标准组织再次联手推出的最新视频编解码标准VVC定稿不久之后，阿里巴巴的视频团队开始全力投入开展VVC软件编解码的开发工作。经过一年的努力，我们最近推出的Ali266不但在业界第一次实现了高清实时VVC编码能力，也同时充分印证了VVC强大的压缩效率。本次主题演讲将带给大家Ali266 的开发过程以及我们对Ali266在云端协同、5G网和云计算等环境下的落地展望。最后我们以“后VVC时代“视频业界所面临的技术和业务挑战为结尾，期许带给大家有意义的“思想盛宴”（food for thought）。
SPEAKER
of 2021
朱照远 /
镕铭微电子
CEO
朱照远，镕铭微电子公司CEO。镕铭微电子是一家研发视频处理芯片（VPU）和可计算储存芯片（Computational Storage）的创新型芯片公司。在加入镕铭之前，朱照远就职于阿里云，担任视频云总经理，负责阿里云视频云、CDN、边缘计算等产品的业务和技术研发。在其就职期间，阿里云视频云和CDN被IDC等国际权威咨询机构多次评为中国市场第一。朱照远对视频产业和应用有深刻的理解，对于云计算技术和视频技术等领域有较深的研究。另外，他也是开源Web服务器项目Tengine的发起人。
TOPIC：
.视频产业新挑战与新机遇.
4G的诞生推动了视频行业的蓬勃发展，也催生了新的视频应用和业务形态，视频内容越来越多，视频能力正在成为一种基本能力。5G时代已经到来，视频行业将会出现什么样的挑战和机遇？在行业，技术，商业，产品等方面会出现什么趋势，对于从业者又有什么建议？本次分享将和您一起探讨。
点击阅读原文了解更多大会相关信息，
获取往届（部分）精彩演讲视频及内容整理
以上是关于探讨基础设施即代码所带来的挑战的主要内容，如果未能解决你的问题，请参考以下文章