云架构错误:DIY 心态的高成本

云架构错误:DIY 心态的高成本

源节点: 2562587

这是一个由五部分组成的系列文章,内容涉及组织在构建云架构时通常会犯的代价高昂的错误。 第一部分 解释了迁移到云的组织如何快速失去对数据处理的可见性和控制,并详细说明了如何避免这种错误。 第二部分着眼于自己动手可能出错的方式。 

如果您的企业要求您建立一个 云网络 具有面向未来的架构和跨多个云的一致设计? (我有没有提到您的网络需要提供具有操作可见性和控制的嵌入式安全性,并且最重要的是优化成本?)

您会启动一个复杂的自动化脚本网络来构建您自己的网络吗? 

OR 

您是否愿意购买具有企业支持的单一、一致且可重复的云架构? 

据最近的一项 欧洲市场报告,多云网络团队报告难以在其多云资产中构建一致的网络,97% 的组织在实施和管理其网络之间的连接时面临重大挑战——尤其是监控和容量管理,以及可见性和带宽和云。 许多运行关键任务工作负载的企业更愿意购买而不是构建这种类型的解决方案。

令人惊讶的是,我注意到许多信息不灵通的组织仍然犯着 DIY(自己动手)的错误。 他们认为他们可以聘请开发人员,利用 CSP 的本地网络和安全结构,并使用自动化脚本构建云网络。 这是一种有缺陷、耗时且成本高昂的方法。 虽然这种方法存在一些挑战,但让我们检查一些关键的挑战。 

CSP 特定的自动化脚本(例如 CloudFormation)仅与特定的 CSP 相关。 它们将在多云场景中失败。 并且根据一个 微软调查,95% 的业务决策者表示,多云对其业务成功至关重要。 

支持自动化脚本将动用关键资源来执行日常任务,而不是成为业务增长和战略计划的一部分。 这些脚本没有任何集中控制平面。 没有“大脑或智力”。 主要是run it and forget it。 如果网络状况发生变化(例如,学习到新的 BGP 路由),静态自动化脚本无法根据新的状态变化采取任何操作。 没有可用的反馈回路。

网络的行为可能随时改变。 您可能会遇到一个峰值,要求您自动扩展基础架构。 您可能有攻击者试图将勒索软件注入网络。 无脑的自动化脚本无法适应这些变化。 

如果自动化工程师生病或离开了组织,知识就全部消失了,新人几乎不可能理解和增强该自动化脚本。

更不用说,由于多云网络技能短缺,雇用或更换该人员的成本正在急剧上升。

图书馆推荐

虽然 DIY 解决方案在短期内似乎最简单且最具成本效益,但投资于一个致力于让您的业务保持领先地位的云网络平台将为您取得长期成功和可扩展性做好准备. 组织应该将他们的团队集中在创新和上市时间上,而不是不断地编写和调整脚本。 在云网络平台供应商中寻找的好处至少应包括: 

  • 具有分布式数据平面的集中式控制器
  • 基于意图的嵌入式网络和安全控制 
  • 具有异常检测的自我修复能力 
  • 基于机器学习的网络行为分析
  • 强大的 Terraform 支持,允许您独立于 CSP 编写 Terraform
  • 支持所有主要 CSP 运行您的关键业务应用程序

供应商应避免的陷阱包括:

  • 传统硬件供应商提供不成熟和以硬件为中心的选项,不适合现代和业务关键型工作负载
  • 满足您的云网络需求的安全特定供应商 
  • 供应商试图通过将硬件代码提升和转移为 VM 并将其称为云网络解决方案来“云洗”他们的遗留硬件技术

结论

在云中自己动手——使用 CSP 的本地网络和安全框架,以及大量自动化脚本——乍一看似乎是一种经济实惠的捷径,但它很快就会导致随意安排,从而导致效率低下并增加成本。 仅限 CSP 的脚本无法在多云环境中运行,并且自动化脚本无法进行集中控制。 另一方面,智能云网络平台提供集中控制、自我修复能力、更好地使用机器学习的能力以及对所有主要 CSP 的支持。 

下一步:第三部分将研究不充分的分摊和扣款选项的风险,以及在与 CSP 无关的平台上构建计费解决方案的优势。

时间戳记:

更多来自 数据多样性