cpu负载转移内存_为什么将所有工作负载转移到云中是个坏主意

cpu负载转移内存

正如我们在本系列文章中一直探索的那样，云炒作无处不在，告诉您将应用程序迁移到云（包括混合云和多云）是确保企业数字化未来的一种方式。 这种炒作很少深入到迁移到云的陷阱，也没有考虑提高客户体验和敏捷交付新旧应用程序的日常工作。

在本系列的第一部分中，我们介绍了基本定义（以公平起见）。 我们概述了对混合云和多云的看法，确保显示了两者之间的界线。 这为第二部分奠定了基础，在第二部分中 ，我们讨论了三个陷阱中的第一个：为什么成本并非始终是迁移到云的明显动机。

在第三部分中，我们将探讨第二个陷阱：为什么将所有工作负载迁移到云中是个坏主意。

云端一切都好吗？

有一个误解，认为一切都将受益于在云中运行。 所有工作负载都不相等，并且并非所有工作负载从迁移到云都会对底线产生可衡量的影响。

正如InformationWeek所说： “并非所有业务应用程序都应迁移到云，企业必须确定最适合云环境的应用程序。” 这是一个很难的事实，在本系列的第二部分中，公用事业公司在尝试将应用程序迁移到云时，人工成本上升了。 发现这不是一个可行的解决方案，公用事业公司对此进行了备份并重新评估了其应用。 它发现一些应用程序使用率不高，而其他应用程序则存在数据所有权和合规性问题。 其某些应用程序未经认证可在云环境中使用。

想象一个虚构的在线旅游公司。 随着业务的增长，它将本地托管容量扩展到40,000台以上的服务器。 最终成为一次通过一次购买数据中心而不是一次机架来扩展资源的问题。 其业务消耗的带宽如此之大，以致基于带宽使用情况的云定价模型仍然令人望而却步。

获取基线

有时，在物理上无法在云中运行应用程序，但有时在财务上不可行。

如这些示例所示，最重要的是对应用程序环境有透彻的了解。 在充分了解需要将哪些应用程序迁移到云的同时，您还需要了解当前的IT环境，了解当前的资源水平，并估算迁移成本。

了解您的基准-每个应用程序的当前状况和性能要求（网络，存储，CPU，内存，应用程序和基础架构在负载下的行为等）-为您提供正确决策的工具。

如果由于复杂的获取流程而运行的CPU利用率只有一位数的服务器，那么按需配置资源的云可能是个好主意。 但是，首先请问以下问题：

• 这种低利用率存在了多长时间？
• 为什么不早点抓到它？
• 是否没有流程或有效的监控措施？
• 您是否真的需要云才能解决此问题？ 或者只是获取和管理资源的更好过程？
• 您会在云中拥有更好的流程吗？

是否需要容器？

许多人认为您需要容器才能在云中成功。 这个流行的流行语很好地总结了这一点，“我们将这种整体式容器塞满了一个容器，并称之为微服务”。

容器是达到目的的一种手段，使用容器并不意味着您的组织能够在云中成熟运行。 这与所涉及的技术无关，而与应用程序有关，而这些应用程序通常是在过时的技术已经过去的日子里编写的。 如果您将轮胎火烧入一个容器中，然后将该容器放到容器平台上进行运输，那仍然是某人正在使用的功能。

那火现在更容易扑灭吗？ 这些容器火灾给您的DevOps团队带来了更多挑战，他们已经在努力跟上组织将所有内容都迁移到云中所推动的所有更改。

请注意，将遗留工作负载迁移到云中不一定是一个错误的决定，将它们进行容器化也不是一个坏主意。 这是关于权衡利弊的因素，评估可用的选项，并为每个工作负载做出正确的选择。

接下来

在本系列的第四部分中，我们将描述每个人都应该避免使用混合多云的第三个也是最后一个陷阱。 找出云对您的数据意味着什么。

翻译自: https://opensource.com/article/18/7/why-you-cant-move-everything-cloud

cpu负载转移内存