案例研究：如何快速构建和交付云不可知产品

案例研究：如何快速构建和交付云不可知产品

• 来源:网络
• 更新日期:2020-05-09

摘要： 案例研究：如何快速构建和交付云不可知产品 p#qiye a:link,p#qiye a:visited{text-decoration:none;} .text img {max-width:630p

案例研究：如何快速构建和交付云不可知产品 对象和图形数据库提供商Objectivity公司两年前为一个客户构建一个新的数字生态系统。该客户虽然占有很大的市场份额，但并没有技术创新或数字悟性。为了解决这个问题，他们提出了构建一个管理资产组合的软件平台的计划。
这个客户的优势在于更加接近数字资产，可以很容易地在数字生态系统中保持最新状态，允许开发更高级的最终用户功能。此外，这个解决方案还应与第三方系统和物联网传感器集成，以处理并向用户提供更多数据。从业务角度来看，所有这些都是“数据是新黄金”的完美理由，然而其时间和预算都是有限的。
在与这个客户进行探讨之后，Objectivity公司在3个月之后交付了最小可行性产品 (MVP)。在此期间，Objectivity公司组建了一个团队，了解业务领域，创建产品愿景，定义架构，并及时交付有效的最小可行性产品 (MVP)以进行商业化展示。
由于Objectivity公司需要在短时间内需要做这么多事情，因此必须设定正确的优先级，并就可接受的限制达成一致。其结果不只是提供一个原型。Objectivity公司的预期是，如果潜在客户在其进行商业化演示之后希望购买这种产品，应该能够在更短的时间内推出该产品。而且要使该项目更具挑战性，该产品必须与云计算无关，易于扩展，并且能够处理多租户。对于技术人员来说，这提出了一个重要的问题：为了实现这一目标必须做出什么样的技术权衡?
技术考虑
在软件方面，需要以某种方式设计解决方案，无需太多麻烦即可更改其某些组件。有时客户会使用这些选项(例如当更改电子商务的支付服务提供商时)，有时则不会。很多人也许记得过去的美好时光，因为那时都在为数据库引擎的更改做好准备，但在后来却很少更改。
怀疑论者可能会想 “供应商锁定风险到底有多大?”，一些人可能还记得谷歌公司在2018年提高了Maps API 14x的价格(在某些情况下)。这证明这种威胁是真实存在的。
那么，这如何适用于云不可知论呢?是否可以简化云的独立性?有人说，“云不可知论架构是一个误解”，或者说，“如果人们相信云计算(及其速度)，就不能相信不可知论”。下图显示了可用选项的范围：

在这种情况下，云原生意味着人们可以利用给定云计算提供商的优势(即更好的性能、更好的可扩展性或更低的成本)。
总体而言，企业对不可知论架构的前期投资越多，切换云计算服务所花费的成本就越少。但是，与此同时，更复杂和不可知论的设计将降低生产率，并减缓交付过程。架构师面临着寻找一个令人满意的最佳解决方案的挑战，该解决方案既要遵循不可知论，又要遵守商定的时间和预算范围。那么如何做到这一点?例如，可以考虑AWS公司的企业战略分析师Mark Schwartz建议的转换成本。他建议企业考虑：
(1)离开云计算提供商的成本;
(2)发生上述情况的可能性;
(3)减轻云平台切换风险的成本。
此外，应该考虑解决方案的多个方面，例如：
•部署方法;
•托管模式;
•存储;
•编程语言。
故事还在继续
云不可知论的解决方案可能是福也可能是祸——它可以让企业为未来的成功做好准备，也可能延迟交付。因此，以下方面在资产管理方案中很重要：
•切换云平台的成本。企业可以在微软Azure云平台和IBM云平台上运行一个解决方案，并且无论哪种方式，即使不采用某种形式的云计算提供商退出策略，也都是合理的。
•中小型前期投资。客户希望避免进行大量的前期技术投资，并且需要了解，在定义新产品时，必须留出一些空间进行功能试验。
•尽管不可能，但企业必须在内部部署数据中心运行做好准备。当时，假设新产品的潜在企业客户可能会对云平台的安装设置这样的限制。
评估应用程序体系结构及其变体的一种方法是使用适应性功能。这一概念借鉴了进化计算的思想，用于计算给定设计与实现给定项目的一组重要目标之间的距离。
因此，假设在方案中：
架构适应度=生产力-前期投资-转换成本+内部支持
考虑到这一点，考虑采用以下选项：

解决方案
为此选择一种混合方法，因为它满足了所有需求。另外，当涉及到新项目中的容器化时，当企业尝试避免供应商锁定时，这似乎是一项轻而易举的事情。大多数解决方案是在.NET Core中实现的，作为一组运行在托管的Kubernetes集群中的服务和工作程序。为了不浪费时间配置持久存储，使用托管PostgreSQL作为所有组件的通用数据存储。Postgres是一个开源数据库，在多个云平台中作为托管服务提供，另外它还支持JSON文档，这是平台的另一个重要方面。
关于物联网集成，选择了云原生实施(例如Azure 物联网中心)。除了采用更具扩展性的方法外，它的实施速度也要快得多。而且如果需要，可以很容易地将其重写以在另一个云平台上工作。容器托管的物联网中心的研究结果表明，没有任何一种解决方案符合期望，尤其是在支持与传感器的双向通信方面。为了进一步降低切换成本，为物联网事件定义了规范的消息格式，以便消息转换发生在Kubernetes集群之外(例如在Azure功能中)，而其余所有处理都发生在集群内部。

最终结果
Objectivity公司成功地按时交付了可在Azure云平台上运行的解决方案，用于为客户提供的商业化展示。数据存储的权衡通过了时间的考验。Objectivity公司在Azure云平台和IBM云平台上进行了一些产品安装，所有功能都正常。Kubernetes也运作良好。但是需要记住，提供程序之间存在细微差异。例如，Ingress控制器会自动安装在IBM云平台上，而使用Azure云平台则必须自己执行此操作。此外，Kubernetes对于每个云计算提供商都具有不同的存储类别。
在展示几个月后，Objectivity公司还使用IoT Watson开发了第二个物联网实例，这证明了云原生方法是一个很好的权衡方案。但是，必须意识到各种排队实现之间的区别。使用Azure Service Bus交付新功能确实非常容易，尤其是如果企业具有.NET背景。但是，切换到RabbitMq后，可能会发现不支持某些排队功能，并且在这个阶段，客户将不得不在代码中实现它们，这引入了不必要的复杂性。为避免这些挑战，首先要坚持使用不可知的队列实现，而不是为了快速交付而选择已经知道的内容。