KonfDB Configuration Model Overview

To understand the configuration model, let’s take an example of Customer Service System.

A Customer Service System (CSS) caters to clients based out of the US, Europe and APAC regions.  It provides a portal for its enterprise customers who can build their own portfolio and manage their clients requests and complaints.  The Customer Service System (CSS) has regional flavours and is deployed in all the 3 regions.

Their Software Development Life Cycle is streamlined and they have defined process of development, user testing and production releases.

All portal & backend instances of CSS have different configurations of database connections, third-party components, reporting services, etc.   Currently, this configuration is stored in Configuration Files that are deployed as a part of code release.

Adopting KonfDB model

To onboard CSS on KonfDB, we need to consider 4 factors

  • Applications / Components in CSS – Service Portal (regional), Backend Services
  • Environments – Development, User Testing, Production
  • Regions – APAC, US, Europe
  • Servers – Number of servers varies regionally

This can be structured in a diagram as shown below KonfDB DiagramsSo essentially this represents a suite (let’s say Customer Service System) of 2 applications – Customer Service Portal and Backend Services and this suite has 3 environments (Production, User Testing and Development) in 3 regions (APAC, US, Europe) with multiple servers.  To configure this in KonfDB, we can represent the above picture into a mind-map as show below

Suite-MindMap

Configuration Parameter = f(Application,Environment,Server,Region)

 

Since a configuration parameter of a system can be represented as a function of various nodes (environments, servers, applications and regions), we can have one configuration parameter CertificateKey assume following different values

Parameter Value Application Environment Server Region
CertificateKey KEY.DEV.1 Customer Service Portal Development Server.01 APAC
CertificateKey KEY.DEV.1 Backend Service Development Server.02 APAC
CertificateKey KEY.UAT.2 Customer Service Portal User Testing Server.03 US
CertificateKey KEY.UAT.2 Backend Service User Testing Server.04 US
CertificateKey KEY.UAT.2 Backend Service User Testing Server.05 Europe
CertificateKey KEY.PROD.1 Customer Service Portal Production Server.06 APAC
CertificateKey KEY.PROD.1 Customer Service Portal Production Server.07 US
CertificateKey KEY.PROD.2 Backend Service Production Server.08 APAC
CertificateKey KEY.PROD.2 Backend Service Production Server.09 Europe
CertificateKey KEY.PROD.2 Backend Service Production Server.10 US

If we analyse the above data set, we have only following unique configuration parameters

  • CertificateKey with value KEY.DEV.1
  • CertificateKey with value KEY.UAT.2
  • CertificateKey with value KEY.PROD.1
  • CertificateKey with value KEY.PROD.2

However with multiple environments, regions and servers we end up with 10 different configuration parameters.  In a typical system, you would release independent configuration files into production.  This sounds good so far.

When any certificate expires, it results in configuration change of all systems – in total 10 different places and then a release to have these files changed.

This changes a bit with KonfDB.

KonfDB allows you to add 4 parameters instead of 10.  That’s a straight reduction in your configuration size.

Using these 4 parameters, you can create 10 mappings where each mapping is again represented by below function

Configuration Mapping = f(Application,Configuration Parameter,Environment,Server,Region)

The above parameters gets split into multiple parts

Applications

Application ID Application Name
A1 Customer Service Portal
A2 Backend Service

Regions

RegionID Name
R-APAC APAC
R-US US
R-EUROPE Europe

Environments

Environment ID Name
E-DEV Development
E-UAT User Testing
E-PROD Production

Servers

ServerID Server Name
S1 Server.01
S2 Server.02
S3 Server.03
S4 Server.04
S5 Server.05
S6 Server.06
S7 Server.07
S8 Server.08
S9 Server.09
S10 Server.10

Parameters

Parameter ID Parameter Value
P1 CertificateKey KEY.DEV.1
P2 CertificateKey KEY.UAT.2
P3 CertificateKey KEY.PROD.1
P4 CertificateKey KEY.PROD.2

Once we have defined this metadata, we need to build up a mapping (using the function above) between them

Mappings

Mapping ID Parameter Name Parameter Value Application ID Environment ID Server Region
M1 CertificateKey KEY.DEV.1 Customer Service Portal Development Server.01 APAC
M2 CertificateKey KEY.DEV.1 Backend Service Development Server.02 APAC
M3 CertificateKey KEY.UAT.2 Customer Service Portal User Testing Server.03 US
M4 CertificateKey KEY.UAT.2 Backend Service User Testing Server.04 US
M5 CertificateKey KEY.UAT.2 Backend Service User Testing Server.05 Europe
M6 CertificateKey KEY.PROD.1 Customer Service Portal Production Server.06 APAC
M7 CertificateKey KEY.PROD.1 Customer Service Portal Production Server.07 US
M8 CertificateKey KEY.PROD.2 Backend Service Production Server.08 APAC
M9 CertificateKey KEY.PROD.2 Backend Service Production Server.09 Europe
M10 CertificateKey KEY.PROD.2 Backend Service Production Server.10 US

or better represented with IDs as

Mapping ID Parameter ID Application ID Environment ID Server ID Region ID
M1 P1 A1 E-DEV S1 R-APAC
M2 P1 A2 E-DEV S2 R-APAC
M3 P2 A1 E-UAT S3 R-US
M4 P2 A2 E-UAT S4 R-US
M5 P2 A2 E-UAT S5 R-EUROPE
M6 P3 A1 E-PROD S6 R-APAC
M7 P3 A1 E-PROD S7 R-US
M8 P4 A2 E-PROD S8 R-APAC
M9 P4 A2 E-PROD S9 R-EUROPE
M10 P4 A2 E-PROD S10 R-US

 

With above setup in KonfDB, when certificates expire you do not have to change 10 parameters.  You just have to change values of P1-P4 which will reflect an appropriate change in all 10 mappings.

No application works with just 1 configuration parameter. So just imagine this reduction with more number of configuration parameters and the ease of maintenance with an application with 100 parameters.

When the application wants to retrieve the configuration relevant to its particular instance, it merely needs to provide the right combination of Application Name/ID, Environment Name/ID, Server Name/ID and Region Name/ID.  KonfDB will search the mapping that correctly represents this data and provide in its APIs or RESTful services.