开放saas平台架构_开放采购SaaS业务时将面临的挑战-CSDN博客

开放saas平台架构

在上一篇文章中，我逐步介绍了各种方案来帮助您确定是否开源您的SaaS解决方案，并讨论了与此决策一起进行的成本效益分析。从开放源代码的角度来看，仅在墙上乱扔代码，拍打开放源代码许可证并称其为一天是没有意义的。您想创建一个吸引人的社区，人们希望在此社区合作并度过时光，甚至与您社交！

除了让其他人深入了解您的操作方式，在墙上抓代码无济于事。尽管这对他们来说可能是有趣且有益的，但是除非您创建协作和沟通的途径以释放繁荣的社区，否则您不会获得太多收益。因此，您对执行“正确的方法”有内在的兴趣。

我有好消息也有坏消息：

首先，坏消息是：这真的很难！而且您应该从一开始就这样做。
现在，好消息是：这是有益的，而且您获得的回报比投入的要多（我有数据证明了这一点）。

开源为SaaS设计的整个软件堆栈的最大问题之一是开发团队习惯于从单个代码存储库中进行工作。实际上，他们经常嘲笑我们的企业软件同事，他们的多个分支分散在各处。我对DevOps哲学家最大的问题之一是，他们通常认为您只需要一个分支或仓库即可。而且，如果您使用父仓库中的分层分支，则认为与敏捷开发相反。

建议您可以简单地依靠单个代码存储库或分支听起来很有吸引力，但这对于协作开发的软件可能会固有地存在问题。这是典型的SaaS项目的供应链：

上图有两个主要问题：

上游开源项目的核心代码被分叉和遗忘，然后与其余的代码一起继承和维护，直到将来需要痛苦的重新基础。它被分叉的原因是……
SaaS项目无需担心管理来自第三方源的传入代码。整个过程旨在从外部进行，在内部进行自动化，永远不会在上游合并。它被设计为可以使用和丢弃，而不是针对持续的管理和维护进行了优化。因此，当开发团队意识到协作项目需要管理传入的想法和代码时，他们会感到震惊。

您的核心团队与不一定具有相同用例的新进来的贡献者之间的内在冲突可能会很痛苦。那些第三方希望拥有共享的所有权和管理权，这并不总是与项目发起者的用例保持一致。核心团队只是希望他们的解决方案能起作用，而不愿意为收到的捐款打扰，即使有必要克服我先前提出的资源约束问题。允许SaaS项目超越其原始团队的唯一实际解决方案是：

Bidirectional collaboration with ecosystem

预期的投资回报率是多少？

我会为我的竞争对手提供弹药使我破产吗？答案通常是“否”，尽管暗示它永远都不是错误的。

考虑到将SaaS转换为开源所需的工作量，选择开源的决定不应轻描淡写。这就引出了一个问题，即为牺牲生产力而期望得到什么呢？回到上面的供应链图，这意味着您的团队将能够与外部团队就核心代码进行协作，从而提高效率。这不仅仅是学术或理论上的练习；我们有数据可以备份。正如我在OSEN博客上所描述的那样，世界银行对其对Geonode项目的投资进行了研究，确定其工程投资的ROI为200％，这是非常重要的。

这意味着领导SaaS工程团队的任何人都需要进行以下计算：要使效率方面的收益超过重新架构给定项目或项目集的成本，需要花费多少时间？

该计算的一部分必须包括可用资源来执行此工作。例如，如果您能够大量雇用工程师并拥有Google，Facebook或Amazon的资源，那么您可能会降低成本意识，而在工程方面变得更加高效的想法是可能没有那么引人注目。另一方面，如果您正面临逐渐减少的工程资源或竞争对手的工程资源，而您的竞争对手却有更多准备就绪的资源，那么采用开源途径可以让您更具创新精神，并专注于在竞争激烈的市场中增加价值。

蚕食和失去竞争优势

最后，我们讨论这个想法时最常问到的问题是：我是否为竞争对手提供弹药以使我破产？答案通常是“否”，尽管暗示它永远都不是错误的。但是，如果您是SaaS公司，那么您的主要竞争对手很可能没有使用您的解决方案，即使他们有机会，也极不可能将其吸引到您的解决方案中。像您一样，您的竞争对手已经在其解决方案中内置了一系列决策，自定义配置和工作流，这些决策旨在专门用于开展业务。您的软件无需跳动即可投入解决方案的机会几乎为零。重新设计解决方案以适合竞争对手的软件平台的想法是如此渺茫，无论我们是在谈论专有的本地软件还是SaaS解决方案，我都无法想到。对于本地软件来说，这种风险已经很低，而对于SaaS来说，这种风险仍然更低。

尽管这种风险不为零，但必须与不公开采购软件的风险进行权衡。不公开采购软件组件的风险包括永远无法达到增加足够的价值来实现目标所需的创新速度。哪种风险更有可能？如果您的资源几乎是无限的，那么您的风险状况就会向不为竞争对手提供潜在弹药的方向倾斜。但是，如果您将来面临的资源有限，请考虑以下可能性：未开源软件的风险大于未开源软件的风险。