在过去的一年里，我越来越多地遇到了一个新的角色——IT。它并没有接管编码任务，但他们肯定在应用程序开发任务的运行位置上扮演着更加积极的角色。这并不奇怪，因为软件开发对计算资源有着永不满足的胃口。无论是用于测试的大型集群、运行ALM工具的数十台机器，还是对"再多一个盒子"的不断请求，开发团队总是在请求一些东西。用你公司的开发团队数量乘以这个数字，就很容易明白为什么这对it来说是一项艰巨的工作。它的反应是越来越多地关注在运行开发任务的地方集中化。其逻辑是，有了开发资源云，他们可以在跨组共享资源时获得更高的效率，并为客户（开发）提供比其他资源更多的资源。然而，它的目标与开发团队的目标有很大的不同。IT组织通过计算环境的效率、流畅性和成本效益来衡量他们的成功。他们需要一个大型的、配置相同、可扩展的、不间断的环境，该环境能够始终如一地为下游客户提供既定的性能水平。换言之，他们越能让事情变得一样，他们的效率就越高。从表面上看，这些目标与发展相悖。开发团队的衡量标准是软件输出和质量，而不是资源效率。每个开发团队通常都有独特的需求来实现peek的生产力和质量。测试环境的矩阵永远不会缩小，与标准化的愿望相冲突。如果环境定制和优化使开发更有效（他们经常这样做），他们需要自己的资源，即使这意味着他们得到的资源更少。如何在这些相互竞争的目标之间架起桥梁？每个人的目标都是错误的，但这并不意味着每个人都不开心。正确的答案是定义一个能够同时实现这两个目标的环境。允许它提供计算云——这些领域是同质性和效率的亮点。这使得它能够通过在大型计算资源池中共享，同时降低成本，满足开发对资源峰值需求的需求。虚拟化是解决方案中的一个重要组成部分，因为它满足了它对同质性的需求和开发对配置专门化的需求。然而，虚拟化还不够。真正需要弥合差距的是一个框架，允许开发人员保持对运行什么进程、谁运行它们以及它们如何以及何时结束在计算云上的控制。这可能吗？我们最成功的客户都使用了electronic commander来完成这项工作。对于它来说，ElectricCommander使软件开发能够在一个大型、可扩展、可靠的开发云中进行。对于开发来说，他们得到了他们所需要的所有控制，只是需要更多的计算资源。