复杂性是云计算普及路上的一个潜在杀手：为了实现云服务所承诺的可扩展性以及高可靠性，基于云的系统架构就会变得越来越复杂。而服务本身必须设计具有足够的冗余度并且有自我监控能力，数据必须能够自动备份到多个不同地点，同时多个服务器间的工作负载必须平衡。随着企业越来越多的关键性应用迁移到云环境，系统错误的风险，以及与任何错误相关的成本损失，都会相应的增加。
在传统的IT系统中，使风险最小化的方法就是设置监控和报警系统。与这些系统不同，随着云计算系统的复杂性日益增加，任何人或者团队都无法对于系统出现的故障做出足够与及时的反应。而随着云服务之间的交互性越来越强，很难快速锁定系统错误的始发点，而人工介入调查往往会导致更大的风险出现。
如果雇佣大规模的IT团队来管理云服务系统，就意味着将企业应用迁移到云服务所带来的成本节约效果完全消失。而降低云服务系统的复杂性，看上去也并不是一条可行的路线。
而唯一可行的方案，就只能依靠自动化的任务管理工具了。随着云架构、平台以及软件的进化，很多专业性的云服务管理解决方案应运而生，这些方案可以让企业在云上的日子过得更舒适。
基于云的监控和报警
此类工具中最好的产品属于基于云的自动化监控工具。此类工具可以让任何人监控不同服务器上的多种资源，并根据所监控的任何参数设定报警触发机制。此类产品的代表之作是Amazon的 CloudWatch 和CloudKick (目前已经被Rackspace收购)。这两款解决方案都支持对资源的实时监控，并自带多种报警设置。这两款产品同样都拥有丰富的可视化界面，并且具有可扩展性。 CloudKick支持所谓的“插件”，即客户自定义的监控脚本，而CloudWatch则通过API的方式与其它应用程序通信，获取监控信息。
这两款解决方案的不同之处在于它们的监控范围。CloudWatch 的监控重点放在Amazon自身的服务器和服务上，并通过API以及客户的相应开发，来支持其它服务器。而CloudKick则可以支持更多的云服务供应商，虽然这种支持是通过代理来实现的，但这些代理可以支持多种操作系统。因此他可以更快更容易的开始监控任何云服务器，而不管是哪家的云服务供应商。
另一种方案是由很多大型云服务供应商提供的云服务器管理服务。虽然这种方案并不算真正的自动化工具，但是却可以让管理云服务器的工作变得更简单。但不幸的是，这些服务一般都非常昂贵。而如果考虑到价格差异，为了获得高可靠性的另一个方案就是选择多个云服务供应商，这意味着会有不同的人来管理企业架构的不同部分(基本上也会有不同的服务等级)，这种方案基本上没有任何吸引力。
从监控到自我修复、直至更高级的功能
一旦应用了上述监控解决方案，原本由管理员手工处理的工作就转为了自动执行的任务。很多云服务供应商都带有自己的报警系统，可以集成进监控解决方案中，此类功能可以通过电邮，电话或SMS短信的方式将警告信息发送给管理员。但是报警仅仅是第一步。
诸如Rackspace 和 Amazon这样的供应商可以提供API，通过API可以实现一系列自动化任务，实现系统的可靠运转。比如，一旦监控系统检测到CPU或内存超载，系统就会自动加大CPU或内存的处理能力，同时将报警信息传递给技术支持团队。在极端情况下，该方案还可以自动将出现问题的服务器下线，并将该服务器的IP动态分配给新的服务器，而这个过程作为用户是察觉不到的。
监控自动化是把双刃剑
和很多以技术为基础的解决方案一样，监控自动化解决方案也是一把双刃剑。在一些失败的案例中，自动化的数据恢复过程可能会导致灾难性的后果。实际上，Amazon在去年4.21日就出现过这样的情况。当时一个配置上的错误导致了一个可用性错误，继而触发了系统的自动化响应机制，最终导致大范围的系统不可用。同时，在安装设置过程中必须确定的一系列元素，也使得人工参与管理变得很不可行。
当然，如果依赖于传统的监控系统来跟踪云应用服务，也不是不可行，只不过传统的监控系统不是针对监控云应用而设计的。而这些产品中的大部分要么是没有针对云环境进行商业化开发，要么就是缺少某种监控云服务所必须的功能，或者是许可证费用太高。自动化并合理的使用API对于监控系统来说十分重要，尤其是在云环境中。因此，企业应当尽量使用专业的云解决方案。
