我们真的需要这么复杂的技术栈吗？

现在业界流行的是k8s全家桶, ELK全家桶, Gitlab全家桶。分别使用他们的如下能力和作用：

k8s: 自动调度，自动扩容
ELK: 日志查询
Gitlab: 代码仓库，CI

这些东西的出现，主要是为了解决：

微服务流行之后，服务数量迅速上升，管理难度增大，手动调度容器已经吃力
日志分散在各处
此前一般使用Jenkins作为CI，而Gitlab CI与Gitlab的结合更好些

可是，我们真的需要这么复杂的技术栈吗？现在的IT界究竟怎么了？颇有一番追星的感觉。

本文所面向的主体是中小型团队，大公司的确有此类需求，虽然上述方案并不一定是最佳方案。

微服务？也许是徒增烦恼

在单体应用时期，我们面临这样一个问题，单体应用代码量大，结构复杂，如果要快速迭代，也许它的启动预热时间要很久，团队中各开发人员之间的协作可能与快速迭代冲突。

于是有了微服务，好吧，它其实就是20年前的SOAP换了一身衣服，再次登场 — 计算机历史总是如此。将原有的服务拆分为多个微服务之后，我们面临了新的问题，而为了解决这些问题，我们引入了上述的三个主角：k8s, ELK, Gitlab。它们都有一套权限管理模型，很明显，在大公司，是适用的，大公司需要这样的管控。

可是如今，很多中小型团队也已经上了船。

什么最重要？效率！

k8s的操作并不能说简单，当然，常用的其实就那么几个，但是维护一个k8s集群需要动用的人员，了解的知识可不少。一般来说，至少需要：

维护k8s本身(运维)
维护分布式文件系统供stateful pod使用，如ceph，glusterfs(运维工作)
与开发对接，大部分开发对k8s的操作并不熟悉，对k8s的yaml配置文件就更不用说了，再加上如果任由开发自己改资源配置，那么 k8s就相当于被打瘸了一条腿，毕竟谁都想自己的应用能多分配点资源

对于一个中小型团队来说，是否应该搭上三个人来做这个事情，是值得考量的。更不用提对于开发来说，需要花额外的时间去了解 k8s专属的命令，需要了解如何更改配置等，这对于开发来说，都是额外的心智负担。

额外心智负担增加，开发设计、编程时间减少 —- 总体来说，效率降低。

搜索日志需要搜索引擎吗？

如果只把日志存储在ELK里，是否需要考虑到磁盘损坏的问题呢？对于重要日志，是需要的，因此通常ELK搭建起来，就需要耗费好几台机器：

ElasticSearch 3节点起(为了高可用)
Kibana 另外放，也许要一个节点

可是，我只是想搜索一个日志而已，ELK之后，tail, grep, awk, sed 等一众UNIX命令都无法再使用，在命令行里，人是机器的主人，可是图形界面里，机器是人的主人。

我有点担心，10年后还有多少人会使用命令行？或者，ELK倒下之后，新一代程序员又需要重学多少特定平台的知识？别忘了，一招鲜吃遍天才能增加程序员的竞争力，不容易过时的东西，才能随着经验增加竞争力。

CI的工具已经换了几代了

最开始流行的是Jenkins，很方便，我只需要使用熟悉的bash脚本，操作着我的命令行，结合ansible，我可以做很多事情。

直到后来，Gitlab CI来了，简单通用的shell脚本被换成了切分成段的yaml — 这真是一个坏消息。

通用技术vs追新

商业中，护城河是一件非常重要的事情，这是一个企业未来盈利的保障。如果一家公司躺着就能赚钱，只需要稍费点功夫，就没人能抢的动它的地盘，对于商业来说，这绝对是一家值得投资的公司。赚多少，就实打实的落在口袋里。

而对于没有护城河的公司，或者是隔三差五又要重新挖护城河的公司，则很难称得上是一家值得投资的公司。如果一家公司赚来的钱，都需要用于维护壁垒，不断的重挖护城河，赚的钱能否落袋为安都是未知的，投资这样的公司让人晚上睡得不安。

对于技术来说，是一样的。并不是说保守就是好的，保守不好，我们需要新知识，新技术来提高生产力，但是最重要的是，去学习通用的，好用却不容易过时的，不被特定平台绑定的技术，或者即使被平台绑定，但是这个平台永远都不会倒闭的技术，随着学习和使用，时间会带来经验的加成，这会提升你的竞争力。

反之，如果今天使用A技术，结果明天流行B技术，A技术所积累的经验，有什么用呢？基本没用。

回到最开始

最后，回到最开始，让我们反思一下，我们是否真的需要如此复杂的技术栈？对于当前的团队来说，是否把代码写好会是更重要的一件事情？

也许我们不需要如此复杂的技术栈。