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

前言

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