微服务和DevOps如何帮助 CIOs 实现业务与IT对齐

了解自动化、DevOps 和 microservices 如何一起使您的业务部门和 IT 人员能够更好地协作并协同工作。

这一阶段是为企业达到新的生产力水平和数字演进而设定的。小而自主能够赢得过大而集中，自动化、DevOps 和 microservices一起以正确的方式使业务部门和 IT 团队再次协同工作。

进入比竞争更快的数字进化

对那些成功的公司来说, 利益是很重要的--他们的竞争将变得更加艰难。好的一点是, 它可以是一个简单的过渡, 所有各方都将了解业务目标以及架构。

但它也可能出错。它需要在公司内部的各种功能之间进行协调努力, 它需要一个新的架构功能视图, 它需要 (商业) DevOps 和良好的自动化, 而所有这一切都必须以业务与IT对齐作为最终驱动。

当四个领域一起完成时, 它以正确的方式释放了组织的全部潜力:

• 当业务线拥有自己的 (商业) DevOps 团队和 (商业) Microservices 时, 他们可以快速而自主地发展, 控制投资而不是价值, 并且容易创新。

• 当 (商业) DevOps 团队与业务组织保持一致时, 它们会随着时间的推移而稳定下来, 它们会不断地帮助创新, 并将自己的流程数字化, 以提高生产率和稳定性。

• 当 (商业) Microservices为功能导向的组件时, 每个实现一个业务功能, 它允许最大的可能性, 新的功能只影响一个单一的组件。

• 通过云、高生产率 (HPA) 平台和 CI/CD 业务流程实现自动化, 允许小型、功能化的 DevOps 团队轻松构建和维护良好的面向业务的 Microservices。

业务和 (商业) DevOps 之间的长期关系允许 DevOps 团队了解他们所支持的业务, 释放技术专长满足商业敏锐和新领域的辉煌区域。该是 CIOs、架构师、开发者和业务团队一起采取下一步行动的时候了!

即使所有四领域看起来都很明显, 放弃历史并非易事, 而将四领域一起做会使组织、团队、管理、架构和发展变得更薄。许多组织只执行这些措施的一部分, 或者以不连贯的方式进行。

例如: N 层体系结构的DevOps, monoliths 或COTS不会使团队变得自主。无 DevOps 团队和功能 Microservices 的 CI/CD 自动化是开发人员的练习, 虽然更快地生成代码, 但缺少业务对齐。

Microservices 远不止架构

为了使 DevOps 团队能够使用业务处理, 我们需要构建功能 microservices, 以使业务工作方式成为默认选项。这些 microservices 有 "装运"、"库存"、"退货" 和 "报价" 等业务名称。数据在体系结构中流动, 就好像 microservices 是进程中的参与者一样。

业务干系人、开发人员和架构师将在体系结构上共同工作。业务目标、交付和可操作性与常规架构关注一样重要。

结果应为：

• 面向商业的人可以理解体系结构。

• 使新功能仅触及一个 microservice 的可能性最大化。

• 集成量很低, 需要运行的服务调用很少。

• 商业创新的变化更简单。

业务部门、DevOps 团队和 microservices 的自主权非常重要, 因此, 根据自己的需要构建新的功能通常是有意义的, 而不是重新使用旧组件或购买功能。microservices 的规模将根据什么是对业务有利, 只要它适合于一个 DevOps 团队。

企业级 microservice 体系结构将组织为一个 "系统" 的层次结构, 每个构建为一个到十 microservices, 所有这些都类似于业务的运作方式。

monoliths、通用现成软件和 SOA 层的时代正在被一个类似业务的 microservices 体系结构所取代，DevOps 团队构建、部署、管理和改进合理规模的、面向业务的 microservices，可以独立地，或者成为更大的 "系统" 或 "应用程序" 的一部分。

对这种健康进化的最大威胁, 实际上是人们走得太远并觉得小的总是更好。极小、技术的专注于规模而非功能的microservices不会产生业务利益，而且架构不会与业务功能相一致。在这种情况下, 生产力效益将不会实现。而最坏的情况是依赖关系会增长, 使事情变得比现在更糟。

(商务)DevOps 打破最后的障碍

越来越多的组织正在引入 DevOps以创建规模较小的授权团队, 并打破开发和运营部门之间的边界。

从有冲突的目标的更大的部门起步, DevOps 相信自主、跨职能团队，其中成员们共享问题、 解决方案和工具, 不仅要构建良好的业务 microservices, 还要建立自己的自动回归测试和操作安全机制。

团队与所支持的业务线紧密相连, 它具有敏捷的心态,专门针对业务部门所需的 microservices 的特定需求数字化自己的 DevOps 流程，这不仅仅节省了资金, 使体系结构更加稳定, 而且使人们更加快乐和富有成效。

最终, 商界人士和 DevOps 团队共同解决问题。角色合并。业务线开始将 IT 投资视为一种利润损失的商业战略。DevOps 团队以一种有价值的方式进行创新，因为他们知道企业是如何运作的。

战略之所以奏效, 是因为它以所有权开始和结束。所有权使跨职能团队负起责任, 并将它们与业务目的相一致。

在使用云和自动化以保持 DevOps 团队规模小和 microservices 重要性时，完整的业务与IT 对齐离不开自主团队和组件。

关键点

对于 microservices 可以为您的组织做些什么, 值得积极关注。它远超架构而表现为一种心态。一些架构师可能不愿意因为历史原因而改变，或者他们害怕失去对自己领域决策的控制权。但这是DevOps, 它与业务协调相关，需要问题和解决方案共享并与一起作出决策。有了 DevOps, 人们就会参与不止一项任务, 因此可以与所有各方一起决定 microservices。

•IT 交付中的自动化会逐步提高生产率, 并改变我们如何看待我们所构建以及如何维护。

• (商业) Microservices和(商业) DevOps启用自主和较小的团队和组件。

• 业务与IT 对齐最后给业务提供IT的工具以快速前进。

Mendix 的本质是业务-IT 对齐

Mendix 提供了一个平台, 它从一开始就建立起来, 使业务和 IT 协同工作。它反映在平台、文化和社区中的任何地方：

• Mendix 使 microservices "跳出框", 因为从一键式部署中可以为数据、逻辑和 UX 提供一个统一的环境, 以满足任何业务目的。它确保 microservices 通过显式服务而不是跨服务数据库查询进行通信。

• 更高的生产率 (高达 10x) 和高水平的自动化意味着需要较少的技术技能 (功能性业务开发人员), 小型团队可以构建重要的 microservices。

• 这使 DevOps 更简单, 并促进了敏捷的心态, 其中业务很容易参与, 并实现了机箱外云和中央高生产率平台的充分优势。

• 治理、CI/CD、集装箱化和监控是平台的一部分, 自动测试和质量管理工具可作为外接组件使用。

Mendix 的五体系结构建议

• 拥抱云和自动化。

• 将体系结构与组织对齐。

• 平衡重用与自治。

• 建立明确的定位, 专为宗旨。

• 实施新的治理, 允许敏捷, 随时准备改变。

译者介绍：

贾文杰，基础架构、数据库、大数据、云相关项目管理和运维服务，云技术社区金牌翻译