决策技术栈迁移的因素

一. 决策技术栈迁移的因素

那么,为何要进行技术栈迁移呢?是否是原有技术无法满足新的业务需求?对于遗留系统而言,这种情况总是存在,即需要扩展旧有系统的功能来满足新的业务。然而,这一原因并不足以支持做出技术栈迁移的决策。因为,从技术实现的角度来看,无论采取何种技术,都可以实现各种业务功能,无非是付出的成本不同而已 。基本上,这种成本一定会低于技术栈迁移的成本。此外,当今的软件开发,常常会将一个软件系统看做是完整的生态系统,在这个生态系统圈中,完全允许有多种技术平台(包括多种语言,甚至多种数据库范式)存在,只要我们能够合理地划定各个功能(或服务)的边界。

牵涉到架构中的任何一个重大决策,都需要综合考量和权衡,只有充分地识别了风险,才能制订有效的设计决策。个人认为,只有在如下几种情形出现时,才值得进行技术栈迁移。

原有技术不能保证新的质量需求

在一个系统的完整生命周期内,系统从诞生到发展,衰老和死亡,与人一样,是不可规避的过程。对遗留系统进行技术栈迁移,无非是希望通过新的技术给旧有系统注入活力,就像器官移植一般,对腐朽的部分进行切除与替换。系统之所以会衰老,会腐朽,原因还在于需求的变化,从而导致系统结构变得庞大而混乱。

我们在进行技术决策时,常常是根据当下的需求以及目前现有的技术,结合团队技术能力做出的最符合当时场景的合理决策。因而,技术栈迁移的原因常常是是因为“此一时彼一时”。在当时场景下做出的明智决策,随着时间的推移,会显得不合时宜。这一点在质量需求的满足上,体现得尤为明显。例如,系统对可伸缩性、性能、安全的要求,都可能因为新的质量需求的提出发生变化。而这些质量属性往往靠旧有技术无法解决。

RackSpace对日志处理的案例就属于这一场景[2] 。RackSpace的架构对日志的支持,先后经历了三个大版本的演化,从文件服务器到中心数据库,再到MapReduce,每次技术栈的迁移都是质量属性的驱动,不得不为之。

出于战略的考虑

这常常是因为企业架构的因素。对于一个企业而言,应该将其IT系统看作是一个整体的生态系统。对于一个正在成长中的企业而言,必然会随着整个企业组织结构、业务体系的变化而影响到IT系统。一般而言,企业IT系统的架构会存在两种情况。第一种情况是从无到有,根据企业架构师与业务架构师的设计,严格按照设计蓝图来规划所有的IT系统。第二种情况则可能是多种不同的系统并存(可能是因为企业采用了并购等方式兼并其他公司业务,也可能是因为不同的业务需要,购买了不同的软件系统)。第一种情况看似美好,但仍有可能发生规划蓝图不能满足需求的可能。第二种情况则处于龙蛇混杂的局面,最后可能导致所谓的“烟囱系统(Stovepipe System)[3]”,需要花大力气对各种系统进行整合。

无论是哪一种情况,一旦做出技术栈迁移的决定,都必然是企业战略上的考虑。当然这种战略指的是IT战略,也可能是企业的整体战略对IT系统产生影响。

我们的一个客户是一家大型的金融企业,提供了多种品牌的保险与银行业务。企业的战略目标是在体现品牌价值的同时,整体展现企业的平台作用。这对于IT系统而言,就意味着需要对各种业务系统进行整合、迁移。

整个系统的主要核心是对客户数据的管理,这些数据的管理会影响到整个企业的服务质量、市场推广与产品维护。由于该企业在银行业与保险业的发展壮大,是通过不断的合并与兼并来促进自身的发展。因而在其IT系统中,事实上存在多种不同的系统。客户信息散落在不同系统的数据库中。客户数据的整合,不仅有利于对这些信息的管理,保证数据的一致性,还在于从市场营销角度考虑,可以通过一致的客户信息对客户的情况做出全面了解,制定更好的推广策略。

原有的技术提供者不再提供支持

这种情形最是无奈,却时有发生。一种情况是使用的技术(平台、框架)不再被供应商维护,这一点体现在开源项目上更为明显。另一种情况则是所选的技术平台进行了升级,却没有很好地提供向前兼容,使得系统难以随之而升级。在架构设计中,这种绑定具体平台与技术的做法,实际上是反模式的一种,即“供应商锁定(Vendor Lock-In)[4]”。

使用旧有技术的成本太高

IT技术并非一定是新技术成本高于旧技术,事实上,随着技术的创新和发展,技术越新,成本越能得到更好的控制。当新旧技术的成本之差,远远高于技术栈迁移的成本,就值得做出迁移的决策了。例如,我们的一个项目需要处理的遗留系统,使用了某软件公司的产品,该产品必须运行在大型服务器上。该产品主要提供客户信息的处理。这是一个存在超过十年以上的产品,之后加入的子系统并未再使用该产品。如今,该产品所支持的客户数量并不多,而每年的产品许可费用以及大型服务器的维护成本都非常高。最后,我们对该产品提供的功能进行了迁移,以渐进地方式逐渐替换了该产品,降低了系统成本。

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2014-08-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

微服务架构:敏捷软件架构的实际体现

正如敏捷开发能够解决工程技术瓶颈,微服务则能够解决架构层面的瓶颈。 2014年出现的“微服务”理念仿佛一道闪电,让技术人员意识到这一全新架构风格的重要意义。面向...

3125
来自专栏Forrest随想录

有运维专家推荐吗?

因为工作行业的原因,会有很多的同行或朋友找我推荐一些有运维经验的人,或者直接希望要运维专家。

813
来自专栏达摩兵的技术空间

如何平衡研发与开发

对于程序员来讲,很多时候会纠结一个问题,我做了这么多项目,除了上线了产品,自己的逻辑、对产品的设计进步了哪些,这一点对前端、后端其实都是一样的具有迷惑性。

913
来自专栏安全领域

物联网对统一通信IT的影响

首先, 物联网是一种现代技术现象, 兼容设备在物联网中可以通过使用互联网来进行互相通信, 并且可以通过收集和交换自身的数据来协调它们的行为. 一个更基本的定义将...

33812
来自专栏云计算D1net

构建私有云时需要考虑的十大要点

私有云让企业能够保护并控制应用程序和数据,同时让开发团队能够更快速、更顺畅地提供业务价值。但是虽然构建私有云有望彻底改变IT,要是没有认真的规划和准备,它也无异...

2613
来自专栏云计算D1net

2015年IT发展四大趋势与云计算三大预测

存储资源日益减少 对于大多数人来说,预测未来是非常困难得。但是人们总是喜欢关注未来会发生什么事情。在IT领域,人们同样喜欢关注趋势发展。到了2014年底了。又该...

32910
来自专栏云计算D1net

探讨:混合云引发IT产生哪些改变

混合云对于很多人而言意味着很多事情。在过去的一年中,其作为一个概念和一款非常实用的解决方案,混合云终于迎来了自己的时代。随着企业将云计算与其他一些技术进行结合,...

3397
来自专栏镁客网

小i机器人朱频频:会话AI将成为主流人机交流方式,积累和深度学习是关键 | 镁客请讲

1300
来自专栏腾讯大讲堂的专栏

为B端用户设计

? 一、为什么做ToB设计很难 1. 设计师不是目标用户 B端产品一般都是面向专业客户的,有着较高的业务门槛。以腾讯云为例,使用者大多是技术运维,设计师既不...

3775
来自专栏云计算D1net

什么是多重云?云计算的下一步

导语 “多重云”意味着使用多个公共云。当企业试图避免对单个公共云提供商的依赖时,从每个公共云中选择特定服务以获得每个公共云的最佳服务,或者他们希望获得双方利益...

3288

扫码关注云+社区