汽车制造网站建设,WordPress如何屏蔽国内用户,电脑搭建网站,虚拟网站免费注册云原生计算可以将行业领域驱动的设计、GitOps和其他现代软件最佳实践汇总起来#xff0c;如果企业实施得当#xff0c;可以减少技术债务。
云原生计算是企业IT的一种新范式#xff0c;它涉及现代技术的方方面面#xff0c;从应用程序开发到软件架构#xff0c;再到保持一…云原生计算可以将行业领域驱动的设计、GitOps和其他现代软件最佳实践汇总起来如果企业实施得当可以减少技术债务。
云原生计算是企业IT的一种新范式它涉及现代技术的方方面面从应用程序开发到软件架构再到保持一切运转的底层基础设施。 云原生为企业提供了清理技术债务的机会。例如通过Kubernetes这样的“扫帚”扫除现有技术的一些积满尘土的角落。因此假设云原生最终会消除多年来累积的技术债务是合乎逻辑的。
这也许合乎逻辑但并不现实。众所周知技术债务将长期存在。此外对于任何一位首席信息官来说宁愿将IT预算花在新技术和新事物上也不愿将其浪费在清理前任留下的烂摊子上。
然而人们也有理由对云原生抱有希望。虽然云原生不是一把神奇的“扫帚”但其核心实践确实可以帮助企业减少技术债务并提供新的软件功能而不会产生更多的债务至少不会像以往那样产生更多的债务。
让企业清除技术债务以便永远不会产生新债务当然是难题的一部分但更直接的问题是如何偿还现有的遗留技术债务。
多年来便利的快捷方式、笨拙的编码以及基础设施中各种各样的接口已经形成了一团乱麻。而对于这个难以解决的问题可能需要采用“快刀斩乱麻”的措施。
云原生计算就是这样的一把快刀基于领域驱动设计的架构重构。领域驱动设计要求将复杂的企业软件挑战分解为单独的业务领域每个领域都有一个“限界上下文”。
限界上下文可以根据业务需求限制上下文来解决诸如“客户”或“发票”之类的业务。例如大型企业的不同部门可能对客户有不同(可能有所重叠)的概念。每一个都代表一个单独的限界上下文。
早期对微服务架构的探索导致了互联微服务的激增其复杂性限制了其可扩展性并且很快显现出来。而通过限界上下文组织它们是管理这种复杂性以及大规模交付基于微服务的解决方案的关键。
因此领域驱动设计已经成为云原生计算的一部分此外它告诉人们必须如何按照这种新范式来实现遗留资产的现代化。
解决具有高技术债务的遗留软件挑战的第一步是应用架构重构从而将遗留架构转换为具有限界上下文的模块化元素。换句话说企业必须遵循业务驱动的限界上下文引入模块化以便引导减少技术债务的路径。
而魔鬼在细节中。根据企业面临的业务需求和遗留挑战可以通过以下几种方式来利用这种架构重构
可能会发现限界上下文中的现有代码根本不符合当今的要求。在这种情况下可以将该代码重写为微服务。 遗留业务逻辑仍然具有价值然后将其迁移到微服务。 可以将遗留模块作为API公开因为它们已经具有有用的API或者因为更新了遗留代码以通过API公开它。 可以使用机器人流程自动化(RPA)程序编写与旧模块交互的脚本。 需要注意的是由于之前已将遗留软件重新组织和模块化为限界上下文因此上述四种方法中的每一种都比其他方法更加简单。
此外如果有必要的话未来的重构也会更加直接因为采用了“分而治之”的方法来划分技术债务。例如随着时间的推移企业还清四笔较小的技术债务比一笔大的技术债务更加轻松。
这种方法也是减少机器人流程自动化(RPA)脆弱性的最佳方法之一。如果没有限界上下文驱动的架构重构那么应用程序环境中的任何地方发生任何变化此类机器人程序就会崩溃。通过适当的划分此类故障将更易于管理且更易于修复。
防止新的技术债务
防止新的技术债务就像要求保持房间整洁一样虽然也许会保持一段时间但到后来将会变得一团糟。
需要的是更多的结构对吗?至少在云原生的情况下这种结构确实有帮助。
云原生计算提供了一系列广泛的最佳实践描述了如何最好地构建软件、配置基础设施、创建和部署应用程序以及管理生产中的一切。
当然如果遵循所有这些建议就不太可能背负新的技术债务或者至少不会那么快地出现技术债务。
“基础设施即代码”(IaC)原则就是一个关键示例。IaC原则指出工作人员不应在生产中弄乱服务器。 IaC原则当然可以限制生产中的额外技术债务因为它提供了一种解决生产问题的主动方法。那么只有一个问题IaC做得还不够。
IaC的问题在于必须编写各种程序。然后必须像任何其他程序一样对这些程序进行测试、管理和版本控制——这意味着技术债务可能会像任何其他软件一样蔓延。
幸运的是云原生计算已经超越了IaC其中每一步都比之前的一步有所改进。
第一步通过声明性配置来表示基础设施它指定应该如何配置基础设施而不指定如何实现此类配置。 与IaC相比声明式方法减少了技术债务因为没有太多的空间来使用快捷方式但这些表示(通常出现在YAML文件或其他基于JSON的格式中)仍然非常像代码尤其是对于复杂的动态基础设施配置。
第二步GitOps。GitOps为软件发布和管理带来了以Git为中心的实践和流程。 GitOps在许多方面补充了基础设施配置的声明式方法因为它采用声明式方法进行软件部署。GitOps通过为其流程提供更多结构而更进一步而结构越多技术债务蔓延的机会就越少。
第三步是当前最先进的技术基于意图的计算。
基于意图的计算包含三个部分
以技术策略的形式对相关软件(基础设施、应用程序代码等)的声明性表示。 这种技术策略的抽象如表示底层配置的业务意图的业务策略。 确保底层软件符合这一业务意图的一种机制从而在策略应用中消除策略漂移。 换句话说基于意图的计算采用声明式配置方法和GitOps并添加额外的结构从本质上确保整个云原生环境随着时间的推移符合业务意图。这样的合规性才是一把斩断技术债务这团乱麻的最好的快刀。
