如何选择可以搞钱的技术栈

143 阅读4分钟

前言

之前在公司主要负责可观测性和 Pulsar 消息队列相关的内容,最近系统比较稳定,只需要做日常运维,所以就抽出时间逐步在接触 OLAP 相关的技术栈。

我们用的是 StarRocks,也是目前比较流行的 OLAP 数据库;在接触的这段时间以来,让我越发感觉到选对一个靠谱的技术方向的重要性。

这里以 Pulsar 举例,Pulsar 也是 Apache 的顶级项目,有一定的技术门槛,同时也解决以往消息队列的一些问题(多租户、低延迟、存算分离等) 但如果把它作为一个商业产品的话,相对来说付费能力还不够强。

其实也能想得到,就单纯的消息中间件在市场上能讲的故事不多,可以将它融入到其他的生态里,比如数据处理、业务解耦等,但总归是配角,没有它虽然没那么优雅,但也可以玩。

同理 OpenTelemetry 也是类似的,它用于可观测性系统,主要是就是拿来排查问题的,对于企业来说也谈不上刚需。

他们两个都有一个共同的特点:小公司不需要(或者自己维护开源版,量小也不容易暴露问题),大公司选择单独的团队自己维护,市场蛋糕较小。

即便是部分中厂可能选择购买云服务,一般也会选择和自己现有技术栈配套的云厂商,比如已经用了大部分阿里云的产品,这种周边服务也会尽可能的在阿里云上选择替代方案,毕竟这样的风险更小,而且国内的产品大多都写还 ALL IN。

可能更多的还是一些政企、金融等业务会选择这些开源产品的企业版,大部分因为需要私有化部署,不太方便直接使用公有云。

而更刚需的往往都是和数据相关的,比如数据库、MongoDB、ElasticSearch 、kubernetes 等,如果想要提升下非业务水平,倒是可以深入一下这些技术栈。

举例

拿数据库来说,任何公司都需要,即便是小公司也不敢在生产环境自己维护数据库,一般也会购买云产品,或者是招一个 DBA。

同理还有云原生相关的基础技术栈,比如 kubernetes 以及围绕着 kubernetes 周边的生态。

k8s 作为云原生的基础底座,只要涉及到上云就离不开它,不管小厂选择云服务还是大厂自己托管都得需要相关技能。

即便不是直接做 kubernetes 开发也得需要了解相关的知识,对自己理解整个系统是如何运转的很大的帮助。

除此之外还有也有个简单的方法:就是看看你们公司为哪些服务买单。

以我最近接触到的 StarRocks 为例,也是和数据处理相关的公司,他们在疫情期间成立的商业化公司,这几年非但没受到影响反而还在增长。

看到他们的招聘还蛮活跃。

即便是厂商更倾向于选择云厂商的数据服务,StarRocks 这类原厂公司或多或少也会参与进去提供一些技术支持。

不过可能有人的第一反应是这些产品的技术门槛较高,上手比较困难,但其实这些往往都是自己给自己上的难度。

以我最近提交的一个 PR 来说: github.com/StarRocks/s…

我之前根本就没有接触过 OLAP 相关的内容,但只要有场景,可以在本地 debug 复现,任何问题都很好解决,即便是这是你不熟的技术栈。

比如 ES 也是 Java 写的,如果你们公司为它付费了,那不如多花时间研究一下,不一定是需要改它的核心逻辑,上层也有很多东西可以参与的。

而一旦我们对这些技术栈熟悉之后,今后在换工作时就有着其他人不具备的优势,甚至可以加入这些技术背后的商业公司。

而这些公司大部分都是满足开发者的喜好:比如远程办公、技术驱动等,大家不妨从现在就可以试试。

总结

不管是哪种技术最终都是要转换为我们到手的收入,所以选择对收入更加敏感的技术栈还是很有必要的。

以上的内容主要是针对后端开发,当然这里并不包含想要做独立开发的技术栈,主要还是用于求职。

大家可以看看自己公司以及曾经的公司有对哪些技术付费,或者是一些都需要的刚需通用的技术栈,深入这些技能对搞钱或多或少都有好处。