SaaS成熟度级别2，如何构建可配置的SaaS？(技术和模式)

Question

根据SaaS成熟度模型，如果SaaS是可配置的，那么它是2级的，但是我如何开始这个概念?我如何使用模式和技术来启用我的SaaS？

Answer 1

主要模式是将配置数据与应用程序代码分离。找到应用程序的属性，这些属性在不同的安装中可能会有所不同，并将这些属性提取到配置系统中。

首先，找出一些基本属性，这些属性可能在不同的安装中有所不同。下面是一些例子:您的服务使用的是什么端口号？什么URL？您使用的是什么证书/CA？客户是否可以对您的软件进行品牌重塑/外观重塑，以及他们的品牌形象或皮肤资源位于何处？您将部署到什么OSes，当操作系统发生变化时，可能会发生什么变化？甚至配置您的配置所在的位置也可能是一个需要改变的重要属性。然后扩展到可能是特定站点独有的功能:如何启用它们？它们是否需要针对不同的客户进行不同的设置？在完成本练习时，请记住，您正在向系统中添加变化点，从而增加了复杂点，以及需要验证、测试和潜在保护的其他点。仔细考虑哪些变化点对您的客户真正重要，并将重点放在这些点上。

然后考虑实现：

• 通常，配置系统就像随应用程序一起安装的纯文本文件一样简单，key = value风格。配置可以在多个文件中，或者在一个文件中包含部分(ini样式)，或者两者兼而有之。允许在配置中添加注释的
• 很常见，这对于记录配置键的含义非常有用，或者允许客户自己记录为什么要以特定的方式设置某些内容。
• 根据您构建应用程序所使用的技术，应用程序堆栈中可能存在自然的配置机制。
• 有些人喜欢XML、JSON或YAML，尽管在处理这种格式上花费的额外努力可能不值得。特别是在人类编辑config.
• Sometimes时，复杂的配置文件可能是用成熟的特定于域的语言编写的。(从技术上讲，大多数配置文件格式都是这样或那样的DSL，但我在这里谈论的是那些真正在配置格式中注入大量表现力的格式-条件、模式匹配、结构化类型等。)然而，这对你和必须学习数字用户线的客户来说都有额外的开销，你们可能都不想把读/写这些配置作为你的核心能力，所以我建议你不要这样做，除非你有迫切的需要。
• 有些人喜欢用他们编写应用程序的脚本语言来编写他们的配置，因为它加载起来很简单，并且在指定配置时给了你编程语言的全部功能。如果客户已经熟悉脚本语言，并且基本结构的脚本语言语法通常很简单，那么他们可能很容易学会。然而，我的经验是，客户可以很容易地弄乱这些，语法错误对于客户诊断和修复来说并不是特别有趣。
• 通常，服务将允许以多种方式指定配置:例如，配置文件、环境变量和命令行参数。对于临时调整测试的默认配置，或者让非sysadmin用户能够运行，这些都很有用。

对于复杂的多层设置，您可能希望提供一些额外的工具来帮助在必要时跨机器同步配置。许多服务还提供生成默认配置文件的工具。这些文件通常会加载注释来解释每个可配置值，这将帮助客户开始使用它们。

有一大堆关于人们如何配置他们的服务的例子。研究您喜欢的服务以及它们是如何配置的。自己想一想，或者问问你的朋友，你觉得哪些服务最容易设置。请记住，配置是您的客户界面的一部分，因此您希望它尽可能干净、易于理解和易于使用。