Ortelius Configuration Mapping

Mapping Microservices to Applications

Map your Microservice to an Application

Tracking the monolithic equivalent of an application is critical for developers building solutions around microservices.  And if you are pushing continuous deployments, you will need to quickly understand the impact your micorservice release will have on the applications that consume it.  For this reason, Ortelius maps application dependencies on microservices.

Mapping is achieved by identifying your full stack – application, environment variables, and infrastructure all together as a complete unit. This unit is called an “application” Map or Package in Ortelius. Your application package is basically your map, seen and known by everyone in the loop.

And, for those who know Agile DevOps, communication is everything. When development, testing, and production are all on the same page, even when their environments are different, your software deployment process becomes repeatable.  The map keeps them on the same page…and much, much faster. Which is the goal.

Although agile DevOps teams often maintain an ongoing dialogue about software in development, the testing and production teams are not always included in those daily DevOps conversation. Hence, your new software application map will keep everyone in the loop. It becomes core to your DevOps practice.

Creating your Map: Keeping Your DevOps Team Informed

Ortelius includes a Map Designer that defines the application’s associations, and makes this information available to everyone on the team. Especially relevant, it displays a software deployment map for each application version that is pushed across the continuous delivery pipeline, and tracks the version to the endpoint.

1. Workflow logic used to perform the actual continuous deployment installation such as Helm charts, Ansible or RedHat Operators.
2. Variables requiring adjustment based on the target continuous delivery environment, particularly important for AWS Lambda functions.
3. Database updates coming down the continuous delivery pipeline.

No More Monolithic Releases

Unique to Ortelius is the ability to version all of the component and microservice meta data.  This means that your Application Map is treated just like source code allowing you to ‘check-out’ incremental changes between any two versions. Versioning includes database components, environment variables, infrastructure, and your application level components such as microservices. Versioning also includes audit information so you can easily see who changed the ‘code’ and when. Every component within the map is versioned, along with any updates, to the installation workflow for that component.

With versioning, Ortelius can easily rollback or roll forward a release on an incremental, not monolithic, basis. But best yet, it allows version jumping. Version jumping makes it super simple to move between any two software releases by applying incremental changes to get you there, including database updates and infrastructure changes. Now that is big.

….try that with a one-off script.

Component Sharing and Publishing

Ortelius uses Domains to leverage the the sharing of microservice versions  across diverse teams. By sharing components, errors are minimized, and any version of you software deployment is more easily reproduced.