Gregor Hohpe最近发表了一篇文章，提出了一种范式转变，以解决供应商对无服务器云应用程序的锁定问题。使用众所周知的模式设计解决方案可以将其功能特性与底层云实现分离，从而更容易避免锁定或转向多云。
尽管人们常说云平台服务产品在本质上是等同的，但它们之间的差异足以让重要用例的直接移植成为不可能。
因此，可移植性是设计系统时要牢记的一个有效问题，尤其是当它们用于多云部署时。然而，以可移植的方式思考并不总是直截了当的。
作者认为，一个重要的障碍是“心理锁定”。一方面，以往的经验可能会限制一个人的思维模式，使其难以采用不同的架构。另一方面，现代云平台让人很想根据服务产品来描述一个人的解决方案。这样做很难将解决方案转换到不同的平台上。
只考虑平台服务会失去应用程序的设计意图，并在精神上将您锁定。
服务映射表的级别太高，无法准确描述可移植性，因为具体的服务功能并不是一一对应的。此外，所使用的云服务集不一定表达解决方案的需求或设计者的意图。
软件工程领域的典型路线是在特定服务实现之上构建可移植层。作者指出，这种方法可以很快导致最低公分母效应。这种影响是不利的，因为它阻碍了在快速发展的云应用程序领域采用创新。
Hohpe 建议与其从实现级抽象的角度思考，不如从设计时抽象的角度思考。作为“技术中立的设计时词汇表”，设计模式提供了有用的抽象以在设计时应用。
将您的解决方案表达为设计模式可以简化将其移植到另一个平台的过程。
通过根据设计模式表达解决方案，架构师的意图和解决方案的需求都变得显而易见。
图片来源:“担心无服务器锁定?考虑模式!”
使用的任何设计模式，例如聚合器、发布-订阅通道、编排器，都可以使用每个云供应商特定的服务产品来实现。有时，可能需要组合这些产品以实现特定的设计模式，这并不是缺点。
服务组合然后成为实现细节而不是设计选择。
作者补充说，系统设计需要使用“形成单一词汇表的内聚语言”来表达。可以使用多种模式语言来形成这个词汇表，但必须清楚地了解它们所应用的系统方面。例如，可以使用企业集成模式设计数据流，但最好使用面向对象的模式来构建组件。
模式语言以服务中立语言表达开发人员的意图。
平台的进步也意味着模式改变所需的权衡。这种演变意味着，例如，无服务器云平台可能更喜欢使用与旧平台上偏好的模式不同的模式。新的模式也可能出现，从广泛使用中出现。
关于作者，瓦斯科维罗索，Vasco Veloso 从事软件开发和设计已有二十多年。从汇编，通过 C、C++ 和 Prolog，到 Java、Scala 和 Kotlin，在大型和小型计算机上......。
