根据Forrester的调查显示，在面临云计算选择的时候，企业客户似乎对IaaS（基础架构即服务）更为感兴趣，而不是paas（平台即服务），虽然paas使用起来更方便。不过，两者之间的界限开始模糊，这都要归功于Amazon Web Services LLC的新产品和突然杀出的Standing Cloud。
对paas的担忧主要集中在锁定方面，开发者和基础架构和运营专业人员担心在paas的服务之上编写代码，他们的应用会丧失可移植性（这种担心也一直存在于中间件领域–paas或者其他的方面。）结果是，IaaS平台让你可以控制中间件的配置模式，在操作系统和虚拟机资源选择上更为开放和自由。可是，这是一场交换，开发者用复杂性换来了自由。在下面的图中，我们可以看到云服务的抽象程度和所需客户技能之间的对照关系。如果你的配置技能仅限于脚本、网页设计或者创建表格，那么绝大部分的SaaS平台都提供了抽象的功能。如果你是一名真正的编码者，会使用Java、C#或者其他的语言，paas让你可以建设更复杂的应用和基础架构，而且你不用自己管理中间件、操作系统或者基础架构配置。paas服务可以帮你完成这些工作。然而，IaaS则需要你了解这些。结果，这两种云服务拥有了大量截然不同的潜在客户。虽然IaaS对企业用户来说吸引力最大，但是它也是最难使用的一种云服务。
抽象决定适用性
那么IaaS应该如何拓宽他们的市场呢？变成paas模式可以让他们轻松些，但是锁定的问题又出现了。你如何才能够在保持对IaaS控制的同时，不让自己的客户基础变成传统的IT人士的坟墓？答案在于提供工具，通过提供最佳实践基础架构选择，帮助客户降低部署工作的难度，帮助你建立高可用性，可扩展的IaaS服务。
这正是AWS Elastic Beanstalk今天为基于Tomcat的应用所做的事（对着它的不断成熟，将可以支持越来越多种类的应用）。Standing Cloud提供了类似的价值，让你可以在IaaS中部署无数的开放源代码软件，但是应该更进一步，让你可以在多个云之间进行选择。
两者都能够拓展IaaS云计算市场，让这种模式对企业更有吸引力，但是这两个产品却并不是彼此直接竞争的关系。Elastic Beanstalk的目标是加快应用部署的速度，但是允许你随时打开AWS的最佳实践选择。如果客户自己具备相应的技能，或者拥有IT团队，你就可以针对配置和性能进行优化，调整服务选项，让你的配置更为经济有效。Standing Cloud瞄准的是中小型企业用户，以及为这些客户提供服务的供应商，这些客户不应该（也不会希望）中断过程，自己配置。他们希望的是SaaS级的简单。
能够帮助IaaS变得更简单的，不只是上面提到的这些产品；RightScale、CloudKick以及其他很多产品都提供了类似的功能。但是这些解决方案更多地是针对DevOps或者企业架构专业人士的–那些有着更多设计和基础架构技能的人；也就是那些传统的IaaS买家。
微软还试图模糊IaaS和paas之间的界限。在Windows Azure 上的VM role并不是一种单纯的IaaS功能，它确实提供了更多的控制功能，让你可以部署自己的系统，内部的IT人员不用像paas模式下那样受制于人。
随着这些市场的不断成熟，我们会发现这两者之间的界限会变得越来越模糊，这会让更多的客户进入这个市场，但也会带来困惑。重要的是要关注服务的核心是什么，这些变化并没有改变服务的核心，以及它们所能够提供的价值。Elastic Beanstalk对IaaS进行了简化。它并不对中间件或者云平台服务进行抽象。这些工作都需要你来做。一旦建设完毕，你就必须自己进行管理。如果你希望简单一些，那么RightScale和rPath之类的工具就非常有价值了。不希望自己管理或者缺乏相应的技能？可以考虑聘请Datapipe或者CapGemini这样的专业公司来完成这些工作。
如果你不想管理中间件或者操作系统–你只是希望它能够工作–paas是更能满足你需要的一种模式（和拥有企业内部的应用感觉一样）。
