谷歌的特长则在于简单易用。应用引擎让用户可以利用谷歌的自主开发数据库及其他基础架构软件；可以通过API使用缓存、镜像、邮件及其他应用服务。Python是惟一得到支持的编程语言，不过谷歌打算在将来也支持其他编程语言。
WindowsAzure和Azure服务平台与微软的内部部署企业软件系列其实一脉相承。Azure包括了托管版本的SQLServer、SharePoint、DynamicsCRM和.Net服务，用Visual Studio和.Net框架开发而成。微软表示，Azure将支持开放协议（HTTP、REST、SOAP和XML）以及非微软编程语言（Eclipse、Ruby、PHP和Python）。
如果IT人员要了解云体系结构的概况，云服务提供商的网站上提供了许多详细信息。亚马逊有一份介绍云体系结构的白皮书，想尽快补上一课的人不妨看一下。
你的设计蓝图应当考虑到云服务可能由多家厂商提供，所以要想好该如何确保互操作性和应用集成。云计算新兴公司Elastra的高级软件架构师StuartCharlton建议采用REST和Atom联合格式（AtomSyndicationFormat）作为全球云体系架构中的底层规范。他表示，联合身份管理方面的标准也很重要。
IBM公司自主计算开发主管DennisQuan表示，面向服务的架构（SOA）已经让通过“符合标准的方式”连接云服务成为可能。下一步关键是把服务从一个云迁移到另一个云。Quan表示，完成这项功能的规范仍处在开发初期。
三、数据保护篇
重视安全
开发人员喜欢“云计算部署后不用去管”的功能；公司希望通过云计算降低基础架构成本；用户则喜欢新的功能能够更迅速地推出。
然而，负责信息安全的人员在为如何把应用程序和数据安全地转移到云中而挠头。
IT界孜孜以求的一个目标就是整合身份管理技术和流程；而云计算可能让这个目标晚十年才能实现。
许多公司可能会把目录服务验证扩展到内部环境以外，以处理云中的应用程序、甚至系统；但如果第三方系统的安全受到危及，这种做法会导致验证系统岌岌可危。公司也许可以实施一种新的解决方案，让云基础架构管理与现有的基础架构管理相互独立。但缺点是，必须集成多个身份和访问管理系统。还有一种办法是及时回去、单独管理云，但这缺乏吸引力。
幸好，有些云服务提供商正在竭力解决这个问题。谷歌提供了这项功能：把GoogleApps与目前实施的单点登录技术结合起来，从而加强安全、简化管理。一家知名互联网公司部署了边缘验证服务器，让云系统通过轻型目录访问协议（LDAP）进行验证。另一家公司则扩展了基于Web的验证协议，通过Web服务来进行验证；验证通过，即可访问其内部的系统。
数据丢失与备份
数据存储在哪里？谁可以访问？数据安全吗？这些都是重大问题，因为没有几家云服务提供商在处理敏感数据方面证明一向很可靠，许多软件即服务（SaaS）提供商除外。如果数据保存在共享存储系统上，要料到可能面临风险。其实，即使我们放在自己公司内部的数据也面临风险。需要把衡量内部数据效益与风险的同一套措施用于衡量云，然后确定哪些数据可以放到云上、并如何保护。这就需要知道及核实提供商采用的标准以及改动标准的灵活性有多大。
企业使用亚马逊的弹性计算云等服务时，可以在虚拟实例中运行的操作系统、应用程序或数据库管理系统里面采用数据加密。其他服务（如应用托管服务）提供商在开发应用程序时需要更全面的考虑，确保已包括加密等安全措施。
不管自己的数据在哪里，公司都应当防范数据丢失。亚马逊知道计算机会出故障，所以它劝告公司要借助冗余和备份措施作好防范故障的规划。有些云服务提供商提供备份服务或者导出数据的方法，那样公司可以自己备份数据，另一些提供商要求客户使用自定义或第三方的应用程序。
因此，我们不妨牢记下面这些关键因素：
——备份如何进行？有些云服务提供商进行备份，不过更有可能是你想自己进行备份。亚马逊EC2的许多客户还使用亚马逊的简单存储服务（SimpleStorageService，S3）或弹性块存储（ElasticBlock Storage）用于存储备份文件。
——备份经得住测试吗？如果服务无法使用，你能访问备份数据吗？
——备份数据将放在哪里？它也许放在云存储系统上、由提供商来托管，或者转到你自己的基础架构。不管怎样，你还是要知道备份数据在存储和传输中，数据得到了怎样的保护。
管理与监测
许多公司的信息安全团队平时经常监测安全漏洞邮件列表、给系统打补丁、改写代码以解决缺陷。在云中，他们相信提供商事先至少对一些方面进行了调查。很少有提供商让客户可以核实自己采取的安全做法，不过有些提供商变得更愿意配合。公司在使用Joyent或亚马逊的EC3等云系统时，可以在操作系统、数据库和应用程序等层面采取安全措施，但他们仍依赖各自的提供商确保网络、存储和虚拟基础架构的安全性。
尽管云服务用户并不控制实际的打补丁和漏洞监测工作，但他们仍有责任管理自己的风险。所以他们要评估哪些资产需要保护、如何防护这些资产，包括在云基础架构上添加安全措施。即使那样，支付卡行业（PCI）标准等行业法规仍可能会让人措手不及，因为PCI委员会方面没有明确规定如何对云服务提供商进行分类。这可能意味着，不同审计人员对待云服务提供商的标准会略有不同。
云服务客户必须要求保证自己可监测谁在访问自己的数据。如果公司要求提供详细的审计跟踪记录，应当采用数据加密；或者只把所处理数据不是特别敏感的应用程序交给云服务提供商。
这个方面可能会迅速得到改进。谷歌近期表示，GoogleApps的安全流程已通过了SAS70Type II审计标准。预计会听到更多的提供商宣称自己的安全标准，因为安全仍是导致公司不敢把应用程序转移到云中的一大障碍因素。
当然，内部信息安全团队不应该坐等提供商来加强安全。从桌面应用程序到服务器托管的各个应用领域，云计算都会变得越来越诱人。需要更高安全级别的应用程序，比如与《健康保险可携性及责任性法案》（HIPAA）或PCI相关的应用程序，可能在云中更难得到保证，因而放在公司内部比较妥当。社区应用程序和内容网站比较适合放在云中。公司的技术团队必须确定把什么数据放在云中不会有问题，但他们也要明白：云最终会是整个基础架构的一部分；还得要自己弄清楚如何把企业系统与云基础架构安全连接起来。
四、网络篇
一家地区银行在试用成功后决定全面使用Salesforce.com服务，但却没有考虑到以后需要更多的带宽。当员工们的互联网连接突然变得慢腾腾时，这家银行为所犯的这个错误付出了代价。
网上传输的数据急剧增长，预示着没有投资于更多带宽的公司会面临带宽危机。但带宽不是惟一潜在的网络问题。数据传输距离长会带来延迟问题；而互联网的稳定性不确定，加上服务提供商的数据中心充满未知因素，更是带来了可靠性问题。
公司只要升级带宽就能缓解其中一些问题。一家医疗公司就把带宽增加了五倍，将后端批事务处理转移到亚马逊网络服务。幸好，带宽价格在不断下跌，但公司仍需要认真规划。
一些技术有助于评估分析流量，比如Packeteer公司的PacketShaper；大多数防火墙厂商允许客户免费试用30天的报告服务，这种服务可以告诉公司使用了多少带宽。网络集成商GreenPages的首席技术官MikeHealey表示，云服务提供商的带宽要求往往不可靠或很难弄到，所以公司至少应当一方面基于试用数据来评估带宽要求。Healey表示，为了准备好应对高峰需求，公司应当规划确保足够带宽，以便自己的带宽利用率平均不超过75%。
