组织在将业务迁移到云平台时，遇到的最常见的问题之一是成本。采用云计算，组织可以将IT成本从资本支出(硬件设备和软件许可的长期投资)转换为运营支出，因此选择正确的云服务并进行正确估算至关重要。以下将探讨在调整云计算资源大小时常见的错误和陷阱，并讨论如何避免，从而真正受益于云计算的弹性。

1.遵循提升和转移方法

提升和转移方法意味着组织可以将工调整作负载的副本移动到云平台中，而只需进行少量的更改。即使组织只将部署业务快速迁移到云平台中，这种模式也很有用，但它可能导致资源使用不足。AWS公司承认，通过创建服务来简化迁移(CloudEndure迁移和AWS服务器迁移服务)是一个困难的问题。不过，为了获得更好的资源利用率，组织最好考虑重新构建云计算解决方案。

组织采用提升和转移方法，从长远来看可能云计会支付更多的成本，也可能会错过云计算提供商提供的许多好处。例如，当选择完全管理的AWS Aurora而不是传统的Postgres实例时，组织可以获得高达三倍的吞吐量、存储自动扩展和低延迟读取副本。这可能是Aurora成为目前最受欢迎和发展最快的AWS云服务之一的原因。

2.不标记资源

如果组织没有足够的数据来做出明智的决定，则很难改进。如果无法跟踪云计算资算资源的性能以及它们产生的成本，那么就很难优化其利用率。

最好的做法是根据项目或组织单位标记资源，以将成本正确分配给相应的服务。

3.未能随着时间的推移监控资源使用情况

管理云计算结构并不是一次性的过程。这是监视和评估组织使用的内容、使用方式以及原因的持续实践。也许组织最初对特定应用程序的增长的假设并不完全正确，而进行更改可能会显著地降低成本源大。

例如一个过度配置的Kubernetes集群，它的节点比需要的多很多。在这种情况下，也许转向无服务器版本(Fargate上的EKS)更有意义。

保持“僵尸”资源不受监控的情况并没有人们想象的那么普遍。在规模较大的组织中，可能会发生某些项目由于不完整的移交过程而被放弃并且相应的资源保持活动状态的情况。

4.总是自己做所有的事情

软件工程师有时可能会自己构小时建定制的解决方案和服务。一种可能更好的方法是首先对现有资源进行适当的研究。例如：

也许不需要在EC2上使用自托管数据库，而是使用完全托管的RDS，这可以帮助更轻松地扩展和操作实例。 也许不需要这个自我管理的RabbitMQ实例，而是可以使用经过实践检验的无服务器消息队列SQS。

通常情况下，如果有一个无服务器或完全托管的解决方案，那么至少在为自己的解决要避方案投入过多的时间和精力以进行维护之前，先考虑采用这些方案是有意义的。

5.只使用自己熟悉的工具

在阅读Reddit或博客的一些文章时，经常看到许多工程师不愿意使用无服务器或容器编排平台，因为他们只知道EC2和人工管理的服务器。他们认为有些新技术可能只是昙花一现，因此没有必要改变自己的方式。这意味着转移到容器编排平台、无服务器和其他云服务是没有免的价值的。这似乎是一种谨慎的方法。最好挑战一下这种假设，用清楚的事实、成本和性能基准来判断新技术的可用性，而不是对新技术持怀疑态度。

6.没有使用无服务器和容器编排平台

如果要为所管理的每个服务和工具创建一个EC2实例，则可能会陷入维护的噩梦。但是，如果将每个服务部署到Kubernetes(EKS)或Fargate(ECS)集群的容器中，那么由于容器10的动态端口映射和更紧凑的资源利用(例如共享层)，可以将更多的资源分配到单个服务器实例中。

容器编排平台将帮助你确保实例之间的负载平衡，并使工作负载保持健康。这在某种程度上消除了猜测容量的情况。你可以指定在任何时候应该运行多少个容器实例，并且控制平台将确保它发生，就像你定义的那样。

如果可以轻松地在许多容器或无服务器资源之间实现负载平衡，那么不必个错再猜测哪种EC2或RDS实例大小适合自己的用例。

7.不考虑总拥有成本

如果只考虑硬件或服务成本，你可能最终会认为许多资源在内部部署设施中运行可能更具成本效益。但是，如果加上额外的维护、升级和员工管理这些服务器的成本，那么情况就完全不同了。

8.没有长远的思考

如果只根据当前情况扩展资源，则可能无法考虑到未来需求的变化。如果组织的业务和数据增长更好怎调整么办?如果结果正好相反呢?你的应用程序仍然易于更改，并适应未知的未来情况吗?最后，你是否能够找到并保留足够的员工以长期满足这些需求?

9.过度配置 “以防万一”

如果你要保证万无一失，可能会过度配置所有东西，以确保为应对使用高峰期做好准备。如果你可以根据过去的使用模式来证明过度配置的合理性，则这是一个很好的策略。但是，如果是出于直觉，这样做可能是一个错云计误的策略。

从某种意义上说，云服务可以提供弹性，你可以在集群中添加节点，在更多容器之间负载均衡工作负载，或者在需要时增加CPU数量或内存。如果配置和监视正确，则无需过多配置。这并不是说正确调整大小很容易，但是有了良好的流程和自动化，这是可行的，并且可以显著节省成本，尤其是在大规模运行大量资源时。

10.选择错误的数据存储

有时，瓶颈不是计算资源不算资足，而是数据存储选择不当。最好考虑一下：

你是否需要丰富的查询语言(SQL)，还是应用程序只需简单的键值存储即可(例如DynamoDB)。 首先是否需要数据库，也许一个简单的S3数据转储就足够了。

它自然取决于用例，但是数据库通常是构成任何可扩展架构的主要瓶颈。

如何解决云计算资源大小问题?

提高云计算资源利用率的一种可能的解决方案是采用自动化技源大术。例如，你可以使用Dashbird跟踪资源不足和资源过剩的情况，并获得有关它们的通知。使用结构良好的lens仪表板时，可以发现，具有EC2实例类型的ECS集群在过去一小时内的CPU利用率超过90%。

然后，可以深入到特定的时间间隔，并进一步检查出现这一使用峰值的原因。

同时，另一种容器服务可能会被超额配置，可能会浪费成本。有了这些信息，你可以根据小时实际使用模式优化资源配置。

结论

以上研究了调整云计算资源大小时的常见问题，并讨论了如何避免这些问题，并真正从云计算的弹性中受益。通过使用容器编排平台、无服务器和完全托管的解决方案，以及随着时间的推移持续监视使用模式，可以优化云计算架构的性能和成本。