SaaS成熟度2级，我如何构建可配置的SaaS？（技术和模式）

Question

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

Answer 1

主要模式是将配置数据与应用程序代码分离。查找应用程序的属性，这些属性可能因安装而异，并将这些属性拉出到配置系统中。

首先找出一些可能因安装而异的基本属性。一些例子：您的服务有哪些端口号？什么网址？您使用的是哪些证书/ CA？客户可以重塑/重新设计您的软件，以及他们的品牌形象或皮肤资源位于何处？您将部署哪些操作系统，以及操作系统更改时可能发生的变化？甚至配置配置所在的位置也是一个重要的变化属性。然后扩展到特定网站可能独有的功能：如何启用它们？他们需要为不同的客户设置不同的设置吗？在进行此练习时，请记住，您正在为系统添加变异点，因此需要额外的复杂点以及需要验证，测试和可能受到保护的其他要点。仔细考虑哪些变化点对您的客户真正重要，并专注于那些。

然后考虑实施：

• 通常，配置系统与使用应用程序key = value样式安装的纯文本文件一样简单。配置可以是多个文件，也可以是一个带有部分（ini-style）或两者的文件。
• 在配置中允许注释是很常见的，并且非常有助于记录配置键的含义，或者允许客户记录他们为什么以特定方式设置某些内容。
• 根据您正在构建应用程序的技术，可能存在与应用程序堆栈一起使用的自然配置机制。
• 有些人喜欢XML或JSON或YAML，虽然IMO花费在处理这种格式上的额外努力可能不值得，特别是如果人类正在编辑配置。
• 有时，复杂的配置文件可能使用完整的特定于域的语言编写。 （从技术上讲，大多数配置文件格式都是这种或那种类型的DSL，但我在这里谈的是那些真正在配置格式中注入大量表现力的人 - 条件，模式匹配，结构化类型等等。）对于你和必须学习DSL的客户来说，还有额外的开销，你们两个都不想让读/写这些配置成为你们的核心竞争力，所以除非你迫切需要它，否则我会反对它。
• 有些人喜欢用他们正在编写应用程序的脚本语言来编写他们的配置，因为加载它是微不足道的，并且在指定配置时为您提供编程语言的全部功能。如果客户已经熟悉脚本语言，那么客户实际上可能很容易接受，而基本结构的脚本语言语法通常很简单。但是，我的经验是，客户可能会非常轻松地搞砸这些内容，而语法错误对于客户诊断和修复并不是特别有趣。
• 通常，服务将允许以多种方式指定配置：例如，配置文件，环境变量和命令行参数。这些可以用于临时调整默认配置以进行测试，或者非sysadmin用户能够运行。

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

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