液态软件的远景

要么快速释放，要么死亡

现代工业已经发展到这样的地步:一家公司的生存取决于它发布软件的速度，以及在计算边缘保持软件更新的速度。虽然这在科技公司中可能更直观，但对于表面上处于其他垂直领域的公司来说就不那么明显了。首先，让我们消除这种区别，模糊界限。维护复杂的网站、移动应用程序、装配线、销售渠道、分销链和许多其他功能都需要软件，而这些软件大部分是在公司内部开发的。因此，在实践中，每个现代公司都是(或至少拥有)一个软件开发组织，并且必须具有快速发布软件的能力。以下是一些原因。

保持竞争优势

在任何市场上，一家公司必须能够不断改进其产品，以便在竞争中脱颖而出。只要一家公司增加了一项市场需求的新功能，其他公司就会争相添加并迎头赶上。为了在竞争中保持领先地位，公司需要不断地用新的能力来设定步伐，把争夺的机会留给其他人。

修复bug和问题

对于最终用户来说，没有什么比软件不能工作更令人沮丧的了。当“点击按钮”并不能产生预期的结果时，用户的注意力持续时间很短，耐心也很少。他们很快将业务转移到其他地方，并浏览到无处不在的竞争。无论该公司运营的是电子商务网站还是预订系统，漏洞的存在都可能很快导致数百万美元的损失。

移除安全漏洞

网络安全市场已经预计到2020年将达到1700亿美元．这证明了公司为保证软件安全所付出的努力。在公司系统中发现的安全漏洞必须尽快修复。一家公司越快发布软件更新以消除检测到的漏洞，就能越快地保护其软件。因此，很明显，快速发布软件对公司的成功至关重要，并且每个版本都有一个标识符——版本号，但这也在变化。

消失的版本

在过去，每两年发布一次软件是一件大事，需要花费数周的时间来准备，而且由于代码的大量更改，这是一项冒险的任务。在接收端，客户将花费大量时间解压软件，验证其不同部分，并测试其与当前系统的集成，直到最终(并且小心地)将其部署到生产环境中。每个整体版本都隆重地标记了一个版本号。这是软件的一个关键参数，因为它确定了所有协同工作的部分，支持人员也需要它来处理客户报告的任何问题。今天，“版本”的概念由于三个因素而逐渐消失:短发布周期、分布式软件和物联网(IoT)。

软件自动化极大地缩短了发布周期。交付速度如此之快，以至于一些有远见的公司每天都要发布好几次软件。客户不再希望(甚至没有能力)为每个单独的版本解包软件、测试和验证它。他们只是想知道他们在任何时候都处于“最新”的稳定版本，并且它将顺利地与他们当前运行的系统集成。实际的版本号无关紧要。此外，软件正变得越来越分布式。曾经可能作为一个完全在prem本地化的安装运行，今天，作为云上的微服务数组运行，其中每个微服务都在一个独立的发布周期中更新。随着每一次“微更新”，“宏版本”都会发生变化，这实际上使“宏版本”变得毫无意义，因为没有人真正知道他们正在运行的是哪个版本。

最后，连接到互联网的设备数量呈爆炸式增长，预计到2020年将超过500亿台。随着越来越多的设备接入电网，管理它们的软件更新只能
无需人工干预的自动更新可以有效地处理，设备也不会真正关心它们运行的是哪个版本。

液体软件和持续更新

我们从具有独特版本号的单片手动软件发布开始，然后以快速、自动化的周期发布分布式微服务构建的软件，但没有有意义的版本号。如果我们现在将当前的状态推断到不远的将来，我们可以想象这样一个世界:发布周期变得如此之短，微服务变得如此之小，以至于在任何时候，都可能有一些东西正在更新。实际上，软件将变成“液体”，因为我们将连接到“软件管道”，将更新流到我们的系统和设备中;液体软件持续自动更新我们的系统，无需人工干预。

虽然这个想法可能会让人惊讶，但这个概念并不陌生，事实上，我们在日常生活中已经遇到过它。我们打开水龙头，想当然地认为水会流出来。我们相信市政当局会确保水足够干净，可以饮用，或者向我们发出警报和警告，告诉我们这些水只能用于洗澡或灌溉，如果水源已被严重污染，就根本不能使用。类似地，当我们将设备插入电源插座时，我们希望设备能够以合适的电压接收稳定的电力供应，这样我们的设备才能“正常工作”。同样的，烹饪煤气或其他任何我们认为理所当然的公用事业。我们没有人测试我们的公用设施;我们相信他们的质量。那么，为什么我们不能将我们的系统和设备连接到“软件管道”上，并相信我们的软件会不断地、安全、可靠和自动地更新呢?这是DevOps必须解决的下一个重大挑战。

最后一英里

虽然还有一段路要走，但我们已经比大多数人和公司想象的更接近液态软件和持续更新。在很多情况下，软件更新已经是自动的了。以移动设备为例。我们大多数人都在手机配置中设置了一个复选框，允许自动更新固件。更新就会发生，甚至可以等到我们使用Wi - Fi网络，这样就不会给我们的数据计划带来负担。同样，当我们下载一个应用程序时，我们允许供应商通过相应的应用程序商店自动向我们发送更新。但即使是我们这些不允许自动更新的人，在听到提示时也会不假思索地点击“我接受”。我们不会费心阅读任何我们遇到的EULA，即使我们读了它，我们也不太可能理解它的法律术语。在一天结束的时候，我们只是想要最新的软件，而不必去想它。

这是我们正在向企业软件发展的操作模式，但要使其广泛应用，仍有一些挑战需要克服。

信任与安全

当我们打开水龙头或接通电源时，我们信任我们的公用事业提供商。这种信任是基于过去的经验，以及监管机构正在监控我们每天使用的相对较少的公用事业提供商，并确保没有人会对它们进行篡改。企业软件组织可能由许多不同的提供者“培养”。安全机制必须到位，以验证每个提供者的身份，并确认不断更新系统的软件流没有被篡改。

软件质量

在企业对其生产环境部署定期更新之前，它将运行一系列测试，以确保没有损坏。然而，生产漏洞和系统中断每年仍使企业损失数十亿美元。为了让企业相信持续更新是稳健的，不会破坏他们的生产系统，液态软件的质量必须比我们今天得到的更新要好得多。这给供应商带来了沉重的负担，他们必须以非常高的信心提供软件更新。

Versionless软件

正如前面所讨论的，软件正日益变得无版本化。最终用户(当然是那些允许自动持续更新的用户)将无法通过版本号来识别他们正在运行的软件。这也意味着，如果在更新中发现了一些灾难性的错误，则无法将其回滚。如果客户联系供应商的帮助台报告问题，甚至只是为了获得某个功能的帮助，必须有一种方法让支持人员准确地识别客户正在运行的是什么。

透明度和协调

由于软件将变得无版本，因此必须有一种方法来协调当前运行的软件与更新它的新软件。安装流经管道的最新更新的自动化机制将需要一种方法来确定更新是兼容的和所需的。

减少释放周期

软件供应商仍在努力缩短他们的发布周期。还有许多障碍需要克服，比如工具的可用性、DevOps实践的采用速度、代码大小、实现完全自动化的管道等等。一些公司正在取得成功。2011年，亚马逊公开宣布D表示每11.6秒就会将代码部署到生产系统。到2014年底，亚马逊开始部署每一秒(尽管是针对自己的系统)。所以，虽然不是每家公司都是亚马逊，但他们的案例表明，这是可能的。

结论

软件开发组织继续以不断增长的速度和不断减少的周期发布软件。如今，企业软件面临的挑战是拥抱这一不可阻挡的趋势，并将发布周期降至零，以实现对所有使用软件的东西的可控、安全、持续更新，从计算系统到智能手机和平板电脑，从消费电子产品到物联网中的简单连接设备。一旦实现了这一点，软件将是流动的，从开发环境源源不断地流向分发平台，以执行自动更新。为了达到这一目标，将发布周期缩短到仅仅几秒钟(在某些情况下)的自动化必须进一步扩展，直到它在每个开发组织的软件开发的所有阶段中普遍存在。自动化系统中固有的安全风险将通过标准机制得到缓解，这些机制对软件管道的生产端到消费端进行身份验证，并验证流经管道的软件没有经过认证
篡改。整个更新过程必须通过详尽的元数据进行协调，元数据必须清楚地描述软件，并提供软件消费者需要的透明度，以便了解在他们的系统上安装了什么。最终，通过使用标准的安全系统和元数据，持续自动更新的液态软件的出现只是时间问题。