Microservice Configuration Management
Configuration is an important part of production applications. As you build out a microservice application, the configuration is essential for knowing what your production application consumes. This is the beginning of the supply chain security conversation.
When creating microservices, it is typically best practice to have configuration values separated out from your code. In this article, we review microservice configuration management and how to track application versions and clusters.
Article contents:
- What is microservice configuration management?
- Software configuration management
- Centralized configuration
- Configuration management and unique meta data
What is Microservice Configuration Management?
Microservice configuration management is defined as the process of tracking changes to microservices and their consuming applications over time.
In microservices, you have multiple applications and multiple instances to configure and manage. During microservices configuration, it’s essential to have the ability to track and manage the version history of configuration changes. There’s a difference between having real-time management and having changes happen in real time. Knowing the differences between the two updates is critical to determining root cause analysis. These changes are a starting point for understanding the problem.
Difference reports are essential for that analysis – they help track the changes between two versions of the same microservice application. Here is our difference report that visualizes these changes.
Example configuration
Here are some examples of the configuration data that is tracked:
- SBOM
- Ownership
- Environments
- Key-value pairs
- Container SHA
- Git Commit
- CVE
- service to service relationships
- service to application relationships
In monolithic development, configuration management was done at the ‘software’ level and called software configuration management or SCM.
Software Configuration Management
With traditional software configuration management, version control was the focus completed by checking in source code to a version repository and checking it out for a compile/link step. 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 source code level and now need to track at the microservice/container level with all necessary attributes. Changes to a microservice impact your application. Every time a microservice is updated, all logical applications that consume that service will have a new release candidate.
With that in mind, DeployHub versions all microservices with their configuration metadata, 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.
Centralized Configuration
Centralized configuration is a pattern where the configuration for all services is managed in a central repository rather than being scattered across clusters. This centralization is a core feature of a unified microservice catalog.
Centralizing microservice configuration management also makes it easy to find and share services. In addition, catalogs track the ownership, so everyone knows who to call when there is a problem.
Ultimately, centralizing configuration and versions of microservices helps tame microservices at scale.
Microservice Configuration Management and Unique Meta Data
Microservice configuration management requires unique metadata to identify a specific version of a microservice. Here are some features of DeployHub that help with this:
DeployHub Features
- Gather metadata
- Automated microservice configuration management updates
- Automatically increment application version
- Tracks dependencies
- Tracks inventory of versions across ALL clusters.
Gather Meta Data
DeployHub gathers the following metadata 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
Automated microservice configuration management updates
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.
Automatically increment application version
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.
Tracks dependencies
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
You can expect to manage thousands of microservices in your Kubernetes cluster with configuration management.
DeployHub provides a method for managing your microservice inventory and all microservice configuration management details. It integrates with your CI/CD process to continually update new versions of your microservices that, in turn, create new versions.
With our inventory system, you always know what version of a microservice your application version is dependent upon. You have the insights into the metadata 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.
Further Reading on Microservices:
- Microservice Catalogs Explored Whitepaper
- Microservice Version Management
- Know Your Microservice Blast Radius
- Microservice Applications
- Microservice Pipelines
- Microservice Ownership for Improving Incident Response