面向一次性应用的一次性基础设施

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

会议议程。活动导航。特定任务，例如购房或申请汽车贷款。

如果您曾为上述任何事项安装过应用，那么安装的就是所谓的“一次性移动应用”（DMA）。这类应用专为单一用例而设计，预计会像宣传册一样在用完后被“丢弃”，删除后等到再次需要时再安装。因此，这类应用通常体量小、灵活且变化频繁。有时，它们只会短期存在，例如用于支持选举、世界杯或音乐节等活动；有时则会长期存在于“服务器”端，而不保留在客户端，例如用于引导用户完成住房抵押贷款流程。

这类应用日益普及，被视为一种“微应用”（与微服务非常相似，但面向第三方开发，而非内部开发）。

之所以需要关注这类应用，是因为它们的生命周期可能大不相同。从诞生到消亡，它们可能只存在几天、几周或几个月。这些应用会迅速出现，也会很快消失。它们大多是一次性的，因此支撑它们的基础设施也很可能是一次性的。

在数据中心虚拟化的时代，随着软件吞噬IT，这种想法已不像过去听起来那么疯狂。毕竟，我们并不是要扔掉价值数千美元的硬件。它们只是一些比特，按一下回车键就能轻松部署或移除。

如果您唯一关心的基础设施只是Web或应用服务器，这种做法或许不错。但实际上，这些应用需要具备可扩展性，也需要提升性能（毕竟它们是移动应用，大部分处理都在服务器端，也就是云端完成），因此还需要通常被视为网络基础设施的多个组件，包括负载均衡、缓存和优化服务。这意味着这些组件也需要“用完即弃”。它们必须能够以软件（或虚拟化）形式部署，并提供一套完善的API和模板，以便快速预置、配置，并在之后撤除。这也意味着它们必须为云就绪、支持云或实现云化（无论您偏好哪种营销说法），从而让支持这些用完即弃型应用的基础设施和服务，与其交付的应用一样灵活且可随时撤除。

这也意味着，DevOps方法对于管理这些高度动态的环境日益重要。在这些环境中，更多应用会在更短的周期内交付和弃用。采用单一、整体式的“一款应用涵盖所有产品和服务”方法，并不一定适合一次性移动应用的构思和交付方式。这类应用目标明确，专注于提供一组特定且不会扩展的功能。其他功能和用途则由其他应用实现，这会增加所需应用的总数，也给负责部署和交付这些应用的运维团队带来更大压力。每款应用都有特定的服务、配置和监控要求，必须根据应用进行定制。在应用领域，并不存在一种方案适用于所有应用。这与另一种情况形成鲜明对比：除性能或安全调整外，基础设施配置在应用的整个生命周期内可能基本保持不变。这意味着，负责管理基础设施的运维团队需要更频繁地处理更多、更复杂的工作

因此，基础设施不仅要实现软件化或虚拟化，不仅要提供强大的置备和配置API，还要注重融入由Puppet和Chef、VMware和Cisco、OpenStack以及Salt Stack等常用框架和工具集构成且不断发展的自动化生态系统。这些框架让持续交付从开发环节逐步延伸到运维环节，并使基础设施的投产和停用同样便捷。

软件正在吞噬IT，但这应当被视为一件好事。随着软件不断吞噬世界，应用和基础设施领域也随之增长。要管理这种增长，就需要采用DevOps方法，对应用和基础设施的整个生命周期进行管理。CA和Vanson Bourne在一项全球调查中发现，采用DevOps方法可带来可量化的收益：21%的受访者表示能够推出更多新软件和服务，18%的受访者表示产品上市速度有所加快。

要支持一次性应用及其交付所需的一次性基础设施，就必须具备这样的敏捷性和速度。IT面临的一个主要痛点是，网络仍然会造成阻碍。根据EMA研究，2014年，39%的组织将“为适应变化而手动重新配置基础设施的流程缓慢”列为一个重大痛点。

将DevOps应用于“网络”，有助于消除生产发布流程中的这一重大阻碍。为此，我们需要摒弃对网络本质的固有观念（网络就是硬件！网络不能动！网络不归我管！），并开始考虑网络中的哪些部分已适合像其交付的应用一样，作为一次性资源来处理。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章