当前位置:网站首页>35岁那年,我做了一个面临失业的决定

35岁那年,我做了一个面临失业的决定

2022-07-07 21:53:00 钱难有~

前言

最近和老板以及CTO商议,最终是决定了转向云原生数据库,在会议结束后,我们的CTO揽着我的肩膀,和我说了一句意味深长的话:我35岁了,转向云原生数据库这个决定可能会影响我的职业生涯,要么晋升迎娶白富美,要么搞得一团糟最终失业。我听了这句话有点意味深长,虽然我们公司没有全面拥抱云原生,但是目前公司大部分产品已经是转向了云原生数据库的怀抱了。我目前接触数据库工作接近10年了,前5年接触的是传统的数据库,后5年随着技术的变革开始接触云数据库,随后就在这家公司开始接受云原生数据库,感触还是很多的。

前5年,传统数据库的痛

我刚出来工作那会是12年,那时候移动互联网开始兴起,越来越多的互联网公司开始兴起,数据逐渐有了一定的规模,我去找了一份后台开发的工作,除了每天写CRUD的代码以外,还需要去维护和管理公司的机房,没错你没有听错就是机房,那时候数据库基本上是自己搭建的,用交换机和服务器,在一个’阴森’的房间,我穿着厚厚的防冻服,在冰凉的黑窗口独自敲着命令,幸亏还有一丝灯光,不至于显得太过于凄凉。
在这里插入图片描述

作为一个业余的机房管理者,要头疼的东西实在是太多了,首先设备采购就是一个很大的问题,资本家都青睐于用一份钱买两份商品,所以前期的服务器的配置、交换机的敲定就很头疼,如果选择配置低的,后期我需要花很大的功夫去优化去配置,都想提桶了,我是CRUD程序员,不是Linux程序员。如果选择配置高的,我肯定会轻松很多,可以专注于业务的编写以及整体架构的优化,但是把,成本太高了,直接被pass了。
其次就是机房的各种软件的安装和维护,因为我们公司没有请专门的运维,那个时候运维这个工作还不是很成熟,没有专门的运维,都是由程序员兼职去做的,那时候公司有一个机房值班表,好家伙,我一看,全部是后台开发程序员。软件安装和各种虚拟化以及后期的维护都是我们来做的,痛!太痛了。我画了一张示意图,大概我一个人一天要去管理和维护那么多太机器。

在这里插入图片描述
还有一个很重要的点,那就是资费的问题,因为我们公司是房地产中间商的网站,当时的业务是有季节性的,大概在6-12月是旺季,那时候购房者的需求是比较大的,由于流量的增大,对于服务器的要求也是比较大的,这个时候上半年采购的服务器完全是不够用的,这半年我们团队基本上是不会去写业务的,基本上就是各种优化,降低服务器的负载,我当时就在想,如果有服务器可以灵活一点该多好。
在这里插入图片描述

后3年,云数据库的轻

后面实在是不堪重负,我选择了提桶。时间眨眼间过了五年多,那时候的数据库已经日趋成熟,MySQL成为了霸主,市面上百分之80的公司都在用,而且出现了非关系型数据库,像redis、ElasticSearch等这种数据库,由于数据量的增大,数据库在整个业务中显得越来越重要了。
这个时候出现了云数据库,我们公司由于是快速发展中的小企业,使用的是亚马逊云原生数据库,我第一次使用就被这种使用模式所惊艳了。真的是很方便,完全不需要我去担心数据库方面的东西,因为他们都帮我配置好了,我只需要专注于我的sql编写即可,一旦有大量的要求,我走审批加钱去升级容量就可以了,一旦到了淡季我可以降低容量,甚至还体验了一把无服务器版本的Aurora,不用都无需花什么钱,简直省了不少钱。
在这里插入图片描述
而且连传统的机房的钱也省了,据说这家企业全部产品转向云原生数据库了以后,把公司的原来的机房改造成了一个健身房。
在这里插入图片描述
刚好这几年,终端工具也逐渐多了起来,像XSehll、MobaXterm 等工具,可以直接通过这种工具去连接到云端,我甚至有点怀念我以前在小黑空调房里面调试数据库的日子了。
在这里插入图片描述
方便不说,而且种类是真的齐全,如果想要关系型数据库,可以选择Amazon RDS、Amazon Aurora,如果想选择缓存,可以选择Amazon Elasticache、Amazon MemoryDB for Redis,想用文档型数据库,有Amazon DocumentDB,想尝试图数据库,可以选择Amazon Neptune,甚至是非关系型数据库,有Amazon DynamoDB,可以说是只有你用不到,没有亚马逊云科技做不到。

这2年,云原生数据库的卷

这两年,我也逐渐迈入云原生的步伐,不仅仅是因为各大厂商都开始发布自己的云原生的产品,越来越卷了,更重要的是,随着人工智能和大数据的普及,云原生才是真正的未来。我们之前使用的云数据库其实本质上是属于云计算领域,云计算应用程序通常是在内部使用传统基础设施开发的,并且经过调整后可以在云中远程访问,简单理解就是我在地面上通过远程软件去链接大气层的云软件,实质上还是部分在云上。接下来我来讲讲为啥我要完全上云?
在这里插入图片描述
首先从是使用角度,云计算应用程序通常需要手动升级,比如说我要升级数据库的或者是服务器的,通常是需要先关闭再升级再打开这么几个步骤,从而会导致应用程序中断和关闭,而我在使用云原生数据库的时候是感受到了云原生数据库的友好,他是具备高度可扩展性,可以对集群规模进行实时调整,而不会对整个应用程序造成干扰。意味着我可以无感升级或者降配。
接着我感触更深的就是价格,毕竟我们上云就是为了降低成本,从以前的自建机房到后面的云数据库,都在进一步降低成本,或者说是把成本转嫁到其他厂商身上,我们把机房搭建、服务器运行、服务器维护、软件安装等一系列成本转嫁到了亚马逊云科技等一众厂商身上,我们只需要付小部分钱就可以享受到了更优越的服务。
亚马逊云科技的云原生应用程序不需要任何硬件或软件上的投资,因为它们是在云上进行的,可以灵活的利用云的弹性优势,因此使用起来相对便宜,这对于中小型企业来说简直是福音。

私货:Amazon DocumentDB的使用体验

顺带说一下最近公司转型云原生数据库使用最频繁的一款产品吧,那就是Amazon DocumentDB。他是一款兼容MongoDB的数据库产品,由于公司在转型期间所做的一些业务拓展,对于海量的json数据的处理有性能与成本方面的考量。
我们MongoDB是一款文档型数据库,他使用的是json格式的数据,与传统的关系型数据库不同。在以前,如果想要支持高并发的请求,通常我需要搭建多台服务器组成一个集群,而Amazon DocumentDB通过独立扩展计算和存储,支持每秒数以百万计文档的读取请求,就问各位老铁,这个功能六不六。
我们公司的评论是使用MongoDB来存储的,按照以前方式的部署,一旦服务器出现了问题,不仅仅会导致评论这个功能出现问题,一不小心还会导致整个系统宕机,而Amazon DocumentDB的一个功能给了我很大帮助,那就是自动化硬件预置、修补,我至此就再也没有担心过稳定性的问题了,而且他还可以通过自动复制、连续备份和严格的网络隔离实现 99.999999999% 的持久性,数据的稳定性保障让我很放心。
从MongoDB迁移到Amazon DocumentDB也很简单,借助另一个服务Amazon DMS就可以啦。

总的来说,这一轮体验下来的感受还不错,性能方面目前是比MongoDB集群部署的性能还要再高一点,估计都替老板省下了不少钱。

总结

35岁CTO的一句话给我的感触实在是太深了,回想起我刚入职使用的技术和现在使用的技术,简直是千差万别,需求在不断的变难,而我们也在不断进步,相信在未来,更优秀的云原生数据可以有更广泛更多的运用,而不是仅仅只是停留在开发者的层面。

原网站

版权声明
本文为[钱难有~]所创,转载请带上原文链接,感谢
https://blog.csdn.net/weixin_43896643/article/details/125607875