006 | 以MongoDB为例,看基础架构类产品创业

006 | 以MongoDB为例,看基础架构类产品创业

朗读人:秭明    07′06′′ | 3.25M

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 如果希望成为一个可靠、有稳定营收,在世界范围内真正有影响力的产品,现在是时候静下来好好提高产品的可靠性了。

如果要做基础架构类的创业产品,可靠性和可用性的兼顾,是每个创业者都需要思考和解决的问题。

版权归极客邦科技所有,未经许可不得转载

精选留言

  • 参悟
    可靠的产品本身就比较复杂,同样对应用有着较高的要求,而简单的东西在复杂的场景就会变得不可靠。这也是为什么可靠的产品,比如oracle,在大型复杂的应用下,需要专业的DBA的原因。
    2018-08-09
  • Maiza
    可靠的产品的逻辑通常是从下往上推,结果就是底层很扎实,但是由于没有把底层的复杂性都包起来。用户就只能对着一堆的平台专有的名词发愣。

    好用的产品通常是从上往下推,过于简单的上层设计导致底层的复杂性无处安身,各种无解的事情都跑出来了,就bug满天飞了。

    个人愚见
    2018-10-21
  • yungoo
    可用性和易用性是什么关系?
    2018-06-09