|
|
# 064 | 以MongoDB为例，看基础架构类产品创业
|
|
|
|
|
|
**MongoDB的产品是文档数据库，可以归类于基础架构类的创业公司。这类公司的特点是，产品本身不产生价值，使用其产品做业务和应用的第三方使用者产生价值并给他们付费。**
|
|
|
|
|
|
基础架构类的软件有很多，比如微软的Windows、Oracle的数据库，再比如整个Hadoop生态圈。
|
|
|
|
|
|
近些年来，因为大数据的蓬勃发展，以Hadoop生态圈为代表的开源基础架构非常火爆。几乎每个Hadoop的拳头产品背后都有一家或者几家创业公司，比如说Hadoop的发行商就有Cloudera、Hortonworks以及MapR，Spark的背后则是DataBricks。
|
|
|
|
|
|
这些公司成长于开源环境下，发展于开源环境下。和以前的闭源产品比起来，近些年来的基础架构类创业产品基本上都需要开放源代码，或者至少部分开放源代码。
|
|
|
|
|
|
总结一下基础架构类产品的显著特点，就是：
|
|
|
|
|
|
1. 产品本身不直接产生价值，被使用以后才产生价值；
|
|
|
2. 产品往往只有被大量用户使用以后，才能够盈利，未普及开来的产品基本上不可能赚钱；
|
|
|
3. 这个市场赢者和输者之间的差距很大，第一和第二所能赚到的钱差距非常大；
|
|
|
4. 通常来说这是创业的红海，因此需要创业公司不仅有很强的系统开发能力，更要有很厉害的市场公关能力。
|
|
|
|
|
|
MongoDB出来之前，数据库市场主要有两类产品。第一类是传统意义上的关系数据库。这类数据库的特点是数据模型死板、产品难用，但是产品性能、稳定性和安全性都比较高，而且此类产品通常很贵。第二类是新起来的NoSQL。NoSQL有不少优点，但是最大的问题是写应用的人会觉得很难用。
|
|
|
|
|
|
**MongoDB作为一个文档数据库，公司开发时在策略上做了几个很重要的决定。具体来讲，首先是把绝大部分注意力都用在提高易用性上，其次是把大量的广告和宣传费用都投入到社区的建设中去。**
|
|
|
|
|
|
这两种策略的好处非常明显，首先MongoDB这个数据库上手快，非常好用，对客户的支持也好。用别的产品得学一个月，用MongoDB一天就够了。如果我是用户，我也喜欢啊。其次，社区在MongoDB的支持下日益壮大。作为工具类产品，用户是开发者，开发者社区不壮大，不会有更多的人来用的。
|
|
|
|
|
|
**MongoDB在这两方面做得都非常成功。那么一个用户接受度那么高的产品，为什么最后商业化的时候，盈利却不好呢？这就要说到面子和里子的问题了。** 好用是一个产品的面子，产品是否成熟、稳定、 安全，能够应对大规模的并发，不丢数据，不会给出错误的结果，不会突然死机等则是里子的问题。
|
|
|
|
|
|
最后上线的产品，必须能够真正稳定高效地把系统跑起来。MongoDB的开发，对用户体验重视到了极致，但是对于产品的基本功能，似乎没花太多力气。MongoDB BUG满天飞，2017年的安全问题更是让无数人的数据被黑客删除。所以用户通常是上了MongoDB的船，等到没办法继续用下去了，又下了船。这可以说是MongoDB的巨大悲哀。
|
|
|
|
|
|
MongoDB最初吸引了很多大客户，那么时至今日，这些大客户去了哪里呢？很多都跑回去用关系数据库了。**一个好用但是不可靠的产品，比起一个可靠但不好用的产品，哪个对用户更有吸引力？这个问题，应该不难回答。**
|
|
|
|
|
|
**那么，我们从MongoDB这里学到了些什么呢？**
|
|
|
|
|
|
**做基础架构类产品，首先也是最根本的一点，就是可靠。** 产品不可靠，即使用户能够一时上了船，也不能保证一世都在这个船上。MongoDB的使用者里颇有几个大客户，但是它们却都离开了。产品的可靠性，对于一个产品的长远发展来说，非常非常得重要。
|
|
|
|
|
|
**其次，从用户体验的各方面来说，MongoDB确实可以打150分，远远超过满分。** 如果我能够一天学会，为什么非要用一个月去学其他的东西呢？为什么其他公司能够做出可靠的产品，却做不出好用的东西呢？这同样是这些“其他公司”需要思考的。
|
|
|
|
|
|
而作为创业者，一旦进入基础架构的创业行列，前面就不是一马平川了。公司的程序员资源都是有限的，MongoDB是，其他公司也是。**作为创业公司，如何在人力资源有限的情况下去平衡可靠性和可用性，是一个非常值得思考的问题。**
|
|
|
|
|
|
为什么这样说呢？不可用，就没有人愿意用；不可靠，就没有人能够用下去。但是创业公司的资源就这么多，二选一也不现实，面面俱到更不现实，怎么办？在优先级的安排上，这其实是蛮有挑战的一件事。
|
|
|
|
|
|
我们肯定不能像MongoDB那样弄出安全事件，安全问题在哪里都是高优先级的事。做基础架构如果存在安全问题，是没有人敢用的。但是，比如说是不是需要支持大量的并发、要不要做到多数据中心运行等等，我想有很多东西是可以进行取舍的。
|
|
|
|
|
|
**取舍的标准同样很复杂，我也只能凭借个人的开发经验说几句。**
|
|
|
|
|
|
首先，应该确定使用人群。如果使用人群不需要大规模数据处理，或者不立即需要，那么做大规模并发相关的功能无疑是早了一点。
|
|
|
|
|
|
其次，应该确定可用性的痛点在哪里，不需要面面俱到，但是最重要的可用性流程都需要走一遍。很多东西只要大部分人觉得很好用，最后10%的人群自己有很强的动手能力就可以了。不需要像MongoDB那样“可用性好到极致，可靠性却成问题”。
|
|
|
|
|
|
最后，我觉得“吹嘘”肯定是会出问题的。MongoDB在宣传上花了很大力气，却在产品质量仍然存在问题的情况下，就给用户设置了很高的预期。很多时候对于开源产品，如果实事求是地告诉用户东西还不错，但是没完工，大家心里有数以后，对产品的预期和要求就不会过高。**过度宣传，往往是基础架构类产品由盛转衰的很重要的因素。**
|
|
|
|
|
|
**但无论如何，MongoDB都是一个瑕不掩瑜的产品。** 这个产品至今依然有无数多的使用者。当然，很多人现在主要是把它作为原型系统在用，等产品真的上线以后就换掉。因此，MongoDB如果希望成为一个可靠、有稳定营收，在世界范围内真正有影响力的产品，现在是时候静下来好好提高产品的可靠性了。
|
|
|
|
|
|
**如果要做基础架构类的创业产品，可靠性和可用性的兼顾，是每个创业者都需要思考和解决的问题。**
|
|
|
|