从这个访谈中，我看到了很多对于这个问题思考的细节，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成本这个问题，早晚会引起人们的广泛思考的。
