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

数据库
0
0
{"value":"#### **前言**\n最近和老板以及 CTO 商议,最终是决定了转向云原生数据库,在会议结束后,我们的 CTO 揽着我的肩膀,和我说了一句意味深长的话:我35岁了,转向云原生数据库这个决定可能会影响我的职业生涯,要么晋升迎娶白富美,要么搞得一团糟最终失业。我听了这句话有点意味深长,虽然我们公司没有全面拥抱云原生,但是目前公司大部分产品已经是转向了云原生数据库的怀抱了。我目前接触数据库工作接近10年了,前5年接触的是传统的数据库,后5年随着技术的变革开始接触云数据库,随后就在这家公司开始接受云原生数据库,感触还是很多的。\n\n#### **前5年,传统数据库的痛**\n我刚出来工作那会是12年,那时候移动互联网开始兴起,越来越多的互联网公司开始兴起,数据逐渐有了一定的规模,我去找了一份后台开发的工作,除了每天写 CRUD 的代码以外,还需要去维护和管理公司的机房,没错你没有听错就是机房,那时候数据库基本上是自己搭建的,用交换机和服务器,在一个'阴森'的房间,我穿着厚厚的防冻服,在冰凉的黑窗口独自敲着命令,幸亏还有一丝灯光,不至于显得太过于凄凉。\n\n![image.png](https://dev-media.amazoncloud.cn/634e5ee244ee4f978eb66d63bbd8b9ec_image.png)\n\n作为一个业余的机房管理者,要头疼的东西实在是太多了,首先设备采购就是一个很大的问题,资本家都青睐于用一份钱买两份商品,所以前期的服务器的配置、交换机的敲定就很头疼,如果选择配置低的,后期我需要花很大的功夫去优化去配置,都想提桶了,我是 CRUD 程序员,不是 Linux 程序员。如果选择配置高的,我肯定会轻松很多,可以专注于业务的编写以及整体架构的优化,但是把,成本太高了,直接被 pass 了。\n其次就是机房的各种软件的安装和维护,因为我们公司没有请专门的运维,那个时候运维这个工作还不是很成熟,没有专门的运维,都是由程序员兼职去做的,那时候公司有一个机房值班表,好家伙,我一看,全部是后台开发程序员。软件安装和各种虚拟化以及后期的维护都是我们来做的,痛!太痛了。我画了一张示意图,大概我一个人一天要去管理和维护那么多太机器。\n\n![image.png](https://dev-media.amazoncloud.cn/e16a8018c78840d3b5f547089062abd1_image.png)\n\n还有一个很重要的点,那就是资费的问题,因为我们公司是房地产中间商的网站,当时的业务是有季节性的,大概在6-12月是旺季,那时候购房者的需求是比较大的,由于流量的增大,对于服务器的要求也是比较大的,这个时候上半年采购的服务器完全是不够用的,这半年我们团队基本上是不会去写业务的,基本上就是各种优化,降低服务器的负载,我当时就在想,如果有服务器可以灵活一点该多好。\n\n![image.png](https://dev-media.amazoncloud.cn/5d7d3a6f32af495fa3b9d0b79bf45726_image.png)\n\n#### **后3年,云数据库的轻**\n后面实在是不堪重负,我选择了提桶。时间眨眼间过了五年多,那时候的数据库已经日趋成熟,MySQL 成为了霸主,市面上百分之80的公司都在用,而且出现了非关系型数据库,像 redis、ElasticSearch 等这种数据库,由于数据量的增大,数据库在整个业务中显得越来越重要了。\n这个时候出现了云数据库,我们公司由于是快速发展中的小企业,使用的是亚马逊云原生数据库,我第一次使用就被这种使用模式所惊艳了。真的是很方便,完全不需要我去担心数据库方面的东西,因为他们都帮我配置好了,我只需要专注于我的 sql 编写即可,一旦有大量的要求,我走审批加钱去升级容量就可以了,一旦到了淡季我可以降低容量,甚至还体验了一把[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)版本的 Aurora,不用都无需花什么钱,简直省了不少钱。\n\n![image.png](https://dev-media.amazoncloud.cn/5808fc3061f54114941633a11a7277b5_image.png)\n\n而且连传统的机房的钱也省了,据说这家企业全部产品转向云原生数据库了以后,把公司的原来的机房改造成了一个健身房。\n\n![image.png](https://dev-media.amazoncloud.cn/c2b83d3bee2549ed9ba9e9fce1a03286_image.png)\n\n刚好这几年,终端工具也逐渐多了起来,像 XSehll、MobaXterm 等工具,可以直接通过这种工具去连接到云端,我甚至有点怀念我以前在小黑空调房里面调试数据库的日子了。\n\n![image.png](https://dev-media.amazoncloud.cn/882db86967ea4d8a992c7a634f1e6b5b_image.png)\n\n方便不说,而且种类是真的齐全,如果想要关系型数据库,可以选择 [Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail)、[Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail),如果想选择缓存,可以选择 Amazon Elasticache、[Amazon MemoryDB for Redis](https://aws.amazon.com/cn/memorydb/?trk=cndc-detail),想用文档型数据库,有[Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail),想尝试图数据库,可以选择 [Amazon Neptune](https://aws.amazon.com/cn/neptune/?trk=cndc-detail),甚至是非关系型数据库,有 [Amazon DynamoDB](https://aws.amazon.com/cn/dynamodb/?trk=cndc-detail),可以说是只有你用不到,没有亚马逊云科技做不到。\n#### **这2年,云原生数据库的卷**\n\n这两年,我也逐渐迈入云原生的步伐,不仅仅是因为各大厂商都开始发布自己的云原生的产品,越来越卷了,更重要的是,随着人工智能和大数据的普及,云原生才是真正的未来。我们之前使用的云数据库其实本质上是属于云计算领域,云计算应用程序通常是在内部使用传统基础设施开发的,并且经过调整后可以在云中远程访问,简单理解就是我在地面上通过远程软件去链接大气层的云软件,实质上还是部分在云上。接下来我来讲讲为啥我要完全上云?\n\n![image.png](https://dev-media.amazoncloud.cn/cd57bcae31e94a3388658c7ebeceaa9a_image.png)\n\n首先从是使用角度,云计算应用程序通常需要手动升级,比如说我要升级数据库的或者是服务器的,通常是需要先关闭再升级再打开这么几个步骤,从而会导致应用程序中断和关闭,而我在使用云原生数据库的时候是感受到了云原生数据库的友好,他是具备高度可扩展性,可以对集群规模进行实时调整,而不会对整个应用程序造成干扰。意味着我可以无感升级或者降配。\n接着我感触更深的就是价格,毕竟我们上云就是为了降低成本,从以前的自建机房到后面的云数据库,都在进一步降低成本,或者说是把成本转嫁到其他厂商身上,我们把机房搭建、服务器运行、服务器维护、软件安装等一系列成本转嫁到了亚马逊云科技等一众厂商身上,我们只需要付小部分钱就可以享受到了更优越的服务。\n亚马逊云科技的云原生应用程序不需要任何硬件或软件上的投资,因为它们是在云上进行的,可以灵活的利用云的弹性优势,因此使用起来相对便宜,这对于中小型企业来说简直是福音。\n#### **私货:[Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail) 的使用体验**\n顺带说一下最近公司转型云原生数据库使用最频繁的一款产品吧,那就是[Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail)。他是一款兼容 MongoDB 的数据库产品,由于公司在转型期间所做的一些业务拓展,对于海量的 json 数据的处理有性能与成本方面的考量。\n我们 MongoDB 是一款文档型数据库,他使用的是 json 格式的数据,与传统的关系型数据库不同。在以前,如果想要支持高并发的请求,通常我需要搭建多台服务器组成一个集群,而 [Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail) 通过独立扩展计算和存储,支持每秒数以百万计文档的读取请求,就问各位老铁,这个功能六不六。\n我们公司的评论是使用 MongoDB 来存储的,按照以前方式的部署,一旦服务器出现了问题,不仅仅会导致评论这个功能出现问题,一不小心还会导致整个系统宕机,而 [Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail) 的一个功能给了我很大帮助,那就是自动化硬件预置、修补,我至此就再也没有担心过稳定性的问题了,而且他还可以通过自动复制、连续备份和严格的网络隔离实现 99.999999999% 的持久性,数据的稳定性保障让我很放心。\n从 MongoDB 迁移到 [Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail)也很简单,借助另一个服务Amazon DMS 就可以啦。\n\n![image.png](https://dev-media.amazoncloud.cn/3bc3ec00b9a541bd8b204d7d9f5ec87a_image.png)\n\n总的来说,这一轮体验下来的感受还不错,性能方面目前是比 MongoDB 集群部署的性能还要再高一点,估计都替老板省下了不少钱。\n#### **总结**\n35岁 CTO 的一句话给我的感触实在是太深了,回想起我刚入职使用的技术和现在使用的技术,简直是千差万别,需求在不断的变难,而我们也在不断进步,相信在未来,更优秀的云原生数据可以有更广泛更多的运用,而不是仅仅只是停留在开发者的层面。","render":"<h4><a id=\\"_0\\"></a><strong>前言</strong></h4>\\n<p>最近和老板以及 CTO 商议,最终是决定了转向云原生数据库,在会议结束后,我们的 CTO 揽着我的肩膀,和我说了一句意味深长的话:我35岁了,转向云原生数据库这个决定可能会影响我的职业生涯,要么晋升迎娶白富美,要么搞得一团糟最终失业。我听了这句话有点意味深长,虽然我们公司没有全面拥抱云原生,但是目前公司大部分产品已经是转向了云原生数据库的怀抱了。我目前接触数据库工作接近10年了,前5年接触的是传统的数据库,后5年随着技术的变革开始接触云数据库,随后就在这家公司开始接受云原生数据库,感触还是很多的。</p>\n<h4><a id=\\"5_3\\"></a><strong>前5年,传统数据库的痛</strong></h4>\\n<p>我刚出来工作那会是12年,那时候移动互联网开始兴起,越来越多的互联网公司开始兴起,数据逐渐有了一定的规模,我去找了一份后台开发的工作,除了每天写 CRUD 的代码以外,还需要去维护和管理公司的机房,没错你没有听错就是机房,那时候数据库基本上是自己搭建的,用交换机和服务器,在一个’阴森’的房间,我穿着厚厚的防冻服,在冰凉的黑窗口独自敲着命令,幸亏还有一丝灯光,不至于显得太过于凄凉。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/634e5ee244ee4f978eb66d63bbd8b9ec_image.png\\" alt=\\"image.png\\" /></p>\n<p>作为一个业余的机房管理者,要头疼的东西实在是太多了,首先设备采购就是一个很大的问题,资本家都青睐于用一份钱买两份商品,所以前期的服务器的配置、交换机的敲定就很头疼,如果选择配置低的,后期我需要花很大的功夫去优化去配置,都想提桶了,我是 CRUD 程序员,不是 Linux 程序员。如果选择配置高的,我肯定会轻松很多,可以专注于业务的编写以及整体架构的优化,但是把,成本太高了,直接被 pass 了。<br />\\n其次就是机房的各种软件的安装和维护,因为我们公司没有请专门的运维,那个时候运维这个工作还不是很成熟,没有专门的运维,都是由程序员兼职去做的,那时候公司有一个机房值班表,好家伙,我一看,全部是后台开发程序员。软件安装和各种虚拟化以及后期的维护都是我们来做的,痛!太痛了。我画了一张示意图,大概我一个人一天要去管理和维护那么多太机器。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/e16a8018c78840d3b5f547089062abd1_image.png\\" alt=\\"image.png\\" /></p>\n<p>还有一个很重要的点,那就是资费的问题,因为我们公司是房地产中间商的网站,当时的业务是有季节性的,大概在6-12月是旺季,那时候购房者的需求是比较大的,由于流量的增大,对于服务器的要求也是比较大的,这个时候上半年采购的服务器完全是不够用的,这半年我们团队基本上是不会去写业务的,基本上就是各种优化,降低服务器的负载,我当时就在想,如果有服务器可以灵活一点该多好。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/5d7d3a6f32af495fa3b9d0b79bf45726_image.png\\" alt=\\"image.png\\" /></p>\n<h4><a id=\\"3_17\\"></a><strong>后3年,云数据库的轻</strong></h4>\\n<p>后面实在是不堪重负,我选择了提桶。时间眨眼间过了五年多,那时候的数据库已经日趋成熟,MySQL 成为了霸主,市面上百分之80的公司都在用,而且出现了非关系型数据库,像 redis、ElasticSearch 等这种数据库,由于数据量的增大,数据库在整个业务中显得越来越重要了。<br />\\n这个时候出现了云数据库,我们公司由于是快速发展中的小企业,使用的是亚马逊云原生数据库,我第一次使用就被这种使用模式所惊艳了。真的是很方便,完全不需要我去担心数据库方面的东西,因为他们都帮我配置好了,我只需要专注于我的 sql 编写即可,一旦有大量的要求,我走审批加钱去升级容量就可以了,一旦到了淡季我可以降低容量,甚至还体验了一把无服务器版本的 Aurora,不用都无需花什么钱,简直省了不少钱。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/5808fc3061f54114941633a11a7277b5_image.png\\" alt=\\"image.png\\" /></p>\n<p>而且连传统的机房的钱也省了,据说这家企业全部产品转向云原生数据库了以后,把公司的原来的机房改造成了一个健身房。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/c2b83d3bee2549ed9ba9e9fce1a03286_image.png\\" alt=\\"image.png\\" /></p>\n<p>刚好这几年,终端工具也逐渐多了起来,像 XSehll、MobaXterm 等工具,可以直接通过这种工具去连接到云端,我甚至有点怀念我以前在小黑空调房里面调试数据库的日子了。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/882db86967ea4d8a992c7a634f1e6b5b_image.png\\" alt=\\"image.png\\" /></p>\n<p>方便不说,而且种类是真的齐全,如果想要关系型数据库,可以选择 Amazon RDS、Amazon Aurora,如果想选择缓存,可以选择 Amazon Elasticache、Amazon MemoryDB for Redis,想用文档型数据库,有Amazon DocumentDB,想尝试图数据库,可以选择 Amazon Neptune,甚至是非关系型数据库,有 Amazon DynamoDB,可以说是只有你用不到,没有亚马逊云科技做不到。</p>\n<h4><a id=\\"2_32\\"></a><strong>这2年,云原生数据库的卷</strong></h4>\\n<p>这两年,我也逐渐迈入云原生的步伐,不仅仅是因为各大厂商都开始发布自己的云原生的产品,越来越卷了,更重要的是,随着人工智能和大数据的普及,云原生才是真正的未来。我们之前使用的云数据库其实本质上是属于云计算领域,云计算应用程序通常是在内部使用传统基础设施开发的,并且经过调整后可以在云中远程访问,简单理解就是我在地面上通过远程软件去链接大气层的云软件,实质上还是部分在云上。接下来我来讲讲为啥我要完全上云?</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/cd57bcae31e94a3388658c7ebeceaa9a_image.png\\" alt=\\"image.png\\" /></p>\n<p>首先从是使用角度,云计算应用程序通常需要手动升级,比如说我要升级数据库的或者是服务器的,通常是需要先关闭再升级再打开这么几个步骤,从而会导致应用程序中断和关闭,而我在使用云原生数据库的时候是感受到了云原生数据库的友好,他是具备高度可扩展性,可以对集群规模进行实时调整,而不会对整个应用程序造成干扰。意味着我可以无感升级或者降配。<br />\\n接着我感触更深的就是价格,毕竟我们上云就是为了降低成本,从以前的自建机房到后面的云数据库,都在进一步降低成本,或者说是把成本转嫁到其他厂商身上,我们把机房搭建、服务器运行、服务器维护、软件安装等一系列成本转嫁到了亚马逊云科技等一众厂商身上,我们只需要付小部分钱就可以享受到了更优越的服务。<br />\\n亚马逊云科技的云原生应用程序不需要任何硬件或软件上的投资,因为它们是在云上进行的,可以灵活的利用云的弹性优势,因此使用起来相对便宜,这对于中小型企业来说简直是福音。</p>\n<h4><a id=\\"Amazon_DocumentDB__41\\"></a><strong>私货:Amazon DocumentDB 的使用体验</strong></h4>\\n<p>顺带说一下最近公司转型云原生数据库使用最频繁的一款产品吧,那就是Amazon DocumentDB。他是一款兼容 MongoDB 的数据库产品,由于公司在转型期间所做的一些业务拓展,对于海量的 json 数据的处理有性能与成本方面的考量。<br />\\n我们 MongoDB 是一款文档型数据库,他使用的是 json 格式的数据,与传统的关系型数据库不同。在以前,如果想要支持高并发的请求,通常我需要搭建多台服务器组成一个集群,而 Amazon DocumentDB 通过独立扩展计算和存储,支持每秒数以百万计文档的读取请求,就问各位老铁,这个功能六不六。<br />\\n我们公司的评论是使用 MongoDB 来存储的,按照以前方式的部署,一旦服务器出现了问题,不仅仅会导致评论这个功能出现问题,一不小心还会导致整个系统宕机,而 Amazon DocumentDB 的一个功能给了我很大帮助,那就是自动化硬件预置、修补,我至此就再也没有担心过稳定性的问题了,而且他还可以通过自动复制、连续备份和严格的网络隔离实现 99.999999999% 的持久性,数据的稳定性保障让我很放心。<br />\\n从 MongoDB 迁移到 Amazon DocumentDB也很简单,借助另一个服务Amazon DMS 就可以啦。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/3bc3ec00b9a541bd8b204d7d9f5ec87a_image.png\\" alt=\\"image.png\\" /></p>\n<p>总的来说,这一轮体验下来的感受还不错,性能方面目前是比 MongoDB 集群部署的性能还要再高一点,估计都替老板省下了不少钱。</p>\n<h4><a id=\\"_50\\"></a><strong>总结</strong></h4>\\n<p>35岁 CTO 的一句话给我的感触实在是太深了,回想起我刚入职使用的技术和现在使用的技术,简直是千差万别,需求在不断的变难,而我们也在不断进步,相信在未来,更优秀的云原生数据可以有更广泛更多的运用,而不是仅仅只是停留在开发者的层面。</p>\n"}
目录
亚马逊云科技解决方案 基于行业客户应用场景及技术领域的解决方案
联系亚马逊云科技专家
亚马逊云科技解决方案
基于行业客户应用场景及技术领域的解决方案
联系专家
0
目录
关闭