作为一家自托管 SaaS 备份服务企业，Keepit 计划从今年的 7 个应用开始，到 2028 年实现数百个不同 SaaS 应用的备份。为了深入了解这一计划，我们向其 CTO Jakob ?stergaard 提出了三个问题，以下是他的回答：
Blocks & Files：Keepit 能否谈谈其 SaaS 应用连接器的生产理念与 HYCU (基于 R-Cloud) 有何不同？
Jakob ?stergaard：虽然我们对 HYCU 在 RCloud 中添加工作负载支持的具体机制了解有限，但我们可以分享 Keepit 是如何处理这个问题的。
在早期，所有公司都采用相同的起步方式，使用传统软件开发方法为每个工作负载实现直接支持，即在他们选择的通用编程语言中一行一行地编写代码。我们认为 HYCU、Keepit 和业内其他公司在这方面的起点都很相似。
HYCU 在 2023 年宣布将使用生成式 AI 来支持新的工作负载。从工程角度来看，这是一个有趣的想法。如果能够实现，这将可能大大提升供应商添加新工作负载的效率。
然而，支持新工作负载的现实挑战远不止于（可能由 AI 支持的）API 交互实现。供应商需要理解工作负载的生态系统，更重要的是要理解工作负载的用户。
以备份 Miro 为例，仅仅与 Miro API 交互只是解决方案中的一小部分。要构建一个真正满足客户需求的解决方案，需要了解企业如何使用 Miro。这个问题以及许多同样复杂的考虑因素，目前都难以通过 AI 轻易解决，因此虽然这是个有趣的想法，但现实情况更为复杂。
在 Keepit，我们一直专注于改进工作负载创建的"开发人员工程学"，以便将来能够让第二方或第三方开发新的工作负载支持。我们的重点是消除创建复杂代码的需求，而不是自动化其创建过程。
为了说明 Keepit 采用的方法，最好将其与 SQL 进行比较。开发者编写一个相对简单的 SQL 语句并发送到数据库服务器，然后 SQL 服务器中的高级查询规划器会设计一个实际的可执行计划（可以说是一段软件），用于产生原始 SQL 语句中描述的结果。
这种方法的好处是需要维护的代码量（示例中的"SQL 语句"）很少，而且执行引擎（示例中的"查询规划器"）可以升级和改进，而无需重写工作负载代码。
显然，创建工作负载既不能完全自动化，也不能完全不需要代码。无论采用什么方法，在考虑添加工作负载支持时都没有完全免费的午餐。有很多可能的方法可以改进平台如何支持更多工作负载，HYCU 和 Keepit 选择了其中的两种。
未来肯定很有趣，我们将继续关注业内各家公司未来采取什么策略来扩大工作负载支持。Keepit 一直遵循自己的策略，以更有效地为更广泛的工作负载添加可靠的支持。
Blocks & Files：谁使用 DSL 生产 SaaS 应用连接器 - Keepit 还是 SaaS 应用供应商？
Jakob ?stergaard：目前，使用我们的 DSL [领域特定语言] 技术，Keepit 负责新连接器的开发。随着技术和工具的成熟，允许第二方或第三方开发连接器有很大的未来潜力，有许多有趣的商业模式可以支持这一点。但目前，Keepit 仍在进行开发工作。
Blocks & Files：编写基于 DSL 的 SaaS 应用连接器涉及哪些内容？
Jakob ?stergaard："传统"连接器开发需要在通用编程语言中编写大量代码，而作为"领域特定语言"的 DSL 可以更好地适应连接器开发这一特定工作。
例如，典型的编程语言（如 C++ 或 Python）严格遵循命令式（"如果 A 则执行 B"），而其他一些语言（如 SQL 或 Prolog）是声明式的（"找到满足 X 条件的所有解决方案"），我们已经能够在我们的 DSL 中混合和匹配我们最需要的范式。
因此，在某些地方我们希望以声明式方式描述关系，让系统在备份期间"推断"适当的操作，而在其他地方我们编写更经典的命令式代码。使用一种自然适应当前问题领域的语言，有可能在开发新连接器时提供显著的生产力优势。
这是我们一年多前就开始的开创性工作。新技术需要时间来成熟，我们目前正准备发布使用这项新技术构建的第一批工作负载。这项技术将帮助我们在支持数百个工作负载的道路上前进，这些工作负载是当今平均企业已经在云端使用的，我们很高兴能在今年晚些时候推出这些新工作负载中的第一批。
本文链接：http://www.xihao.site/showinfo-1-73241.htmlKeepit 解答 SaaS 应用备份方案问题
