35、云原生转型常见挑战解析

云原生转型常见挑战解析

1. 云原生转型挑战概述

在云原生转型过程中,常常会遇到一些典型的挑战和场景。这些情况在迁移计划停滞或出现问题时较为常见,且在不同类型和规模的企业中频繁出现。虽然每个组织的需求和情况独特,转型路径细节各异,但这些场景代表了更广泛的“大局”概况,而非细致入微的分析。

每个场景都配有云原生成熟度矩阵图示例,展示该情况下的典型结果。若你已对自身状态进行评估和绘图,可将结果与这些场景对比。如果你处于转型初期,这些场景能让你明白“规划云原生转型时不应做什么”。

在探讨每个问题后,会给出一套可作为设计解决方案一部分的模式。需注意,这些模式仅针对特定阶段的特定问题,它们构成整体设计的一部分,整体设计则全面涵盖整个转型过程。

2. 过早的“提升与转移”策略
  • 背景与原因 :采用“提升与转移”策略的企业大多采用传统瀑布式软件开发方法,虽可能采用了一些敏捷流程,但大型企业根深蒂固的层级和官僚做事方式仍占主导。这类企业在确定业务战略目标后,愿意投入资源进行云原生转型,但错误地认为只需将现有系统和流程迁移到云端即可。公司内部对云原生的理解和经验不足,无法做出更明智的决策。
    • 工程师推动情况 :公司工程师参加会议后,急于尝试云原生技术。他们在大型云服务提供商处开设账户,尝试设置容器并构建小型实验应用,进展顺利后便自信能进行全面转型,进而寻求管理层批准进行全面云迁移。
    • 高层推动情况 :CEO 和董事会决定公司向云原生转型,将其作为大型但并非特别困难的技术升级交给中层管理人员。他们错误地认为投入资金就能从大型云供应商处购买完整解决方案。
  • 问题本质 :两种情况都基于一个看似合理但根本错误的假设,即认为当前系统运行良好,就能在云端原样重建。迁移计划本质上是将旧系统“提升”并基本完整地“转移”到云端,而组织和文化方面,如规划、设计、开发流程等保持不变。
  • 不良后果 :经过数月努力和大量资金投入后,公司会发现虽然拥有了 Kubernetes 和云基础设施,但系统无法正常运行,或者运行速度和效果与之前相比并无提升。运营成本上升,几乎无法获得收益,浪费了时间和金钱,还错失了真正改变组织和流程的机会。
  • 更好的方法 :应专注于将各个方面向云原生状态推进。对大多数组织而言,可能意味着从架构和流程入手,同时逐步转变文化。
  • 实用模式解决方案
    1. 对当前状态进行诚实而全面的评估。
    2. 以愿景为先(若未获得 CEO/董事会支持,先进行商业案例和高管承诺模式)。
    3. 组建核心团队。通过这些模式,可获得清晰的愿景、高层次的架构方向和具备实施能力的团队。

以下是“提升与转移”策略的相关情况表格:
| 推动方 | 决策原因 | 迁移计划 | 后果 |
| ---- | ---- | ---- | ---- |
| 工程师 | 参加会议后尝试新技术,实验顺利 | 将旧系统迁移到云端,拆分单体应用 | 系统运行不佳,成本上升,错失转型机会 |
| 高层 | 决定公司转型,认为可购买解决方案 | 原样重建系统到云端 | 同上 |

3. 将云原生简单视为敏捷的延伸
  • 背景与原因 :从瀑布式软件开发向敏捷开发转变是重大范式转变,多数公司明白要成为真正的敏捷组织,需改变软件开发和交付的诸多方面。但在从敏捷向云原生实践转变时,他们未能认识到这是另一次真正的范式转变,而是认为云原生只是“敏捷的新方式”。
  • 问题表现 :云原生转型被视为一系列技术相关任务,添加到现有开发待办事项中。组织在构建云原生平台方面取得一定进展,但仍无法在其上交付软件。最坏情况下,几乎一切都无法正常工作;最好情况下,系统基本运行,但无法实现产品速度和数据驱动设计的价值,新系统甚至不如旧系统。
  • 不良后果 :云原生工具如 Kubernetes、CI/CD 和微服务被简单视为敏捷方法的正常延伸,而实际上并非如此。虽然能更快构建小模块,但如果仍每六个月同时发布紧密耦合的单体应用,就完全偏离了云原生的要点。敏捷流程和文化在利用云计算优势方面不够快速、响应和灵活。
  • 更好的方法 :对于习惯紧密耦合开发方式的组织来说,这是重大转变。先进行小规模实验,有助于来自敏捷背景的团队理解脱离层级驱动的单体应用后,思考和工作方式的不同,进而逐步转变为协作和分布式的云原生工作方式。
  • 实用模式解决方案
    1. 以愿景为先。
    2. 组建核心团队和平台团队。
    3. 从小规模实验开始逐步转型,实验应涵盖云原生的主要元素(探索性实验、概念验证、最小可行产品)。要确保平台团队的文化自然适应新平台。

以下是该场景的 mermaid 流程图:

graph LR
    A[开始] --> B[以愿景为先]
    B --> C[组建核心团队和平台团队]
    C --> D[进行小规模实验]
    D --> E[确保团队文化适应新平台]
    E --> F[逐步转型]
4. 不平衡方法导致的“尖峰”式云原生转型
  • 背景与原因 :这是最常见的场景,由三种因素之一导致。在成熟度矩阵的任何阶段都可能出现不平衡的方法。当迁移出现问题时,常发现组织仅在微服务、编排/Kubernetes 或 DevOps 三个领域中的一个取得显著进展,而其他对云原生转型至关重要的相关领域未同步推进。
  • 问题表现 :在成熟度矩阵图中,连接各轴的线会出现一个尖锐的“尖峰”。具体“尖峰”区域可能不同,但最终结果相同,即迁移会陷入困境,很可能最终失败。
    • 高层推动情况 :CEO 和董事会决定公司向云原生转型,团队转向 DevOps,但管理层并不真正理解其含义,只是简单地将运维人员加入开发团队,除座位安排外,流程、交付和产品/服务设计实践基本不变,且没有未来战略,也不清楚云原生转型的含义和实现方法。
    • 开发者推动情况 :开发者推动云原生转型时,会迅速推进微服务架构,但公司其他部分保持不变。
    • 运维团队推动情况 :运维团队推动时,会强调需要 Kubernetes,导致供应/编排轴大幅领先,而公司其他部分仍按原有方式运作。
  • 不良后果 :即使孤立的举措进展顺利,也是有问题的。例如,开发团队在未与其他重要利益相关者沟通的情况下尝试微服务,虽自身能理解和实施,但因缺乏运维团队支持,微服务无处部署,要么项目停滞,要么开发人员在未与运维沟通的情况下配置不佳的集群,导致无人能维护。此外,若不进行重组,康威定律表明微服务的划分方式将不可避免地反映公司的组织结构。
  • 实用模式解决方案 :目前虽未提及该场景的具体解决方案,但可推测需要全面评估和协调各领域的发展,确保各方面同步推进,避免出现“尖峰”情况。

以下是不同推动方导致不平衡转型的情况表格:
| 推动方 | 推动方向 | 问题表现 |
| ---- | ---- | ---- |
| 高层 | DevOps | 仅调整人员安排,无实质改变,无未来战略 |
| 开发者 | 微服务 | 其他支持领域不变,微服务部署困难 |
| 运维团队 | Kubernetes | 供应/编排领先,公司其他部分照旧 |

通过对这些常见挑战和场景的分析,我们能更好地理解云原生转型过程中可能遇到的问题,并采取相应的措施避免或解决这些问题,从而更顺利地实现云原生转型目标。

5. 各挑战场景对比分析

为了更清晰地对比上述三种云原生转型常见挑战场景,我们可以使用表格进行总结:
| 挑战场景 | 背景原因 | 问题表现 | 不良后果 | 更好方法 | 实用模式解决方案 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| 过早的“提升与转移”策略 | 企业采用瀑布式或部分敏捷开发,对云原生理解不足,认为迁移现有系统到云端即可 | 迁移旧系统到云端,组织和文化方面不变 | 系统运行不佳,成本上升,错失转型机会 | 专注推进各方面向云原生状态发展,从架构和流程入手,逐步转变文化 | 评估当前状态,以愿景为先,组建核心团队 |
| 将云原生简单视为敏捷的延伸 | 企业完成瀑布到敏捷转变,但未认识到云原生是新范式转变,将其视为敏捷的新方式 | 云原生转型作为技术任务添加到开发待办事项,组织构建平台有进展但无法交付软件 | 云原生工具未发挥作用,未实现产品速度和数据驱动设计价值,新系统不如旧系统 | 先进行小规模实验,帮助团队理解云原生工作方式,转变为协作和分布式工作 | 以愿景为先,组建核心团队和平台团队,进行小规模实验并确保团队文化适应新平台 |
| 不平衡方法导致的“尖峰”式云原生转型 | 企业在微服务、编排/Kubernetes 或 DevOps 某一领域单独推进,其他相关领域未同步发展 | 成熟度矩阵图出现“尖峰”,迁移陷入困境 | 孤立举措即便顺利也会因缺乏支持而出现部署和维护问题,微服务划分反映公司组织结构 | 全面评估和协调各领域发展,确保同步推进 | 目前未提及,推测需全面评估和协调 |

6. 应对云原生转型挑战的通用原则

在面对云原生转型的各种挑战时,有一些通用原则可以遵循:
1. 全面评估 :在进行任何云迁移之前,对企业的当前状态进行全面、诚实的评估是基础。这包括技术能力、组织文化、业务流程等多个方面。通过评估,明确企业的优势和劣势,为后续的转型规划提供依据。
2. 愿景驱动 :以清晰的愿景为导向,确保整个转型过程有明确的目标和方向。愿景应该得到企业高层的支持和认可,为转型提供战略指导。
3. 团队协作 :组建跨职能的团队,包括开发、运维、业务等各个领域的人员。团队成员之间要密切协作,打破部门壁垒,共同推动转型的顺利进行。
4. 渐进式转型 :避免激进的一次性转型,采用渐进式的方法逐步推进。可以先从一些小规模的实验项目开始,积累经验和信心,然后再逐步扩大范围。
5. 文化变革 :认识到云原生转型不仅仅是技术变革,更是组织文化的变革。要注重培养团队的创新精神、协作意识和快速响应能力,营造适应云原生的文化氛围。

7. 云原生转型的未来展望

随着技术的不断发展和企业对数字化转型需求的增加,云原生转型将变得越来越重要。未来,云原生技术将更加成熟和完善,为企业提供更强大的支持。同时,企业在云原生转型过程中也将面临更多的挑战和机遇。

为了更好地应对未来的挑战,企业需要不断学习和创新,关注云原生技术的最新发展趋势,及时调整转型策略。同时,加强与云服务提供商、技术合作伙伴的合作,共同推动云原生技术的应用和发展。

以下是云原生转型未来发展的 mermaid 流程图:

graph LR
    A[当前云原生转型] --> B[技术不断发展]
    B --> C[云原生技术成熟完善]
    C --> D[企业面临更多挑战和机遇]
    D --> E[企业学习创新,调整策略]
    E --> F[加强合作,推动应用发展]
    F --> G[未来云原生转型成功]
8. 总结

云原生转型是企业实现数字化转型的重要途径,但在转型过程中会遇到各种挑战。本文详细分析了过早的“提升与转移”策略、将云原生简单视为敏捷的延伸、不平衡方法导致的“尖峰”式云原生转型三种常见挑战场景,包括其背景原因、问题表现、不良后果以及相应的解决方法和实用模式解决方案。

通过对比分析和总结通用原则,我们可以更好地理解云原生转型的复杂性和重要性。在未来的转型过程中,企业应遵循全面评估、愿景驱动、团队协作、渐进式转型和文化变革等原则,不断适应技术发展和市场变化,成功实现云原生转型,提升企业的竞争力和创新能力。

总之,云原生转型虽然充满挑战,但只要我们正确认识问题,采取有效的解决措施,就能够抓住机遇,实现企业的可持续发展。

随着信息技术在管理上越来越深入而广泛的应用,作为学校以及一些培训机构,都在用信息化战术来部署线上学习以及线上考试,可以线下的考试有机的结合在一起,实现基于SSM的小码创客教育教学资源库的设计实现在技术上已成熟。本文介绍了基于SSM的小码创客教育教学资源库的设计实现的开发全过程。通过分析企业对于基于SSM的小码创客教育教学资源库的设计实现的需求,创建了一个计算机管理基于SSM的小码创客教育教学资源库的设计实现的方案。文章介绍了基于SSM的小码创客教育教学资源库的设计实现的系统分析部分,包括可行性分析等,系统设计部分主要介绍了系统功能设计和数据库设计。 本基于SSM的小码创客教育教学资源库的设计实现有管理员,校长,教师,学员四个角色。管理员可以管理校长,教师,学员等基本信息,校长角色除了校长管理之外,其他管理员可以操作的校长角色都可以操作。教师可以发布论坛,课件,视频,作业,学员可以查看和下载所有发布的信息,还可以上传作业。因而具有一定的实用性。 本站是一个B/S模式系统,采用Java的SSM框架作为开发技术,MYSQL数据库设计开发,充分保证系统的稳定性。系统具有界面清晰、操作简单,功能齐全的特点,使得基于SSM的小码创客教育教学资源库的设计实现管理工作系统化、规范化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值