软件的演变可能是交付渠道创新的故事——从大型机到个人计算机、特定于硬件的应用程序到跨架构编译、桌面到移动、本地到云。这些新的交付方法为开发人员提供了一个独特的机会,可以通过相同的应用程序接触更多用户。好处是显而易见的:一次编写,随处可用。我们可能会使用可移植性这个词,然后,用非常笼统的术语,作为软件的一个特征:高度可移植的软件可以编写一次并在任何地方部署。

便携式应用程序需要较少的开发和操作工作,即使它们暴露给更多潜在用户。不过,同样的价值也适用于软件团队的内部运营。在现代微服务架构中,开发人员还扮演消费者的角色——消费组织内外其他团队创建的服务和 API。因此,应用程序的可移植性对软件公司的内部运营非常重要。

今天,我们将阐明可移植性在云软件的背景下意味着什么,以及为什么它对您的客户和您的团队成员都很重要。

“它在我的机器上工作”

软件团队通常使用“环境”一词来描述应用程序运行的环境。这是一个广义的术语——你可以用它来指代特定的机器、操作系统或整个网络。重要的是,这个词包含了一个具有重要含义的基本概念:上下文因环境而异,如果您的软件依赖于上下文,那么它的行为将因环境而异!这种区别通常是软件功能不佳的罪魁祸首:它似乎在一个地方工作,但当你在其他地方运行它时就会出现错误。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--T1LBuA4U--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/nbutchbdxy0nw3x40wpz.jpeg)

将软件的逻辑与环境的特征区分开来是开发任何软件应用程序的核心技能,它是一项旨在实现上述目标的技能:可移植性。将软件与其环境隔离的开发人员会发现自己拥有一套优雅的业务逻辑,无论它在哪里运行,它们的行为都是一样的:他们自己的机器、公司的 QA 环境、他们的生产云,甚至是他们客户的云!

谁从软件可移植性中受益?

IT 部门:云提供商商品化

如果有机会,聪明的企业会限制其硬依赖。供应商锁定引入了一个中心故障点,使公司面临服务中断和供应商的定价突发奇想。水平应用程序可移植性的特点是最大限度地减少环境切换成本,这样 IT 部门就可以避免供应商锁定。如果您可以在 GCP 或 AWS 上轻松运行您的应用程序,您就可以避免将您的公司固定在一个云提供商的正常运行时间和定价上。

开发人员和 DevOps:构建和发布可扩展服务

即使在小型软件团队中,环境也会迅速增加并不少见。开发人员需要在本地运行应用程序,质量工程师需要在测试环境中运行,销售代表需要在演示环境中运行,操作员需要在暂存和生产环境中运行应用程序。

开发/测试/演示/部署生命周期的成本与应用程序的可移植性直接相关。随着新版本在整个生命周期中移动,需要大量与环境相关的配置和调整的软件将花费时间和精力。可移植性为涉及跨环境移动新版本软件的任何人节省了时间和精神开销。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--TV9_7s6r--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/yjnx4owp801orxl8xsn4.jpeg)

销售:增加潜在市场

出于安全原因,许多潜在客户更喜欢在自己的场所运行供应商软件。如果企业生产刚性软件——需要特定的操作系统、云提供商、嵌入式安全和广泛的环境配置——企业会无意中将其目标市场限制在满足这些条件的客户中。另一方面,一家发布便携式软件的公司取消了对其目标市场的这些限制。

软件可移植性的三个维度

构建可移植的软件实际上鼓励了支持许多其他有价值属性的模式。假设您使您的软件更容易在这里或那里运行。因此,在这里和那里运行它更容易:支持环境内和跨环境的复制,并使跨团队和组织的工程师能够自己操作软件。提供完全可移植性且易于开发人员运行的应用程序更易于构建。具有出色可移植性的应用程序具有出色的可扩展性。

那么我们如何知道我们的应用程序和服务是否可移植呢?它们可以在某些方面便携而不是其他方面吗?为了自己确定这一点,让我们评估我们的应用程序可以移植的三个不同维度:

1\。复制(深度)

可移植性的第一个维度对于大规模运行云应用程序至关重要——扩展和复制。您的服务能够维护作为一个内聚单元工作的多个运行实例的能力对于其支持大规模并发用户的能力至关重要。一致的打包机制,如 VM 映像和容器,通常是在云环境中大规模自动复制服务的关键。尽管如此,这种复制仍需要一致的方法来进行负载平衡和分配传入流量。通过将打包一致性与 API 网关、服务网格和其他负载均衡解决方案相结合,团队可以快速实现深度应用程序可移植性。

2\。平台/提供商迁移(水平)

可移植性的第二个维度通常是大多数人在考虑云可移植性时首先想到的——云迁移和/或多云部署。让您的应用程序在多个平台上运行的能力是一种很好的防御策略。它确保云应用程序可以保持成本效益并防止中断。将应用程序设计为在商品基础设施(例如,Linux 与 Windows)或多个云提供商(例如,AWS、Azure 与 GCP)上运行,使团队能够同时在多个位置运行,或者在定价证明有利时更换提供商。

3\。开发生命周期(垂直)

可移植性的第三个维度经常被忽视,尽管它比横向移动性更有影响力。这是通过软件开发发布周期的可移植性。软件开发人员不断在应用程序堆栈内构建或修改服务。因此,他们发现自己需要在可以确定与生产相匹配的环境中进行测试。从本地开发到测试/QA/staging,最后到生产环境的应用程序上下文的一致性对于确保信任、维持强大的开发流程以及确保产品功能快速安全地呈现在客户面前至关重要。

历史与未来

对便携式软件的向往并不新鲜。 Java 虚拟机的开发是迄今为止最成功的软件可移植性创新之一。现在,任何机器都可以运行单个编译的 .jar 文件和任何操作系统并显示相同的行为。使用 Docker,应用程序可以更进一步:整个操作系统可以作为轻量级工件交付并在任何地方运行。

请注意注意事项,并注意与整个可移植性概念的看似不一致的地方!如果 java 需要安装 JVM,这不是对我们讨论过的所有内容的严重违反吗?唉,好像是这样。这里有另一个与可移植性相关甚至相反的概念:平台。便携式软件仍然需要由某些东西执行;一个平台,一个操作系统,一个环境。随着开发人员努力使他们的应用程序更便携,公司也努力使所有应用程序都可以在其上运行的“通用平台”便携。微软尝试使用操作系统、使用窄 VM 的 Oracle、使用更通用 VM 的 Docker,以及最近使用开源硬件抽象和 Terraform/Cloudformation 以及可重复的基础设施即代码模板的 Kubernetes。

真正的便携性

应用程序真的可移植吗?回答这个问题的最佳方法是查看我们自己的应用程序。我的应用程序是可移植的吗?我可以与其他开发人员共享我的应用程序吗?他们可以使用自己的工具和硬件运行或访问它吗?

该行业在允许云软件变得可移植方面取得了巨大进步。每次创新都为软件架构带来了进一步突破界限的新机会。昨天我可以通过将其放入 AMI 或 Docker 映像中来制作一个可移植的单体应用程序。今天我的应用程序包含多个单独运行但仍需要连接在一起的图像。对便携性的追求是一种持续的努力,但追求的价值始终存在。

在 Architect.io 博客上了解有关现代持续交付实践的更多信息!

• 秘密管理基础知识

• GitOps 开发人员指南

• 为什么分布式应用程序需要依赖管理

和往常一样,我们很乐意在 Twitter 上继续对话!找到我们@architect_team。