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 microservice configuration management were 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 were 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 impact your microservice application. This means that every logical application that consumes that service will have a potential new release candidate.
With that in mind, DeployHub versions all microservices with their configuration meta data allowing you to see what versions of microservices are running across all of your clusters, how they got there, and which applications are using them. While microservices move us away from the traditional build and release approaches, we still need a method of tracking their changes and a way to make them unique.
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 Data
Once defined, DeployHub uses your CI/CD plug-in to perform automated microservice 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 over time.
In Conclusion: Microservice Configuration Management
With microservice configuration, you can expect to be managing thousands of microservices in your Kubernetes cluster. DeployHub provides you with a method for managing your microservice inventory along with all microservice 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.
Like a software version control solution, DeployHub tracks specific information in the microservice to track its changes and uniquely identify a version.