如何快速构建和交付云不可知产品

对象和图形数据库提供商Objectivity公司两年前为一个客户构建一个新的数字生态系统。该客户虽然占有很大的市场份额，但并没有技术创新或数字悟性。为了解决这个问题，他们提出了构建一个管理资产组合的软件平台的计划。

这个客户的优势在于更加接近数字资产，可以很容易地在数字生态系统中保持最新状态，允许开发更高级的最终用户功能。此外，这个解决方案还应与第三方系统和物联网传感器集成，以处理并向用户提供更多数据。从业务角度来看，所有这些都是“数据是新黄金”的完美理由，然而其时间和预算都是有限的。

在与这个客户进行探讨之后，Objectivity公司在3个月之后交付了最小可行性产品 (MVP)。在此期间，Objectivity公司组建了一个团队，了解业务领域，创建产品愿景，定义架构，并及时交付有效的最小可行性产品 (MVP)以进行商业化展示。

由于Objectivity公司需要在短时间内需要做这么多事情，因此必须设定正确的优先级，并就可接受的限制达成一致。其结果不只是提供一个原型。Objectivity公司的预期是，如果潜在客户在其进行商业化演示之后希望购买这种产品，应该能够在更短的时间内推出该产品。而且要使该项目更具挑战性，该产品必须与云计算无关，易于扩展，并且能够处理多租户。对于技术人员来说，这提出了一个重要的问题：为了实现这一目标必须做出什么样的技术权衡?

技术考虑

在软件方面，需要以某种方式设计解决方案，无需太多麻烦即可更改其某些组件。有时客户会使用这些选项(例如当更改电子商务的支付服务提供商时)，有时则不会。很多人也许记得过去的美好时光，因为那时都在为数据库引擎的更改做好准备，但在后来却很少更改。

怀疑论者可能会想 “供应商锁定风险到底有多大?”，一些人可能还记得谷歌公司在2018年提高了Maps API 14x的价格(在某些情况下)。这证明这种威胁是真实存在的。

那么，这如何适用于云不可知论呢?是否可以简化云的独立性?有人说，“云不可知论架构是一个误解”，或者说，“如果人们相信云计算(及其速度)，就不能相信不可知论”。下图显示了可用选项的范围：