除了应用场景的限制外，团队的技术能力也是决定组织是否使用serverless database的很重要的因素。可能你会看到某些互联网企业在这方面用得很溜，你也想去学他们，不过如果你自己的技术能力不足，简单的模仿很可能会编程东施效颦。如果你的核心业务依赖于数据库容器云，而当容器云出现故障的时候，你无法解决这些故障，那么后果如何，是可以想象的见的。
在讨论这些问题之前，我们首先要来弄清楚你把数据库迁移到容器云而不选择云主机的原因。如果你仅仅是因为觉得容器比VM具有更小的开销（OVERLOAD），那么我建议你要再慎重考虑一下。适当节约IT资源是很合理的，不过目前的数据库服务器资源与数据库所承载的企业关键数据相比，并不算昂贵。如果你是为了百分之几的资源消耗差异而选择将数据库运行在容器里，那么就真的可以放弃这个想法了。
将数据库放在容器云里运行，其终极目的都是serverless database，让数据库这种IT基础设施变得很简单，这才是数据库上容器云的最合理的需求。2年多前，我写过一篇关于数据库上容器云的文章，其中对VM还是容器的选择用一张图示做了分析。这张图是我在medium上看到的，是谷歌云解决方案架构师本杰明.古德画的。觉得挺有道理，就抄了下来。
图片
第一个选项要回答你的数据库是不是k8s友好的。由于容器较物理机、虚拟机等环境是更容易出现故障的基础设施，因此故障自动转移事件的发生可能性比传统托管或完全托管的数据库高。数据库中包含分片、故障转移选择、自动副本复制功能的数据库都是属于k8s友好的数据库，比如ElasticSearch，Cassandra或MongoDB等。而Mysql、Pg、Oracle等数据库则是非k8s友好的数据库。
对于非k8s友好的数据库，如果具有较好的k8s上的运行支撑，比如借助于一些Operator来实现数据自动复制/备份，故障自动转移等特性，并且组织能够提供足够的运维支撑，那么也是可以转回使用k8s这条线的。然后我们要回答下面的一个选项，就是数据库的工作负载是不是适合k8s，如果这个数据库是一个负载不高，并且随着应用上线后，负载增加不是很大（如果有较大的负载，可以通过横向扩展，而不是增加在一个独立的数据库上），那么这个工作负载就是k8s友好的，可以使用k8s。反之，如果这个数据库工作负载很大，或者存在十分高的高峰，或者随着上线时间推移，数据量增长很快，负载会越来越大，而且无法很好的横向扩展，那么这个工作负载是非K8S友好的。
然后进入第三个选项环节，你的工作负载能支撑多大的并发量，如果你可以完全控制并发量，让k8s能够承受合理的工作负载，那么你就放心的在k8s上跑你的数据库吧，否则还是让数据库跑在一个完全受控的环境下。
从上面的分析可以看出，判断数据库是否能上容器云，主要要考虑两方面的因素，一个是你的应用负载是否是可控的，数据库的规模与负载是否完全受控，不会因为业务发展和数据量的增长而导致数据库规模和负载不可控从而引发性能问题，这一点是数据库在容器中运行的最基本的条件。
第二个因素是数据库本身是否是容器友好的，其架构本身就不怕容器这种不够稳定的基础设施出现问题，如果你的数据库本身必须依赖于稳定的IT基础设施，那么你的数据库上容器云的前提是你的技术足够好，能够提供能力强大的operator，从而让数据库能够在容器云中免维护运行。
上面的问题只是回答了能不能在容器云中运行数据库而已，而要不要让的数据库在容器云中跑是另外一个问题了。我觉得在让自己的数据库上容器云之前有几个问题需要再思考一下。如果你觉得上容器云的最主要的目的是为了节约计算资源，那么我建议你立马放弃这个想法。对于绝大多数企业的几百个或者千把个数据库来说，上容器云节约的成本，还不够搞出一套靠谱的operator来。
如果你上容器云的目的是为了简化运维和运营，那么还是有点靠谱的。不过你也要考虑一下，你的应用是否能将数据库都控制在类似规模上，确保自动化运维能够很好的管理这些数据库，不需要进行额外的管理与优化。如果你的应用无法很好的控制数据库的规模，那么可能就会上云一时爽，爽后一世忙了。
另外一点要考虑的是，你的企业中是否有数十个甚至上百个规模相当，可以使用同样镜像模板的数据库，如果是这样，用容器云还是挺省事的。而如果你的每个数据库的参数都需要定制化，那么使用容器云和用虚拟机就没啥区别了。
最后要提醒的还是那个最初说的问题，你的IT能力是否能够驾驭好运行了成百上千个小型数据库的容器云，当云平台本身出问题的时候，你是否能够很快的解决这些问题。当数据库因为IT基础设施不够稳定而产生切换，丢失部分数据的时候，你的业务是否能够承受，也是你需要事先考虑好的问题。
