Ortelius Configuration Mapping

Mapping Microservices to Applications

Microservice Mapping, Configuration Management and Tracking Application Versions and Clusters

Microservice mapping is a configuration management process that tracks 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. Microservice mapping tracks that for you.

Microservice mapping includes the process of versioning all microservice deployment and configuration meta data to allow visibility into 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, Ortelius tracks specific information in the microservice mapping to track its changes and uniquely identify a version.

Microservice Mapping, Configuration Management and Unique Meta Data

Microservice mapping and configuration management requires unique meta data to identify a specific version of a microservice.  Ortelius 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 Ortelius Domain catalog. You can collect this data via the Ortelius interface, or using a Ortelius CI/CD plugin such as Jenkins, JenkinsX, Tekton, CircleCI, Google CloudBuild, Puppet Relay or any CD engine.

Microservice versioning

 

Once  a base line is defined, Ortelius 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 Ortelius 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, Ortelius 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.  Ortelius builds a map that displays this data overtime.

Conclusion

You can expect to be managing thousands of microservices in your Kubernetes cluster, requiring the process of microservice mapping.  Ortelius provides 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.