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

即将开播:5月14日,Jenkins在K8S下的三种部署流程和实战演示

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

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

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

在与这个客户进行探讨之后,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功能中),而其余所有处理都发生在集群内部。

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

最终结果

相关推荐