SaaS maturity level 2, how i can build configurable SaaS?(Technics and patterns)

According SaaS maturity model a SaaS is level 2 if is configurable, 开发者_Python百科but how i can get started in this concept?how patterns and Technics, i can use to enable my SaaS?

The primary pattern is separation of configuration data from application code. Find the properties of your application that may vary from installation to installation, and pull those properties out into a configuration system.

Start by figuring out some basic properties that are likely to vary from installation to installation. Some examples: What port numbers are your services on? What URLs? What certs/CAs that you are using? Can the customer rebrand/reskin your software, and where are their brand images or skin resources located? What OSes will you deploy to, and what is liable to change when the OS changes? Even configuring where your configuration lives can be an important property to vary. Then extend to features that may be unique to particular sites: how do you enable them? do they need to be set up differently for different customers? As you go through this exercise, keep in mind that you are adding points of variation to your system, thus additional points of complication, and additional points that need to be validated, tested, and potentially secured. Think carefully about which points of variation really matter to your customers, and focus on those.

Then think about implementation:

• Usually, a configuration system is as dirt-simple as plain text files that get installed with the application, key = value style. The configuration could be in multiple files, or one file with sections (ini-style), or both.
• Allowing for comments in the configuration is common, and extremely helpful in documenting what the config keys mean, or for allowing the customers to document themselves why they set something up a particular way.
• Depending on the technology you're building your applications with, there may be natural configuration mechanisms that go with the application stack.
• Some folks like XML or JSON or YAML, though IMO the extra effort spent dealing with that format may not be worth it, especially if humans are editing the config.
• Sometimes a complicated configuration file may be written in a full-blown domain-specific language. (Technically, most configuration file formats are DSLs of one sort or another, but I'm talking here about the ones who really pour a lot of expressivity into the configuration format – conditionals, pattern matching, structured types, etc.) However, this comes with additional overhead for both you and the customer who has to learn the DSL, and neither of you probably wants to make reading/writing these configs your core competency, so I'd advise against it unless you have a pressing need for it.
• Some folks like to write their configs in the scripting language they're writing the applications in, since it's trivial to load and gives you the full power of a programming language when specifying the config. It may actually be pretty easy for customers to pick up if they're already familiar with the scripting language, and the scripting language syntax for basic structures is usually simple. However, my experience is that it can be surprisingly easy for customers to mess these up, and syntax errors are not particularly amusing for customers to diagnose and fix.
• Often, a service will allow configuration to be specified in multiple ways: config files, environment variables, and command-line arguments, for example. Those can be useful for temporarily tweaking the default config for testing, or for a non-sysadmin user to be able to run.

For complicated multi-tier setups, you may want to provide some additional tools to help synchronize configuration across the machines where it's necessary. Many services also provide tools to generate default configuration files. These files are often loaded with comments to explain each configurable value, which will help the customer get started with using them.

There are a ton of examples out there about how people have gone about configuring their services. Study your favorite services and how they're configured. Think for yourself, or ask your friends, about which services you felt were the easiest to set up. Remember that the configuration is part of your interface to your customer, so you want it to be as clean, understandable, and easy-to-use as possible.