CloudQuery 的过去、现在和未来发表时间:2024-01-02 16:03 CloudQuery (后续简称「CQ」)这个产品从设计/研发到现在,一晃已经 5 年多时间了,在不断的完善中,也积累了不少的社区/企业用户,我意识到,CQ 已经从一个 Idea 变成了公众软件,开始有它的使命、责任和价值主张。很多用户(客户)非常关注 CQ 的进展和规划,作为产品的第一负责人,来跟大家说说 CQ 的发展历程,对过去做个总结,对未来做个展望。 一、CQ 的诞生 2018 年公司刚成立不久,我们框定了数据库领域,先后尝试了数据库代理(Proxy)和复制迁移,开始做 Web SQL,即把 SQL 客户端运行在 Web 上,因为我坚信绝大部分不需要本地复杂计算的软件都需要迁移到 Web 上,这样才能融合到整个云背景中,或者可称之为 Cloudware。 Web SQL 最初的产品名称叫做 Daios(Database All In One Studio),目标是一个类似于 DBEaver 的 Cloudware,但做出来之后,发现市场对于这类纯客户端的反应并不大,以某位老大哥的话来讲,这是痒点,不是痛点。正好碰到上海一个客户需要针对数据库做细粒度、精确的审计,同时管理用户对数据库的各种操作以及动态脱敏,于是我们「误打误撞」地跑到了数据安全赛道。 产品搞了,第一个客户也落定了,但每个接触过 Daios 的人都不知道怎么念,拗口的名称极大得影响了产品的推广。考虑到这个产品的 Cloudware 设定,并且主要针对数据库查询类做安全产品,也考虑过叫 CloudSecureQuery,但为了便于称呼,最终定为 CloudQuery。 二、V1:艰难起步 在 CQ v1.0 时期,产品团队只有 3 个人,我们对于功能的规划是尽量「抓大放小」,即:
这个时期的产品虽然功能弱,但在技术上我们力求扩展性,坚持自研,并因此走了不少弯路,这是因为 CQ 的定位是一个门户类的平台产品,如果不关注技术,最终会被技术债吞噬。 一年多的探索下来,我们确定了一个数据库管控平台的几个核心技术点:
现在看来,这个版本功能其实远离了数据库核心,且体验「处处漏风」,但也服务了 20 多个客户,我也分析了为什么它会有市场。 三、为什么 CQ 可以? 任何一个能被认可的产品都是时代和环境的产物,这其中有 3 个关键因素影响了类 CQ 软件被接受并运用到实际数据生产中。 1、 Cloud 时代 就需要大量交互的功能软件来说,Web 体验远比不上桌面,但是大中小都在上云,上云之后最好的软件形态就是 Webware,这里 Web 就是个云端数据中心软件的 Agent,理论上拥有可以连接和整合企业IT设施的无限能力。对比于单薄的桌面,功能上享受到的收益大于体验上获得的收益,这对高效工作很重要,比如 SSO,Dashboard,再比如 Portal 等等。并且随着前端技术的发展和浏览器厂家的海量投入,体验也在快速跟上。 2、 数据崛起 随着互联网,特别是移动互联网的蔓延,世界的数据总量基本两年翻一番,这促成了数据相关的繁荣,比如存储、存取、转换、分析、安全、可视化等等,企事业开始接受对数据相关产品付费。数据对人们的生产生活影响越来越大,人们意识到,数据也应该像软硬件、网络设备那样被当作资产。上一代的企业 IT 资产通用保护装置「堡垒机」(或跳板机),主要用来保护主机和网络设备,无法有效&深入地对数据资产进行保护,当前堡垒机的不足推动了 DBA 和数据相关安全人员选择更为专业的数据管控类产品。 3、 信创支持 多年来,国际巨头几乎垄断了中国的数字化基础设施基础软硬件,这既包含数据库/大数据,也包含繁荣的生态配套,就此共生了大概40、50年时间。随着全球 IT 生态格局的演变,迫使中国必须要建立基于安全的 IT 底层架构和标准。近几年信创产业的大力发展,逐步解决了一些关键问题的 0 到 1,但在一些配套和优化上仍是缺失。信创数据库是刚需,那么配套的客户端、复制迁移、监控以及安全等等也是刚需,这是独属于中国中小软件公司的机会。 CQ 会顺着这个路径继续完善下去,CQ 可以,我相信很多数据安全类的软件云化也可以。 四、ToB 与社区版 曾经一个做堡垒机的大佬说「在企业市场打死我都不搞免费和开源,这很不商业」,因为付出和收益不对等。 这几年的 ToB 下场实践,我发现愿意付费、能付费对客户项目的成功是一件好事,这能在最大程度上保障业务需求的贴合和产品的稳定性。但对于软件公司来说,除了点对点地服务好客户,市场上的声音更是推动产品发展和前进的「燃料」。 为了获取更多市场对于 CQ 这类产品的反馈和需求,我决定尝试社区这条路径。但由于对知识产权保护缺乏信心,所以我暂时放弃开源(opensource),而是选择免费路线(freeware)。我们能坚定不移地搞社区的原因,也有几点:
社区是个融合了我对技术、产品和市场看法的创新实践,期望能够在现实环境下以产品公司的底色发展壮大的同时,还能够提供最广泛的客户价值。 五、V2:大重构 经过两年各式项目的增强,CQ 无论外在还是内在都已「千疮百孔」,已经无法进一步支撑客户需求,思考再三,决定进行大重构。从开始编写目标到第一个 V2 客户测试,足足花了 1 年多时间。而产品的变化主要来自三个方面: 1、定义的变迁 如果说 V1 的 CQ 是一个挂载了安全功能的简易数据库 Web 客户端,那么 V2 根据大量的客户沟通和实践,CQ 则被定义为「数据安全入口」。这个数据不仅指数据库的数据,也包括应用的数据、网络的数据、其他存储的数据等等。如果把数据仓比作一个园区,那么 CQ 就是唯一的一道门,且进出的路上有大量的安全配置。 2、功能扩展 功能上主要围绕两个面展开,一个是对数据库种类(包括 nosql)进行大量支持。截至当前,CQ V2 系列已经完整支持 28 种国内外数据库。尤其是大数据库方面如 hive/vertica,已经成为很多企业数据开发人员的首选工具。同时我们也会在 V2 周期内实现主流国产数据库覆盖,既包括 OceanBase、GaussDB、达梦等 TP 数据库,也包括 TiDB、StarRocks、DWS 等 AP 数据库。 另外一个是围绕安全三剑客“权限、脱敏、审计”进行完善,其功能对标国内主流安全厂家的产品,其中:
在这个版本,我们已经有意识有计划地根据用户反馈改进操作体验,主要集中在导出、执行日志、结果展示、脱敏、审计展示等方面。 3、技术改进 能让我们顺利进行功能深度改造的核心是技术的大重构,我们几乎重写了底层所有的关键代码,主要包括以下方面:
六、V3 展望 虽然我们是「偶然」拐到数据安全领域的,但我们也发现,在当前阶段,数据安全还没有很好地被分析和对待。很大一个原因是安全行业的成功者基本都来自于网络安全领域,如果依旧用同样的技术手段、产品模式甚至商业模式去解决新的数据问题,就很难成功。 数据是什么?是业务承载,所以数据安全刨开技术问题,很大程度上是个业务问题。这意味着数据安全的解决方案要关注更多“层”面,用我的一张PPT阐明下观点: 或者说,数据安全需要以全栈或者平台的思路去解决,需要干一些「脏活累活」(目前正火的 AI 正好可派上用场) ,需要处理好通用性和可扩展性的平衡,这也是 CQ 在 V3 周期的主体思路。我们将会把 CQ 建设成为一个“数据安全平台”,沿数据生命周期,对各式数据进行高效接入和全面保护。 站在产品角度,安全虽然能合法合规,但经常会降低工作效率,为提升使用者的获得感,必须要通过提升效率来对冲安全带来的消耗,即不仅安全,还好用。围绕这个核心目标,我们将会继续做以下工作: 除了「入口」,我们将开发更多子产品,使之遍布在“园区”各处,更全面地满足各种场景,形成 「CloudQuery 产品家族」,即 1+N 体系。当前明确的主要有:
后续还可能有 API 安全网关、数据分级分类、数据加密等等。 之前的版本,我们一直在「赶功能」,对于用户体验这一块有很多的负债。这个版本,我们将针对一些典型问题进行持续清算,主要包括:
3、持续进化 CQ 将会沿着图尔兹的产品战略持续进化,持续带给用户更多的价值:
4、走出去 社区运营的过程中,陆续有人希望我们推出英文版,当前英化已经搞定,这个季度我们会在国内外发布英文版。另外从 2024 年开始,将正式出海推广,并尝试支持更多的语言,比如西班牙语、日语等。希望通过跟国外同类产品同台竞技,为用户带来更多的可能性。 在产品更完善的同时,我们能坚守的承诺就是社区只会越来越开放,一些企业级功能会逐渐下放,开放文档会更细节。此外,我们也会吸纳外部公司/开发者,以源代码共享的模式共建一些扩展功能模块。 七、花开叶落,初心不改 最初搞这个产品时,是希望安全类的产品除了合规,也能好用,更立体地解决用户对数据的关切。但在行业呆久了问题变成另外一个:做软件尤其是技术软件怎么在当前环境下,保证生存发展的同时还能坚持创新?这是软件创业者共同面对的难题。 软件在国内 IT 史里除了零散的喝彩,从来没长时间雄起过,甚至在向“人天”和准外包剧烈地倒退。社会要进一步发展(提升效率),各行各业细分的高质量软件必不可少,甚至比 AI/大数据重要的多,而搞好软件的关键是人才及创新精神。 人才需要利润支撑,在温饱都不普遍的情形下如何获取?创新如果缺乏法律和文化的坚实保护,又该如何有“技巧”地落实?这需要坚定的战略,也需要灵巧的步伐。走了 5 年多,我们还是要坚决的突破,最大化地连接技术、云、互联网和社区等要素,走出一条可复制的软件路来。 |