在我上一篇文章中，我讨论了大多数组织在云应用的各个阶段所面临的问题——如何尽可能高效地交付应用程序SLA，只为他们使用的东西付费，只使用他们需要的东西。解决这一问题的唯一途径就是根据需求不断调整资源配置。换言之，匹配供需。这将导致只在需要时正确支付所需的资源，即云成本效率的圣杯，而实现这一目标的唯一方法是通过自动化。要真正做到有弹性，每个决策都必须考虑到多个方面：资源需求的动态变化决策对应用程序SLA的影响影响：环境中的其他工作负载同一应用程序的其他组件与更改相关的成本（或节省）与业务策略和法规遵从性保持一致今天人们如何解决这个问题？今天，通常有三种不同的方式来尝试：手册-使用电子表格进行资源管理规则-基于阈值的实时单资源规则批次分析-定期运行的复杂批次分析，通常每周或每月运行一次这些方法都不能解决问题。在这篇文章中，我将讨论手动解决问题的方法。手册一些组织试图手动解决这个问题。无论目标是确定要购买哪些保留实例、每个工作负载的正确实例类型，还是从其内部数据中心迁移应用程序的最佳方法；他们都使用电子表格来解决问题。负责这些不同任务的不同团队创建电子表格，汇总来自多个源的数据。然后，小组将收集到的数据倾泻并合并，并尝试分析上述每个问题的答案。这种方法的问题首先，这是一个时间汇，它没有规模。人们需要时间来合并大型数据集、确定节约机会并防止性能问题，而且由于需求不断变化，任何问题或机会都可能会错过。与我交谈的大多数组织都将30-50个vm视为手动方法变得无法管理的点。第二，它使用静态数据，这意味着决策与特定时间点相关，不会随着资源需求的变化而更新。有些组织采用了不同的启发式方法，比如使用30天平均值、峰值消耗量或峰值的90%。尽管所有这些启发式方法都比使用单时间点数据要好，但它们仍然是基于历史的。如果一个应用程序突然经历了一个需求高峰，它就不一定会被记录在历史记录中，这意味着这种方法不能保证应用程序获得所需的资源。最后，问题是，在大多数情况下，使用这种方法，组织会选择一个子集的指标来考虑，而对这个子集所做的决策可能会对应用程序的性能产生负面影响。例如，当考虑CPU和内存而不是IOPS时，重磁盘应用程序的性能可能会降低。需要输入到决策过程中的指标量是巨大的，对人们来说是非常具有挑战性的。总之即使一个组织找到了解决上述问题的方法，他们通常也会与其他组织进行权衡——使用指标的子集、虚拟资产的子集或近似值。这种方法的所有不同变体都是静态的、周期性的、耗时的并且容易出错。有效利用云资源并真正具有弹性的唯一方法是，您需要一个能够实时了解需求并能够相应地进行增量更改的平台。在我的下一篇博客中，我将讨论另一种方法：规则方法。敬请期待！