我在本地部署SaaS软件的经验教训(2018)

通过指导客户在内部部署我们的SaaS应用程序，我学到了惊人的东西。

在Windows计算机上处理零散的数据库迁移与运行我们精心调整的AWS vPC大相径庭。我很高兴我们咬紧牙关，很早就在本地部署--它以我无法想象的方式塑造了我们的应用程序和系统设计决策。

我们在2014年推出了我们的集成平台KLouless，作为AWS上的多租户Web应用。它提供统一的API，使工程师能够将其他几个业务应用程序集成到单个实施中。

当我们开始与第一批企业客户合作时，我们很快意识到我们的SaaS应用程序没有达到各种预期的法规遵从性和审核要求。在我们认证符合PCI和HIPAA，或者经过SOC 2审核之前，有几个组织根本不能使用KLouless。

作为首席技术官，我向我的团队提出了挑战，要求他们找到解决方案。我们很快推出了KLouless Enterprise，这是我们的云解决方案的内部版本，允许我们的客户将KLouless作为其内部堆栈的一部分来运行。今天，KLouless Enterprise Docker Containers、AMI和OVAS为财富50强公司和美国一些最大的银行提供动力应用。今年，我们每月超过5亿次上游API请求。

#无声企业(出自https://bit.ly/2RbUOri)\=_=_/_.-'；-`-._\\-._--/\\//`-_-'；__，--`.`-'；..'；-_/_||`--._，-'；

KLouless Enterprise经常安装和更新，因此我们的客户要求快速完成此过程。限制暴露的活动部件的数量使我们能够提供与部署新的Docker容器一样简单的更新。开发人员可以先使用本地PostgreSQL和Redis服务，然后配置外部服务，以实现可伸缩的生产部署。这种结构类似于GitLab的Omnibus包，这是一个很好的例子。

我们将许可证绑定到图像和容器的单独发布渠道，因为特定客户或特定版本有时需要发布补丁。秘密：我们还为KLouless操作员提供了将单独的应用程序代码包更新到容器内的下一个补丁版本的能力，不变性见鬼去吧。虽然这是一种反模式，并且绝对不是推荐的选项，但有时它被证明是处理必要的变更管理审查过程中阻力最小的路径。

保留容器外部的所有应用程序状态，如许可证、加密密钥和元配置，可以实现无缝更新。使用外部存储(如Docker卷)和网络连接存储(如EBS)可在更新期间保留配置。

适用于企业和本地部署的SLA通常需要能够快速诊断问题，最好使用命令行实用程序和监控集成等自助式工具。即便如此，我们的工程团队不得不深入远程部署的KLouless开发集群，引导操作员完成配置并诊断难以重现的问题。使其与排除任何云环境故障一样简单，这是一个主要的好处。当事情没有按计划进行时，支持人员需要可用的工具来帮助客户。

我们构建了命令行实用程序来执行从读取和发送日志数据到管理用户、维护窗口和配置更新的所有操作。我们最常用的工具可验证从KLouless Enterprise实例到我们网络中安全远程堡垒的出站连接，以便工程师通过反向SSH隧道提供帮助。对于这类东西，一定要使用autossh。此实用程序允许我们应客户的要求访问防火墙后的客户实例，同时维护他们的合规性要求。

专用无人值守部署覆盖了总共运行100个以上内核的多台机器。您可以通过提供规范的缩放指南和要考虑的事项来防止不必要的压力。

10+个小型AWS实例，而不是5个较大的实例。有趣的事实：AWS网络吞吐量基于实例vCPU，因此添加更多实例并不能解决网络瓶颈问题！

未处理的网络分区问题。我们很快就从使用etcd的有状态的主/次集群格式切换到了无主控模式。这不仅使我们客户的运营团队更加简单，而且更加强大，能够更好地处理大型部署。

多样化的部署环境和工具。我们最初的版本有一个交互式的设置过程，需要的准备工作较少，但在大型生产环境中却成了绊脚石。非交互式部署提高了自动化程度以及与AWS CloudForment和Docker Compose等现有工具的集成。

在写作主题上，我注意到我们必须向本地客户提供一套完全不同的文档。我们希望提供有关安装的API文档和信息，但我们还必须创建更多的文档，包括：

重要的是要坦诚对待所有数据传输，并确保在默认情况下选择启动出站连接的工具，以免激怒客户的安全团队。

最糟糕的部署策略是为本地部署分叉云应用程序。除了增加维护成本外，这还会导致狗蹄疾本可以捕捉到的错误。引入指示应用程序是否在本地运行的功能标志有助于轻松切换许可证限制和备用Web应用程序UI等功能。

但等等，还有更多：使用相同的应用程序和数据堆栈可以轻松地将云客户过渡到私有部署或本地解决方案，而无需复杂的数据迁移。虽然加密密钥等特定于环境的项目需要有文档记录的升级过程，但可以通过限制应用程序行为中的偏差来简化过渡。此外，销售团队喜欢顺畅地增加收入。

请前端设计团队不要参与这项工作。我在GitHub的一位朋友为GitHub Enterprise做出了贡献，这启发了我们在构建自己的解决方案时的许多设计选择。我们听取了一个宝贵的建议，以减少配置开销。我们取消了花哨的设置仪表板web UI，只提供了一个YAML文件进行编辑。这为我们节省了大量送货功能的时间。我们还：

如果您想与企业的工程和采购团队进行一次有趣的对话，那么告诉他们他们需要购买更多的本地软件才能真正查看分析、日志、监控等。使用第三方SaaS供应商非常适合云产品，但内部软件需要附带电池才能实现核心功能。

幸运的是，允许配置各种开源工具有助于打包功能并避免这些顾虑。例如，KLouless提供了将系统和应用程序指标发送到StatsD和InfluxDB以及通过标准协议将日志数据发送到外部的选项。这使得KLouless能够以最小的努力与现有的监控基础设施集成。

开源实用程序还可以帮助用户轻松配置应用程序安全性。例如，利用We‘s Encrypt为自定义域名快速提供SSL/TLS证书。

安全就像一个正弦波，在这篇博客文章中以周期性的间隔达到峰值。

应用程序安全超越了满足工程要求的技术解决方案。例如，认证符合性摘要和笔试结果等项目同样有价值。安全状况在每个阶段都是相关的，因为它是部署内部部署的主要原因之一。提供精心编写、全面的信息安全政策，涵盖从代码审查等SDLC流程到内部控制信息的方方面面，有助于满足客户对安全相关抵押品的贪婪需求。

我们收到了多个请求，要求提供单点登录、团队成员访问控制、活动日志、IP白名单等项目。使这些功能易于配置可实现无摩擦部署。然而，我们已经注意到，在大多数情况下，这些都不会破坏交易--我们发布的KLouless Enterprise没有几个受到大客户欢迎的功能。这可能特定于我们的应用程序类型，但我很高兴我们选择了尽快发货，而不是构建我们认为需要的功能。请查看enterpriseready.io，了解有关面向企业客户的软件中经常包含的功能的更多详细信息。

附注：我们还调整了我们的构建管道，从一开始就编译和混淆应用程序代码，以保护不同类型的IP，但事后看来，这是否有必要还有待商榷。

归根结底，客户可能会购买某种概念的许可证“密钥”来私下运行应用程序。我们发现，这里所需的最低限度的工作就是构建验证检查，并详细说明它们传输的数据。

比方说，您创建了产品的自托管版本，并且在您的云版本上运行了一个很棒的计费系统-甚至使用了最新的条纹计费API-具有清晰的许可模式。我发现，在您确定可重复的流程之前，最好还是手动为客户开具发票。我们避免了通过点击解决方案过早优化支付，这会阻碍定制的定价方案，特别是在企业交易量相对较低的情况下。与SaaS应用程序不同的是，由于净额30美元的发票延迟了几天，通常不能禁用账户。许可条款也有所不同，从季度和年度订阅到多年合同，因此我建议搁置每月cron工作或同等的解决方案。

我们构建了一个内部仪表盘，完全独立于支付来更新许可证，并且我们避免将购买本地解决方案的客户引导到提供给云客户的计费选项。要构建功能标志来处理不同的许可要求已经够难的了；要求单一支付流只会减慢速度。

KLouless集成了API，但也提供了Meta API来管理API集成平台。我今年的目标是说服我们的工程团队将KLouless与自己整合在一起。说真的，对应用程序的编程操作对于部署本地解决方案的工程团队来说是一个巨大的好处。它支持客户可能甚至没有费心提前提出的工作流，例如要求每隔90天轮换一次密钥。

我强烈推荐使用API来管理应用程序中的所有数据，特别是配置和取消配置工作流。

最终，我们的GTM战略将我们的应用程序部署在客户感到放心使用的地方；要么是我们的多租户云、由我们管理的私有部署，要么是完全自托管的虚拟机和容器。对于考虑内部部署的供应商来说，要做出的一个关键决策很简单，那就是上述开销是否值得其带来的好处。

要了解更多关于KLouless如何帮助您的SaaS应用程序在集成方面取得成功的信息，请立即查看我们新的API集成官方指南！