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

  • 作者:zccc
  • 来源:网络
  • 2020-05-09 13:17:47

案例研究:如何快速构建和交付云不可知产品 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后,可能会发现不支持某些排队功能,并且在这个阶段,客户将不得不在代码中实现它们,这引入了不必要的复杂性。为避免这些挑战,首先要坚持使用不可知的队列实现,而不是为了快速交付而选择已经知道的内容。

  • 相关专题

免责声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,也不承认相关法律责任。如果您发现本社区中有涉嫌抄袭的内容,请发送邮件至:operations@xinnet.com进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。

相关文章

免费咨询获取折扣