最近跟一个客户聊起应用全面上云的事情,过程中涉及到了大量原有单体应用如何上云的问题。单体应用上云到底是直接迁移和还是重构,这个问题不管是在哪儿都是不是一个小 事儿,都需要审慎的思考。沟通下来很有感慨,把心得体会记录下来,以备咨询!
一、我们到底要解决什么问题
首先我们要搞清楚,我们到底需要解决什么问题。我们所在的组织到底是如何理解数字化和数字化转型的。从信息化到数字化的过程中,我们基本会从三个阶段一路发展过来:
1、概念导入期:在这个阶段我们会尝试理解和接受数字化的概念,我们会在IT基础设施这块“补短板、强弱项”, 但是非常容易陷入一个误区,那就是过分放大IT和技术的重要性,会认为数字化转型就是大干快上新技术和新平台、新应用,陷入技术的TCO泥潭里面 ;
2、能力成长期:随着基础设施的能力提升,我们开始深入考虑IT与业务的关系,IT开始从应用和数据两个层面跟业务产生深度关联,通过应用和数据能力的提升去探索新型能力建设。 在这个阶段始终有一个问题在困扰我们,到底是IT引领和推动业务创新发展,还是IT支撑业务发展 ;
3、价值呈现期:在理顺IT和业务的基础上,尘归尘土归土,我们不在纠结先有蛋还是先有鸡的问题。数字化转型的价值呈现,始终会通过业务的提升表现出来,我们需要面对的始终是业务如何发展。 就算云计算一样,云计算的价值就是最终大家会忘掉云的存在 。
通过上面对数字化的剖析,我们就会发现,我们关注的重点和核心永远都是业务的concern。因此对于应用上云过程中暴露出来的问题,就很容易理解了, 单体应用是直接迁移上云,还是做架构重构,这个问题必须回归到业务层面 ,一切以业务安全、稳定、敏捷、持续运行为第一要务。
二、非必要不重构,重构谨防过度设计
明白了数字化的发展历程和我们的关注点,我们应该形成一个行事原则,那就是非必要不重构,简单来说别给自己找麻烦。系统重构的必要性原则都有哪些呢:
1、 业务是否发生重大改变 :业务逻辑和流程已经发生了重大改变,现有应用系统已经无法适应业务的发展,或者是说业务部门的认知已经远超IT实现了;
2、 是否存在关键和致命问题 :现有系统有明显BUG,在现有条件下无法解决或者需要付出极大的成本,这个成本已经接近或者超过重构成本了;
3、 系统陈旧无法维护 :系统老旧,供应商无处可寻,关键文档缺乏,维护人员不足,系统谁也不敢动。这种情况下,如果业务逻辑清楚,非常有必要重构。长痛不如短痛;
4、 接口和依赖关系是否清晰 :在重构之前还有一个关键问题需要解决,那就是系统对外的所有接口和依赖关系是否都搞清楚了,如果没有,我劝你千万别动。
如果以上问题都搞清楚了,重构还是可以考虑的,关键是成本和代价必须在可承受的范围内。
架构的过度设计是怎么回事呢?这事其实很大程度上,有技术人员炫技的成分在里面。
嫌弃MySQL太土,非得上商业数据库,先单库不时髦,非得弄分库分表;嫌弃All in one设计太臃肿,非得搞微服务,明明调用关系很简单,非得搞解耦;数据访问逻辑很清楚,非得在数据和应用之间加一层代理;觉得虚拟机不先进,非得上容器;嫌弃原有代码不漂亮,非得重写的才香;嫌弃原有技术栈太旧,说出去丢人;不喜欢A语言编写的程序,非得觉得B语言才时髦。
大家别笑,上面这些问题每时每刻都在发生。 技术的选择和架构的设计没有绝对的对与错,适合的才是最好的 。过度设计劳民伤财而且后患无穷,我们始终都要以业务为中心,以持续发展为目标。
最后跟大家探讨一个问题,什么是架构?
我觉得,架构是在可调度的资源范围内,以实现某种特定需求为目标的,一个可持续可进化的技术约束和原则集合。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞2
添加新评论0 条评论