Cloud-Native 元素卡: 打造 Cloud-Native 持续改善的生态系统

前言:

软件开发本身就是一个持续改善的过程;一个从无知到智慧的过程。

在软件开发的世界里,没有标准答案。

在软件开发的世界里,没有任何一个人能为软件开发制定所谓的 “统一标准”、“统一规范”; 例如: 没有任何一个人, 能规定微服务的架构只能这样设计, 不能那样设计。

在软件开发的世界里,我们真正需要的是 “持续改善”;有效、有智慧的持续改善。

本文:

  • CMMi 是期望团队能在达到 CMMi-2,CMMi-3 时,建立起软件开发流程的规范。并期望团队在达到 CMMi-4 时,能找出先前在 CMMi-2, CMMi-3 所建立的流程上的瓶颈、风险,而能在达到 CMMi-5 时,“持续改善” 软件开发的流程。
  • 敏捷开发期望团队能借由最直接的人与人之间的交互与最高效的自动化的工具,而能在最短的时间内反映出产品开发上的瓶颈、风险。

所以,不论是 CMMi 或著是敏捷开发,都是在指引着我们如何在软件开发的过程中,能做好 “持续改善”。

为何 CMMi, 敏捷要这么做?

因为,软件开发的过程,本身就是一个 “学习的过程”:

  • 学习着如何能更加贴近用户的想法、行为?
  • 学习着如何能对用户产生更多正面的影响?
  • 学习着如何能在更正确的时间,交付更有价值的产品?

既然软件开发是一个学习的过程,所以,什么样的流程,什么样的工程实践,什么样的自动化工具最适合团队,也同样是要经由一段 “学习的过程”;持续改善;才能有所结论的。

这道理大家都明白,但,为何总是做得似乎不大好?

不论是在 CMMi, 还是在敏捷开发,我们都还是习惯用 “标准答案” 去界定我们的软件开发做得好不好?做得对不对?而所谓的持续改善,也只是肤浅的将不符合标准答案的部分,“修改” 为符合标准答案。

真正的问题到底出在那?

除了软件开发在度量上缺乏 “持续改善” 的思维、作法、数据以外,另外的一个问题就是⋯

  • 我们缺乏一个可视化、轻量级的工具;可以使得我们在发现软件开发问题的同时,就能持续改善软件架构的决策、工程的实践、开发的框架、自动化的工具。

Cloud-Native 元素卡就是要借由轻量级、可视化的 “卡片” 来解决这个问题;使得团队永远可随时将不适用的软件架构决策卡片、工程实践卡片、开发框架卡片、自动化工具卡片给移出,给舍弃,同时也能随时加入适合的各类型卡片。

[图一: Cloud-Native 微服务板]

团队中的各不同角色; 产品经理、架构师、开发人员、测试人员; 在 “Cloud-Native微服务板 (请参考图一)” 前协作:

  • 在 Cloud-Native 微服务板上的 Cloud-Native 元素卡的指引下, 团队对价值特性与外部用户、产品的交互场景、功能达成共识; 请参考图二。
  • 在 Cloud-Native 微服务板上的 Cloud-Native 元素卡的指引下, 团队对微服务的粒度达成共识; 请参考图二。
  • 在 Cloud-Native 微服务板上的 Cloud-Native 元素卡的指引下, 团队对微服务的 Restful 接口、事件达成共识; 请参考图二。
[图二: Cloud-Native 元素卡]
  • 在Cloud-Native 微服务板上的 Cloud-Native 元素卡的指引下, 团队对微服务的软件架构方案、开发的框架达成共识; 请参考图三。
[图三: Cloud-Native 元素卡]
  • 开发人员便以 Restful, gRPC 开发著第一个版本的微服务, 并将微服务先部署到蓝线上。请参考图四。
[图四: 蓝线部署、绿线发布]

当第一个版本的微服务被部署到蓝线上后, 团队便想针对以下的问题进行 "持续改善":

  • 微服务间的高藕合
  • 不易处里异步事件流
  • 不易传送、合并有业务关连性的数据集

所以, 团队决定将 KAFKA 引入到第一个版本的微服务架构中, 并新增了 KAFKA Cloud-Native 元素卡; 以 “持续改善” 团队 Cloud-Native 微服务的软件架构的决策、工程的实践、开发的框架、自动化的工具。

[图五: 团队新增了 KAFKA Cloud-Native 元素卡]

结论:

Cloud-Native 元素卡使得团队中的各个不同的角色; 产品经理、架构师、开发人员、测试人员; 能在 Cloud-Native 微服务板前高效的协作, 大幅的缩减了团队在 Cloud-Native 微服务设计上所需花费的时间。而使得开发人员能更快速的将微服务部署到蓝线上, 进而使得团队能在更短的时间内, 就能发现已开发完成的微服务在粒度、软件架构决策、开发框架、自动化工具上所存在的风险或缺陷。

团队更可以从所发现到的风险或缺陷中, 设计新的 Cloud-Native 元素卡或淘汰不适宜的 Cloud-Native 元素卡; 以持续改善团队 Cloud-Native 微服务的软件架构的决策、工程的实践、开发的框架、自动化的工具。

软件开发的本质就是 “持续改善”;我们也正在逐步的打造一个 “软件开发持续改善的生态系统”。

附注:

  • Cloud-Native 元素卡包含:
    • Cloud-Native 微服务开发元素卡
    • Cloud-Native 微服务架构元素卡

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏用户3254834的专栏

干货丨小程序功能解读白皮书

上述新增能力,主要集中在小程序的功能、小程序的管理以及小程序的用户管理。小程序在不断优化用户体验的同时,也在不断为第三方介入提供更多的接口和便利。当然每次新能力...

11740
来自专栏DevOps时代的专栏

什么样的团队结构才能适应 DevOps 的蓬勃发展?

引言 组织中发起任何 DevOps 相关活动的首要目的是改善对客户和业务的价值交付,而不是降低成本,提升自动化程度,或者从配置管理中驱动任何事情;这意味着不同的...

274100
来自专栏SEO

「知识」8个改变游戏规则的SEO趋势

32070
来自专栏罗超频道

找社交要答案,搜狗能重构搜索吗?

移动互联网还在不断瓜分着互联网的流量,入口的碎片化使得搜索引擎受到很大冲击,搜索引擎都在尝试重构自己,寻找新的出路,执掌搜狗11年的王小川的思路是:接入独家内容...

44840
来自专栏互联网杂技

六步完成出色的用户体验设计

Product Manager& UX Guy at CoreLogic Great User Experience (UX) in 6 Easy Steps ...

35180
来自专栏程序猿DD

微服务与Serverless对决,谁才是未来之主?

近两年里,微服务的突然崛起让人仿佛看到了架构开发的新世界。摒弃繁杂而不稳定的巨型系统架构城堡,轻装上阵,应用单个开发,基于业务构建,自动化独立部署,不仅缩短了开...

24920
来自专栏猿天地

Kubernetes对阵Serverless,未来究竟是谁的?

近两年里,kubernetes的风头之盛可谓一时无两,在谷歌和大量开源社区的推动下,k8s技术不仅把容器的大规模应用彻底激活,提升了诸多编程语言的适用环境,更重...

15440
来自专栏BestSDK

神策数据分析SDK全面支持小程序,打造一站式PaaS + SaaS服务

在iPhone十周年之际,在众多互联网人的朋友圈里发酵月余的小程序,正式席卷而来。作为企业,如何应对小程序的访问用户“凌波微步”来去无痕?数据驱动理念该如何实现...

39240
来自专栏北京马哥教育

DevOps,就是开发吃掉运维?

? 本文转载自 DevOps 时代社区高翻院 在大多数的团队中,开发、运维之间有着一系列冲突和博弈。 有人说,DevOps 的出现让开发和运维不再相爱相杀,从...

48960
来自专栏罗超频道

百度特型搜索来了,解放伪球迷

世界杯将全世界引入看球模式,大量的“伪球迷”们纷纷浮出水面。如何判断一个球迷是否伪球迷呢?如果不知道解说员挂在嘴边的“越位”是什么意思,基本可以算伪球迷了。这一...

33630

扫码关注云+社区

领取腾讯云代金券