长期以来，人们一直说应用程序的性能有四大支柱：
1.记忆；2.CPU；3.网络；4.存储。
只要你在对应用程序的响应时间做出反应，解决了其中一个问题时，另一个就成为了瓶颈，即使你并没有触及这个瓶颈。
更详细一点说，他们是：
“内存消耗”——因为在现代操作系统中，这会影响交换。
“CPU利用率”——因为无论什么操作系统，在某性能极端下降后都有一个神奇的线。
“网络吞吐量”——因为应用程序必须通过网络进行通信，而不论阻止与否（今天几乎所有的网络编码），网络上所要求的信息是必要的，并最终将限制代码块继续执行。
“存储”——因为在从磁盘中读/写、或读/写到磁盘中时（或在OS转换出/回记忆时），IOPS很重要。
这四个相对比较容易跟踪。这种关系是非常容易发现的，当你解决了一个问题，另外一个却成为对应用程序的性能来说“最危险”的。但是，从历史上看，你总是有权访问硬件。即使在高度虚拟化的环境中，这些项目可以被认为是在主机和客户机的水平——因为单个虚拟机和整个系统都很重要。
当移动到云中，四大支柱变得远远没有那么易于管理了。“远远”所指的程度，在很大程度上取决于你的云供应商，以及你如何定义“云”。
把简单来说，如果你突然受袭击导致失明在你面前的景物并没有什么变化，变化的只是你感知它们的能力。
在PaaS的世界中，你只有供应商提供的工具来衡量这些东西，且被敦促不要考虑主机可能对你的应用产生的影响。但它们确实有影响。在IaaS的世界，你或多或找会有更深入地了解，但正如其他人所指出的，比在你的数据中心的控制要少。
在SaaS的世界里，假设包括在“云”中，你有零位控制，且没什么了解。如果你的应用程序不执行，你必须跟供应商的员工交涉（但愿如此）让他们解决问题。
但这个问题在云中会比在数据中心更糟吗？我会认为没有。你的感受能力、触摸能力下降了，但实际问题并没有变少。在一个单一业务公共云部署中，应用程序的性能在很大程度上取决于供应商，但顶级供应商（如亚马逊）备份，会根据需要制造副本来减少工作负载。这与一个在高度虚拟化环境中常见的表现技巧相去并不甚远——带来了另一台服务器上的另一个虚拟机，并把它们添加到负载均衡。如果应用程序设计不当，最终的结果不是你购买服务器到主机实体，而是说，而是你直接购买实体。
这对IT有影响。降低使用低效应用程序的前期成本——无论它在四大支柱中的哪个方面低效——意味着IT部门更容易忍受效率低下，即使在长期运行上每月支付成本可能远远比购买一台新服务器的成本高，仅仅是因为预算疼痛的减少。
有很多公司提供云部署的信息，可以帮助你确认自己是否觉得盲目。
虽然了解并不总是与采取行动直接相关，有一些只有云服务提供商可以为您提供的信息，知道的性能瓶颈在哪里至少能提供给IT人员一定程度的决策制定依据。如果一个应用程序执行不佳，调查一下出现了什么问题（你可以告诉说是网络带宽，虚拟机CPU使用情况，虚拟机IOPS等，但不包括发生在物理硬件上的问题）可以令决策制定知道如何将云运营成本包含在内。
内部云是一个更容易的东西，你仍然有机会获得云出现之前的所有信息，一般情况下，是使用与高度虚拟化的环境中相类似的调查。从解决性能问题的角度来看，这是大致相同的。虚拟化和内部（私有）云的关键是，你意图最大限度地利用资源，所以你将不得不更密切地观察这些瓶颈——你处于离性能问题更近的“边缘”，因为你就是这样设计它的。
在云计算和虚拟化环境中，一个全面的日志和监控环境，可以在保持突然出现的问题方面走很远——尤其是在运行着许多应用程序的大型数据中心。
对于内部开发的应用来说，对内部开发人员进行怎样才能不耗费资源的教育是很有用的。对于外部开发的应用程序，你能做的最好的事就是要求尺寸信息，并在购买前测试他们的假设。
有时候，云实在是正确的选择。例如，如果网络带宽是主要的限制因素，且你的组织这些可感知的安全/合规风险，那么云计算是一个简单的解决方案——在云中带宽是不受限的，或者被你每月写支票缴费的意愿而限制。无论哪种方式，它不是一个极端昂贵的互联网连接升级。
坚持获取你需要的能见度，不用担心那些你并不需要的东西。
