聊聊复杂性也是IT成本,你明白了吗?

云计算 云原生
近些年一些企业的IT似乎陷入了一个思维怪圈,放弃了原有的简单设计,从而选择了一个更为复杂,似乎也更为先进的技术堆栈。不过在这些设计中引入的复杂性,早晚还是会以运营成本的方式给予回报的。复杂性也是IT成本这个问题,早晚会引起人们的广泛思考的。​

​7Signals从公有云撤退后还应该继续类似公有云商的技术堆栈,继续使用K8S,但是他们连K8S都放弃了,改为私有云虚拟机+DOCKER,就值得我们更仔细的去研究一番了。为了更好地了解这个事件,我一大早又看了一遍rework对David和37Signals COO Eron Nicholson的访谈的文字稿。实际上从访谈中我们可以获得更多的值得思考的线索,不过很多内容不在今天要讨论的范围内,以后找机会再聊吧。

从这个访谈中,我看到了很多对于这个问题思考的细节,David他们当初上云的目的是解决IT的复杂性问题,他们可能会面临系统上线两周后的几十万访问的尖峰,公有云很好地帮他们熬过了这个时期。随着业务的不断成熟与扩大,系统负载变得很平稳,没有黑色星期五的销售量暴增,也没有圣诞假期的低谷。于是业务的发展,IT系统的负载变得十分容易预测了,因此需要公有云解决的复杂性问题不存在了。此时带来了一些新的复杂性,公有云对于37Signals来说是一个黑匣子,它是否真的安全、可靠,只有出了问题才知道,在此之前,它就像一场梦一样不可捉摸。

图片

37Signals付出了高额的成本,但是他们还是买不起更高级别的服务,亚马逊并不能及时接听他们的电话,遇到的所有问题也必须由他们自己的运营团队来解决。因此上云数年后公有云并没有真正帮他们解决掉复杂性的问题,只是让他们的运营成本变得更高了。

对于他们回归自营虚拟机+DOCKTER,则是对复杂性的另一个思考,他们认为K8S太复杂了,其陡峭的学习曲线让他们感到力不从心。当一切都正常时,大家都觉得K8S很不错,用起来很省心,但是一旦出问题的时候,他们是无力解决这些问题的。对于一个拥有数十万注册用户,但是只有80多人的中型SAAS服务商来说,很好地掌握K8S的复杂运维并不是一件容易的事情,因此他们最后决定将K8S上的应用退回到虚拟机+DOCKER的环境中,复杂度的降低让他们对整个系统的把控能力提升了许多,他们的十几个人的运营团队可以十分轻松的把控整个平台和系统了。而之前他们的系统一直为不太必要的系统复杂性的可能性买单,从而面临诸多的运维挑战。

大型互联网企业的业务面临巨大的不确定的负载挑战,因此他们的系统可以面向各种各样的复杂性。因此他们从头到尾构建了一套IT体系,从研发到运营,这套体系是完全适应这个IT基础平台和技术堆栈的。近些年来,大型互联网企业也在做技术输出,很多传统企业也接受了这种技术输出。但是这些传统企业往往只能学其表,而无法做到表里一体。因此他们引入大型互联网企业的技术的同时也引入了IT的复杂性,但是并没办法掌握解决复杂性问题的方法。同时,这些企业的业务与互联网企业完全不同,他们也并没有那么多的复杂性要去解决。他们实际上并不需要掌握解决这些复杂性的钥匙,因此他们拿到钥匙之后并不知道门在哪里。

实际上很多企业或者团队低估了复杂性所带来的成本,因此过于强调了敏捷和可扩展性带来的好处。这几年我一直跟踪一个项目,这是一个面向近百万用户使用的管理类系统,其在线用户数最终会突破10万。最初设计是从以前的Oracle数据库迁移到RDS Mysql作为数据库。他们最初选择了32C/128GB的标准RDS实例,每个数据库不超过500GB容量。在研发过程中,他们解决了很多分库分表的难题,通过一年多的时间,终于完成了应用的改造。上线试运行阶段他们解决了大量的性能问题,对数据库做了进一步的拆分。不过随后他们发现,如果完成整个系统上线,数据库系统将需要被拆分为120+个RDS实例,而如果为了进一步提升处理能力,为今后系统长期运行做准备,必须使用读写分离的方式,如果这样,他们可能需要将整个系统拆分为360+实例。在一个系统中创建与运维如此大数量的RDS实例,让他们感到恐惧。

为了解决数据库的复杂性问题,他们又开始对数据库实例进行合并,将120+的数据库实例都改为大规格的90C/720GB的MYSQL实例。这样就把数据库实例的数量减少为40+,不过每个数据库的容量也变成了1.5TB。看到这个新的数据库设计,很多人觉得放心多了,不过我也提出了一个新的问题,运维一个23C/128GB,小于500GB的MYSQL数据库实例与运维一个90C/720GB,1.5TB的MYSQL实例的难度相同吗?我想很多了解MYSQL,深度使用过MYSQL的朋友心里已经有答案了。

对于需要长期运行的系统来说,复杂性必然带来额外的成本,增加的成本的高低取决于系统本身的属性。因此解决IT系统的复杂性是我从事IT工作这三十多年来很多企业一直在考虑的问题。IOE架构也是因为它解决了企业IT建设与运营的复杂性而获得了巨大的成功。云平台实际上也是解决了IT的复杂性而得到了极大的发展,它让用户不需要考虑底层IT基础设施与平台的复杂性,而可以更多地关注企业的业务。

实际上前面所举的例子并不需如此复杂,实际上近百万用户是按省为单位使用这个系统的,这套系统完全可以按照省为单位拆分为多套系统。每套系统的应用、数据库都可以独立部署,因为除了总部的统计分析业务外,用户不会跨省办理业务,而统计分析完全可以在数据中台或者数据仓库里完成。

近些年一些企业的IT似乎陷入了一个思维怪圈,放弃了原有的简单设计,从而选择了一个更为复杂,似乎也更为先进的技术堆栈。不过在这些设计中引入的复杂性,早晚还是会以运营成本的方式给予回报的。复杂性也是IT成本这个问题,早晚会引起人们的广泛思考的。​

责任编辑:武晓燕 来源: 白鳝的洞穴
相关推荐

2022-10-19 08:19:32

动态基线预警

2023-06-14 08:15:34

算法合并操作Winner

2022-10-24 20:25:40

云原生SpringJava

2021-09-16 21:34:52

5G专线

2022-05-31 07:32:19

JDK8API工具

2024-05-30 08:19:52

微服务架构大型应用

2022-03-17 08:54:59

软件系统重构

2022-03-03 09:20:08

分布式数据库场景

2012-12-26 10:53:26

2022-07-27 08:31:28

SQL开发控制

2019-08-21 13:24:25

KubernetesHadoop容器

2017-06-23 08:45:02

存储技术复杂性

2009-01-20 15:23:33

存储安全密钥数据保护

2019-05-13 15:47:29

Kubernetes云计算云复杂性

2020-06-15 09:58:23

云计算云安全数据

2016-11-22 09:24:29

大数据部署Hadoop

2012-09-19 13:18:37

复杂设计UI设计

2012-04-10 22:52:58

IBMTivoli云计算

2019-07-29 12:35:15

云计算复杂性云计算平台

2019-11-23 23:30:55

Python数据结构时间复杂性
点赞
收藏

51CTO技术栈公众号