组织在将业务迁移到云平台时，遇到的最常见的问题之一是成本。采用云计算，组织可以将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)集群的容器中，那么由于容器的动态端口映射和更紧凑的资源利用(例如共享层)，可以将更多的资源分配到单个服务器实例中。
容器编排平台将帮助你确保实例之间的负载平衡，并使工作负载保持健康。这在某种程度上消除了猜测容量的情况。你可以指定在任何时候应该运行多少个容器实例，并且控制平台将确保它发生，就像你定义的那样。
如果可以轻松地在许多容器或无服务器资源之间实现负载平衡，那么不必再猜测哪种EC2或RDS实例大小适合自己的用例。
#7不考虑总拥有成本
如果只考虑硬件或服务成本，你可能最终会认为许多资源在内部部署设施中运行可能更具成本效益。但是，如果加上额外的维护、升级和员工管理这些服务器的成本，那么情况就完全不同了。
#8没有长远的思考
如果只根据当前情况扩展资源，则可能无法考虑到未来需求的变化。如果组织的业务和数据增长更好怎么办?如果结果正好相反呢?你的应用程序仍然易于更改，并适应未知的未来情况吗?最后，你是否能够找到并保留足够的员工以长期满足这些需求?
#9过度配置 “以防万一”
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
