What is Microservice Configuration Management?

Microservice Configuration Management – Tracking Application Versions and Clusters

Microservice configuration management is the process of tracking changes to microservices and their consuming applications over time.  In monolithic development, configuration management was done at the ‘software’ level, and called software configuration management or SCM.  With SCM, version control and configuration management was done by checking in source code to a version repository, and checking it out for a compile/link step. This is where the core of all SCM was done.  The results of SCM was the ability to clearly see the changes between two releases shown via a Bill of Material Report, Difference Report and Impact Analysis Report. With microservices we have shifted from tracking at the SCM level and now need to track at the microservice level.  Changes to a microservice impacts your Microservice Architecture. This means that every logical application that consumes that service will have a potential impact.

With that in mind, DeployHub versions all microservice deployment and configuration meta data allowing you to see what microservices are running in your cluster, their versions, how they got there and which applications are using them. While microservices move us away from traditional build and release approaches, we still need a method of tracking their changes and a way to make them unique. Like a software version control solution, DeployHub tracks specific information in the microservice to track its changes and uniquely identify a version.

Microservice Configuration Management and Unique Meta Data

Microservice configuration management requires unique meta data to identify a specific version of a microservice.  DeployHub gathers the following meta data into a single version of a microservice, or component (web components, database updates for example):

  • GitHub, Jira Change Request
  • Git repo
  • CI/CD Build Number
  • Container Registry
  • Container Digest
  • Container Tag
  • Git Commit
  • Environment Variables
  • Deployment Script (Helm Chart, Ansible Playbook, etc)
  • Any Attributes (DB Name for example)

This information is initially collected when you define your microservice to the DeployHub Domain catalog. You can collect this data via the DeployHub interface, or using a DeployHub CI/CD plugin such as Jenkins, JenkinsX, Tekton, CircleCI, Google CloudBuild, Puppet Nebula or any CD engine.

Microservice Configuration Management

Microservice Configuration Data

 

Once defined, DeployHub uses your CI/CD plug-in to perform automated configuration management updates to track changes in this information any time a new version of your microservice is created.  In addition,  your CI/CD process will call DeployHub to automatically increment the application version if a microservice it consumes is updated.  You can also subscribe to a ‘base’ version of a microservice which then notifies you if a new version of a microservice has been created.  As microservices are consumed by applications, DeployHub tracks the dependencies.  It can tell you at any point in time which version of the microservices your application is consuming, how many different versions have been deployed to your Kubernetes cluster, and who is using the same microservice.  DeployHub builds a map that displays this data overtime.

 

 

Conclusion

You can expect to be managing thousands of microservices in your Kubernetes cluster.  DeployHub provides you a method for managing your microservice inventory along with all configuration management details.  It integrates with your CI/CD process to continually update new versions of your microservices that in turn creates new versions of your applications.  With our inventory system, you always know what version of a microservice your application version is dependent upon.  You have the insights on the meta data to resolve issues, and expose the level of impact a new microservice version may create.

 

Leave a Reply