前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >ToB 创业公司的开源之路 - KubeSphere

ToB 创业公司的开源之路 - KubeSphere

原创
作者头像
陈少文
修改2023-07-03 10:17:17
1.1K0
修改2023-07-03 10:17:17
举报
文章被收录于专栏:陈少文

1. 以开源为核心的商业模式

开源的魅力之一在于其包容性。它能接受怀揣各种意图的人,无论是执着技术的的工程师,还是心怀鬼胎的商人,亦或是热心公益的志愿者,甚至茶余饭后的看客,都能在这里碰撞、交融,形成一股力量。

围绕开源做商业,应该被允许和接受。开源和商业是互相成就的关系。最新的开源报告显示,在 GitHub 上,开发者工作日比周末明显活跃。这说明全职的开源开发者正在增加,开源正在给开发者带来收入。这些收入可能来自某个基金会、某家商业公司、某些赞助商,支持着开发者全身心地投入开源。

基于开源的商业模式需要思考几个问题。

开源能给产品带来什么?开源不仅仅是将源码托管在 GitHub,而是需要管理和运营社区,借助社区的力量积攒人气、扩大影响力。

为什么用户要使用这个产品?开源并不意味着降低了对产品的要求,产品的领先性是开源成功的关键因素之一。打磨一个好的产品并不是一件容易的事。需要对领域有深入理解,对用户习惯有所把握,才能通过产品填补沟壑,实现价值的传导。

能为这个产品提供怎样的服务?开源是免费的,但服务是收费的。如果没有持续的收入,商业是难以稳定投入开源的。这种收入通常不直接来源于开源,而是以开源为基础进行衍生。开源软件可以免费使用,但如果需使用培训、增强安全、适配场景、修复问题、咨询方案、定制开发、分发应用等,就有商业机会。

2. KubeSphere 的开源之路

自 2018 年 04 月正式立项, KubeSphere 同年 07 月 发布 1.0, 2019 年 04 月 发布 2.0, 2020 年 08 月 发布 3.0。

连续三年,每年千万级别的研发投入,青云对 KubeSphere 期待很大,称之为青云 2.0,面向云原生的新生代。提供 HC、增加人力是上层对下层最直接的支持方式。最近几年,KubeSphere 团队来来往往的人很多,但总体人数一直是保持增长的。值得一说的是,KubeSphere 开始渗透到青云的其他团队,周边的团队在以 KubeSphere 为模板加速融入云原生。

而 KubeSphere 交出的答卷是:

  • 主仓库 kubesphere/kubesphere 超 5.1K star
  • 安装工具 ks-installer 下载量达 1M+
  • 中文论坛/Slack/微信群均达到了 1~2 K 人

从数据上看,KubeSphere 完成了原始积累,拿到了云原生的门票。下面从几个不同的方面对其进行讨论。

2.1 产品研发

产品研发的策略是,先堆积功能吸引用户,再拆分做可插拔的架构。

纯 ToB 的公司,最难的是找到愿意尝鲜的用户。如果没有用户持续地使用、反馈,是开发不出好产品的。因此,从一开始 KubeSphere 就在追赶功能,不断地集成组件,用来吸引更多用户。1.0 管理原生 Kubernetes 基础对象、DevOps、Prometheus 监控、应用商店;2.0 Istio、日志;3.0 多集群、网络管理。

但是,仅集成组件积攒人气是不够的。不能带来收入,向上面对老板的压力大,向下回报少离职率高。幸运的是青云属于 IaaS 厂商,有很多的组件可以对接到云原生生态,比如存储、负载均衡器、云主机等。通过提供全独立的 Kubernetes + KubeSphere 服务,不仅带动了青云 IaaS 及周边产品的销售,还给 KubeSphere 打入用户心智带来了可能。

与此同时,研发有机会接触用户真实的使用场景,反哺产品的设计。

在未来的 4.0 架构中,预期是以 KubeSphere 为核心架构,以应用商店作为分发渠道,构建一个类似 IOS 的生态。与之配套的还有一个服务销售系统 kubesphere.cloud,提供工单、定制化开发等服务。

至此,就是一个很常见的架构模式了。我之前参与过的一个项目也是这个想法。我也写过一些关于平台的思考,可以参考《领域输出才是 PaaS 的核心竞争力》

下面是引用的一张图:

KubeSphere 的平台目标对应到 PaaS 层。但在 KubeSphere 设计之初,更像是以 SaaS 的定位进行开发的,并没有提供公共的运行时,也没有抽象公共的 SDK 库。这其实对应着 aPaaS 和 iPaaS 两部分。

首先,需要下沉基础的功能,比如统一的错误码、日志输出方式、鉴权控制、前端脚手架等,这其实就是一套开发框架。KubeSphere 以微服务的形式提供核心的用户、权限、应用商店等功能。

然后,基于开发框架,对 DevOps、微服务、日志、网络管理等组件进行重构,上线到应用商店。但这不会是一个短暂的过程,主要有两方面的原因。

  1. 架构解耦有难度

如果你看过 KubeSphere 源码就会发现,这些组件都是通过功能开关控制,而且相互之间具有依赖关系。KubeSphere 在架构演进、协作模式上在学习 Kubernetes ,忽略了其面向应用的定位,对开发者并不友好。

  1. 风格惯性很强

下面是 KubeSphere 1.0 的 UI:

和 3.0 很像。风格一旦形成,是很难改变的,这就是产品的基因。SaaS 拆分为 PaaS/SaaS 也会面临很大挑战。

代码拆分可能只是其中很小一部分,Monorepo 改成 Polyrepo 不会很耗时,风险在于用户习惯、文档、FAQ 、博客等前期的积累都会失效,之前参与者的经验都需要更新。参考 SkyWalking 的发展路线,其也经历了数次重构,从原型验证、产品化,到社区化、丰富功能,最后是性能优化。但能被津津乐道,也正说明其稀有,KubeSphere 任重而道远。

2.2 发展阶段

这里我想引用一下鸿沟理论,如下图:

CNCF 孵化项目的三个阶段对应着鸿沟理论中的三个群体:

  • Sandbox, 沙箱, 创新者
  • Incubating, 孵化, 早期采纳者
  • Graduated, 毕业,早期大众

KubeSphere 已经完成了从 0 到 1, 证明了其市场存在的空间,同时培养了一批粉丝。我认为,KubeSphere 目前进入了早期采纳者的视野,正在向上爬升。

在不同的阶段,需要有不同的侧重点。长期应该有战略,遇事有方向;短期应该有战术,实践有方法。这样积小胜才有大胜。

在项目的初期,研发更加重要,早期打好根基,用心开发产品,证明其价值。

目前 KubeSphere 在功能上基本已经补齐,处于走量推广的阶段,重视运营、拉新、留存、增量市场。主要的目标是规模化地铺开,积极响应反馈,维护好用户群体。

在后期大规模应用时,会暴露很多的问题。用户对产品更加挑剔,需要再次回归到研发,将上一个阶段的反馈改进到产品中,产品也因此从早期采纳者步入早期大众的视野。

2.3 服务方式

一共有三种服务方式,公有云、私有云、纯服务。

借助青云的公有云 IaaS,KubeSphere 提供全独立的 Kubernetes 服务 QingCloud KubeSphere Engine(简称 QKE)。用户只需要在青云的控制台选择 QKE ,即可获取基于青云 IaaS、云硬盘、负载均衡器的 Kubernetes 集群。同时,还提供免费的集群工单服务。除此,业界另外两种服务方式,半托管和全托管的 Kubernetes 集群服务,技术上更具挑战,目前并不适合 KubeSphere 。

在私有云市场上,结合青云公、私有云一致的技术架构,KubeSphere 能提供自 IaaS 到容器的全套解决方案。私有云中标后的分成,是 KubeSphere 的主要收入来源。

纯服务是更大的梦想,这也是我觉得有意思的地方。从 OpenPitrix 到 kubesphere.cloud, 青云似乎总能找到好主意。OpenPitrix 意在统一运行时,实现应用的全生命周期管理,无论是部署在阿里云、亚马逊云、VMware,还是 Kubernetes。而 kubesphere.cloud 将服务从厂商剥离开,单独进行销售,同时允许开源社区的其他参与者作为卖家参与。

目前的服务方式依靠的是工单值班人员、售前、售后、研发,以人工为主,往往客户会击穿中间环节,直达研发。这并不是一种 Scalable 方式,服务卖得越多,团队越难协作,我认为这是急需解决的问题之一。

3. 一些关于组织和经营策略的思考

3.1 创新至关重要

创业不是将别人的蛋糕抢到自己的碗里,而是要将蛋糕做大。

创业时,不要选择存量市场,而应该选择增量市场。“Cloud Native is eating the world”, Kubernetes 就是一个增量的市场。云原生会接管运维基础设施、研发流程,存在巨大的市场机会和发展空间。

KubeSphere 选择了一个好的赛道。Kubernetes、云原生、Istio 能吸引用户和资本的眼球。KubeSphere 选择了一个大家嫌不够技术含量的 Dashboard 作为切入点,避开了竞争,又抓住了用户的痛点,还提供了很大的想象空间。

不要走别人走过的路,否则你永远只能跟随。

3.2 注重内部知识流动

创业公司的人才梯度落差很大,内部知识的流动非常重要。

创业公司的回报可能和大公司很不一样,创业公司会将成本集中到极少数人身上。虽然保证了极少数人不流失,但是高离职率会带来很多潜在的问题,也明显降低了团队整体的效率。

钱可以解决一部分问题,但快速成长的机会、开心的工作环境、行业的发展前景也是可以留住人心的。

注重内部知识的流动可以避免人员单点、提升人员能力、减少人员离职。创业公司通常没有实力组建自己的学院,更多需要内部形成一种机制和氛围。

内部不仅仅指的是同一个团队,其实也包括售前、售后等其他合作者,这就需要发挥制度创新,将利益相关者聚合起来。

3.3 靠机制而不是靠人

人的服务是不利于规模化的,人的决策蕴含较大风险,人的流失也意味着业务的风险。我们要将经验、思考都转换为可见的东西。

处理业务问题时,要学会记录,形成解决方案,进而行文至文档,编写为脚本等自动化工具,输出为产品,转化为自助服务。

我们需要的是一套能替代人的工作流。任何人都可以启动,执行,得到一致的结果。

另一方面,培养员工也需要形成一套制度,让实习生也可以成为主力,就不会担心人员流失了。

3.4 意愿大于技巧

方向是错的,不要紧,只要有人愿意不断地纠正,起步反而是最难的。

考虑得很全并不是一件很好的事,事倍而功半。这种考虑局限于现有的经验和当前的环境,一旦经验增长、环境发生变化,以前的结论就会被推翻。

kubekey 是一个很好的例子,运维愿意学 Go 搞研发,那么就随他干。现在 kubekey 也是 KubeSphere 核心产品矩阵之一了。

有意愿做,那么就小步快跑地做,不要犹豫。很多时候,退一步就会节节败退; 反过来抗住了就会打开一片新的天空。

3.5 分区办公要根据职责划分

分区办公指的是一个团队在物理上被隔离在不同的地方。一个团队被分割在不同城市,北京、上海、武汉、成都,甚至有的在家里,看似很 nice,非常 global,但如果架构得不好,人员流失率会很高。

一个团队构成一个系统架构。一个团队分成很多个小组,一个组有一个具体的目标,一个小组共同为这个目标而努力。

一个组应该被分配到一个区域,比如微服务在武汉,多集群在成都,DevOps 在北京。而不能一个组三个人分布到三个地区,这样会造成极高的沟通成本。即使现在远程办公在家被逐步接受,但这种没有建立感情的小组人员极易流失,而且不会替项目考虑太多,说走就走。

根据职责划分区域是比较合适的一种方式。一个分区的成员可以充分的沟通,不同分区之间相互协作,构成一个完整的团队。

4. 参考

原文链接 https://www.chenshaowen.com/blog/the-road-to-open-source-for-tob.html

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 以开源为核心的商业模式
  • 2. KubeSphere 的开源之路
    • 2.1 产品研发
      • 2.2 发展阶段
        • 2.3 服务方式
        • 3. 一些关于组织和经营策略的思考
          • 3.1 创新至关重要
            • 3.2 注重内部知识流动
              • 3.3 靠机制而不是靠人
                • 3.4 意愿大于技巧
                  • 3.5 分区办公要根据职责划分
                  • 4. 参考
                  相关产品与服务
                  容器服务
                  腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
                  领券
                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档