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

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

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

[[325346]]

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

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

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

技术考虑

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

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

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


在这种情况下,云原生意味着人们可以利用给定云计算提供商的优势(即更好的性能、更好的可扩展性或更低的成本)。

总体而言,企业对不可知论架构的前期投资越多,切换云计算服务所花费的成本就越少。但是,与此同时,更复杂和不可知论的设计将降低生产率,并减缓交付过程。架构师面临着寻找一个令人满意的最佳解决方案的挑战,该解决方案既要遵循不可知论,又要遵守商定的时间和预算范围。那么如何做到这一点?例如,可以考虑AWS公司的企业战略分析师Mark Schwartz建议的转换成本。他建议企业考虑:

  • 离开云计算提供商的成本;
  • 发生上述情况的可能性;
  • 减轻云平台切换风险的成本。

此外,应该考虑解决方案的多个方面,例如:

  • 部署方法;
  • 托管模式;
  • 存储;
  • 编程语言。

故事还在继续

云不可知论的解决方案可能是福也可能是祸——它可以让企业为未来的成功做好准备,也可能延迟交付。因此,以下方面在资产管理方案中很重要:

  • 切换云平台的成本。企业可以在微软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后,可能会发现不支持某些排队功能,并且在这个阶段,客户将不得不在代码中实现它们,这引入了不必要的复杂性。为避免这些挑战,首先要坚持使用不可知的队列实现,而不是为了快速交付而选择已经知道的内容。

 

责任编辑:赵宁宁 来源: 企业网D1Net
相关推荐

2014-06-26 14:08:28

Azure云服务

2022-12-13 10:45:12

无服务器架构物联网工具

2021-04-20 12:53:34

Polkadot部署合约

2010-03-29 13:35:39

ibmdwRIA

2010-05-18 10:07:23

桌面PC云计算

2012-03-21 09:36:48

私有云IT即服务ITaaS

2012-12-26 09:32:59

应用交付AWS云优化

2019-09-18 11:17:53

云计算云安全

2017-11-07 06:28:11

2013-06-21 16:38:51

惠普世界之旅

2016-10-12 17:18:26

私有云持续交付华为

2022-09-06 11:10:47

IT主管金融服务企业

2015-07-22 17:40:05

应用交付 太一星晨

2020-05-21 10:14:46

云计算混合云

2017-03-01 14:30:48

存储云私有云公有云

2017-03-03 10:18:13

存储云APIGUI

2012-06-27 11:12:05

云计算案例

2013-05-13 14:16:43

2011-03-14 13:07:18

QMLQt

2023-08-24 08:49:27

点赞
收藏

51CTO技术栈公众号