云计算可以无限扩展，并不意味着应用程序中的每个组件都应该这样。当运营商不参与设计和测试时，团队可能就会浪费资金，并降低应用程序的性能。
在应用程序投入生产时，再去修复可扩展性问题已为时过晚。相反，需要关注开发和运营合作伙伴关系以及集成测试。
云计算的可扩展性使用户能够随着负载的增加而扩大资源消耗，但是普遍的资源增长是不够的。并非应用程序的所有组件都需要相同的乘法运算，并且其扩展不会造成紧张的组件的负面后果。智能扩展只会增加支持重载应用程序组件的资源。运营团队需要在设计流程的早期就开发人员与应用程序可扩展性进行沟通，并确定组件的启动时间和方式。这些团队应该通过集成测试一起工作，以确保应用程序在扩展以满足需求时保持性能和可靠性。
应用程序可扩展性是棘手的业务
此示例显示了扩展资源可能出现的问题：不同分支机构的两名工作人员几乎同时开始交易，以销售某种东西。交易服务检查库存，销售产品并输入订单。而在云中，同一应用程序的两个实例为这两名工作人员提供支持。每个实例检查库存，以找到产品和订单，但在第二种情况下，其库存水平不反映第一个订单正在处理的事实。
弹性扩展会创建不可预知数量的应用程序组件实例，并且这些实例不一定能够彼此识别。独立组件扩展对这种冲突构成了主要挑战，但传统实践通常只处理双倍或N ＋ 1冗余组件。云爆发是通过容器托管、虚拟化和私有云工具实现的，云扩展可以来自公共云自动缩放功能和混合云管理器。有数百种工具可以实现突发和扩展，而这些工具通常不会期望组件知道云爆发过程。
IT运营团队跟踪哪些工作负载处于高度或过度利用状态，以及托管资源应扩展以适应需求，但如果应用程序组件不能有效扩展，操作无法确保应用程序的可扩展架构。 DevOps的一个宗旨是将开发人员对应用程序部署和管理的要求转化为运营术语。那么将什么转化成运营需求，即云计算环境中的可扩展性？对于应用程序可扩展性和基础设施灵活性，应该通过运营为开发者提供哪些具体的细节？
开发人员在应用程序扩展中的角色
应用程序开发人员必须了解软件使用的场景。并非每一笔交易都具有冲突的风险，只有那些试图更新相关数据库元素的服务。某些应用程序需要具备防火墙来确保与给定事务关联的所有消息都转到相同的处理组件。有些还需要状态控制，以便它们像功能组件或微服务一样运行。缩放组件的场景感知也可以解决性能和功能方面的问题。
这些是只有开发人员才能解决的问题。IT运营可以扩展可用的云资源来支持软件组件，但不能保证应用程序的性能会更好。开发人员必须知道如何设计应用程序可扩展性以及哪些组件需要它。如果没有预期或有用的情况下增加对扩展的支持，将会增加开发成本和时间，并且可能会降低应用程序性能。当组件跨多个应用程序共享时，其问题尤其严重。一个开发团队不一定知道使用相同组件的其他组件。
部署范围和集成测试
在软件开始生产时，任何尝试解决应用程序可扩展性问题的尝试都是无效的，而且在许多情况下完全不切实际。相反，在开发早期就提出可扩展性假设的运营反馈意见，然后在生产之前验证它们。在应用程序开发周期中，最方便的阶段是集成测试。
开发人员以各种方式创建可扩展架构。例如，微服务和基于容器的体系结构自然会鼓励独立扩展。一旦开发人员了解如何扩展，以及如何与IT运营商讨论如何确定组件的可能部署参数是合适的：在数据中心内部，数据中心和云计算之间，云计算提供商之间，或在一个云提供商的平台中。
应用程序必须扩展的基础设施范围确定了组件对网络连接传输延迟的敏感程度，新实例的启动延迟以及其他实际性能因素。如果可扩展性的开发目标不能在运营中得到满足，那么开发计划或部署计划必须进行调整。网络连接、部署的合规性和治理，甚至云计算提供商的选择都可能发生变化。
集成测试是开发人员和运营专家第一次查看与组件化应用程序相关的信息流，并检查可扩展性如何影响应用程序性能和稳定性。测试人员将各个应用程序组件组合起来，以评估它们在实际工作流程中的工作方式集成测试可能会暴露孤立应用程序组件中的扩展问题，以及更高级别的问题。集成测试必须尽可能模仿实际的生产部署。
功能开发人员和应用程序所有者往往会忘记部署的组件必须进行负载平衡并连接到工作流程中。运营旨在以优化托管资源、网络连接性和其他注意事项的方式部署应用程序，但是当更新数据库不受运营控制时。一旦应用程序已经建立，管理工具就没有什么区别了。如果最佳部署方案不够好，则无法对其进行重新制作以掩盖不适合的体系结构。那就有些为时过晚了。
将集成测试作为未来生产系统的试验场，并从该测试环境中培养开发／运营伙伴关系，以应对应用程序自身成长时的挑战。
