Rockset用户因OpenAI收购而陷入困境:现在怎么办?

智能真的很好说 2024-08-31 14:35:50
意外迁移不仅会威胁您的业务,还会给您的团队带来巨大压力。 2024 年 6 月,Rockset 用户收到了一些压力很大的消息: OpenAI 已收购该公司,其平台的现有用户有 90 天的时间寻找另一个解决方案。在规划整个流程时评估新的解决方案、集成它们以及管理数据迁移已经足够具有挑战性了。 有人认为最好使用开源解决方案,尽管这些解决方案可能会变成闭源、失去维护者或由于其他原因不可行。有些人甚至主张采用最站不住脚的方法:单干、重新发明轮子、自己建造。但只有 90 天的时间,这几乎是不可能的。 工程师和技术团队必须具有弹性、敏捷性和适应性,就像他们构建的解决方案一样。尽管如此,领导者和管理者还必须考虑被迫做出重大的、意想不到的转向另一种解决方案的人性化一面。 现在是夏天(至少在北半球)——家庭度假、婚礼、聚会、烧烤的季节。但现在,至少对于当前的 Rockset 用户来说,不同的季节发生了突然的、意想不到的变化。不仅温度升高,压力也升高。 那么,这样的迁移应该如何处理呢?实施策略、测试、验证并确保流程安全都很重要。但是,让我们放眼全局,考虑如何以支持您的业务和人才的方式处理迁移。 动作要敏捷,不要着急九十天的时间并不长,但足以评估几种解决方案并进行试用过程。业务和工程领导者需要与多个解决方案进行初步汇总,看看哪些解决方案值得更深入地尝试。在这种情况下,敏捷意味着灵活并根据组织可用的解决方案进行调整。这意味着给自己时间来了解过渡过程并制定策略。这与下一点有关——知道何时持有、何时弃牌。 知道何时持有和何时折叠您之前的整合效果如何?是否有改进的空间——也许有其他解决方案的新机会?您是否需要保留所有数据并将其迁移到新的解决方案中?在这种情况下,“持有”意味着试图让一切尽可能接近原来的样子——但这可能是不可能的。 “弃牌”并不意味着放弃——看看你抽到的下一手牌是否更适合。 从数据角度来看,如果您的保留窗口已经很短或者不定期查询所有数据,则可能只需要迁移其中部分数据。或者您可以将大部分数据移至存储桶中并稍后再处理。如果是的话,折叠也没关系。同时,如果您有关键任务数据,则需要保留 ,并且需要在试验/POC 流程中确定。 从功能的角度来看,Rockset 具有一系列独特的功能(也有一些弱点)。哪些功能是您的集成绝对必须具备的?哪些是你在短期内可以没有却可以生活的必备品?哪些不是必需的?例如,Rockset 是一种罕见的将 OLAP 功能与可变数据相结合的解决方案。然而,许多涉及实时分析和日志数据的用例不需要可变性。不变性通常更适合日志数据。 哪些功能和数据是您必须保留的,哪些是您可以没有的? 一切以人为本这就是人员的重要性——不仅仅是您的人员,还有那些为您正在考虑的解决方案的供应商工作的人员。您需要了解解决方案的可行性,快速启动并运行,然后将其集成到您的业务中。需要帮助没关系。您可能需要所有可以获得的帮助。概念试验/验证过程是一个快速启动和运行的机会,通常是免费的,并得到另一个深刻了解其产品工作原理的组织的支持。 如果您需要迁移数据,下一个解决方案的成功团队应该能够提供支持。这同样适用于设置不同的数据源、确保摄取的数据具有您期望的形态、优化用例的查询等等。 对于这种快速转型来说,优秀的人才和支持是绝对必要的。当然,尽可能与当前解决方案的人员合作。例如,Rockset 已承诺支持其现有客户进行转型。 不要单打独斗您是否拥有一支超级明星工程师团队,可以在几个月内建立实时分析数据库的 MVP?即使你这样做,也要抵制住 DIY 的诱惑。至少在短期内,涉及的风险太大。这不仅仅是构建 MVP,还涉及开发成可行解决方案所需的优化和一致性,即按预期工作的完美解决方案。试图在如此压缩的时间范围内构建 DIY 解决方案是仓促而非敏捷的一个例子。 最重要的是,尝试 DIY 可能会转移您需要构建的产品的资源。 DIY 解决方案可以是长期计划的一部分,但不能是令人惊讶的 90 天计划。 开源并不是唯一的答案在这样的收购之后,一个典型的反应是开源就是答案。原因是开源将始终保持可用,并且您不必处理意外收购。开源通常是一个很好的解决方案,Apache 软件基金会等组织正在构建 Flink、Pinot 和 Druid 等强大的工具,以支持实时分析用例。 然而,从短期来看,构建适合您的用例的开源解决方案会面临一些与 DIY 相同的挑战。即使是一个乐于回答您问题的强大开源社区,也不同于一个积极为您集成解决方案并赢得业务的客户成功团队。如果 Rockset 所做的事情很容易复制,那么它一开始就不会存在。客户将使用 RocksDB 或其他开源解决方案。闭源会产生成本,但价值会增加。具体来说,围绕可扩展性、可靠性和效率的复杂问题已经为您解决。 九十天的时间很短,所以要小心不要急于建造东西。是的,开源通常是一个很好的答案,但要现实地考虑您需要多少时间来建立解决方案,需要多少资源,以及它会偏离您的核心业务目标多少那条路线。 一种尺寸不一定适合所有情况Rockset 打造了一款独特的产品。 OpenAI 花费九位数购买它是有原因的,也是他们不希望竞争对手使用它的原因。它将 OLAP 与其他功能(例如聚合索引和可变数据)相结合。 寻找另一个非常接近的替代方案可能很诱人,但这又回到了知道何时持有和何时折叠。必须离开 Rockset(或使用其他解决方案面临相同问题)的企业已经面临损失。他们现在必须出乎意料地花费时间、精力和资源来寻找新的选择。 您不应该只评估一种解决方案,您甚至可能会发现您想要使用不止一种解决方案。例如,在短期内,这可能意味着使用提供强大实时分析功能的实时分析平台,然后将一些数据从该平台发送到机器学习应用程序的另一个解决方案中的关联表。从长远来看,这可能意味着结合多种闭源解决方案、开源解决方案,甚至一些 DIY。 保护您的业务和人才意外迁移不仅会威胁您的业务,还会给您的团队带来巨大压力。为了驾驭这一领域,您需要从您的团队、领导者和其他企业那里获得所有的人才,他们已经构建了适合您的用例的解决方案。对于 Rockset 用户来说,他们将无法再接触到 Rockset 构建的人才和独特的解决方案,这是一个巨大的损失。但还有很多其他解决方案,而且很可能有一个(甚至多个解决方案)可以为您解锁新的业务用例。
0 阅读:0

智能真的很好说

简介:感谢大家的关注