Skip to main content

Repository Analysis

Errors during the data collection phase are common due to platform complexity and manual work from different actors. The repository analysis scans the repository, detects errors and inconsistencies, and generates suggestions to fix them, ensuring accurate modeling for subsequent cloud transformation stages or reporting.

Available analyzers:

The Repository Analysis consists of several independent ‘analyzers’ that detect and report the mentioned anomalies with the objective of improving the data quality. Analyzers emit suggestions which can then be applied to remediate any discovered problems. Ignored suggestions will not be shown again.

Isolated Assets​

This analyzer reports assets with no links and issues two suggestions:

  • Deletion of the asset in question
  • A simple warning to link the asset

Duplicated Assets​

While easy to spot visually in a deployment stack, it's not a straightforward task to eliminate all duplications from the repository. The duplicate assets analyzer addresses this task by calculating a name similarity score between all assets. If the similarity score passes a certain threshold, a suggestion to merge the assets in question will be issued. Alternatively, a suggestion to remove either of the assets will be shown.

Storage Capacity​

Storage assets are analyzed to find assets where

  • the Capacity Used is larger than the Capacity Total
  • the ratio Capacity Used / Capacity Total is outside a certain threshold indicating a likely modeling error

The analyzer tries to detect the source of the problem by simulated switching of units and Capacity Used vs Capacity Total. It then suggests to solve the problem by (depending on the root cause):

  • Switching the property mapping in the importer
  • Setting correct units in the importer configuration

Resource Utilization​

This analyzer checks that underlying infrastructure has the required resources to actually power the technical components running on them. The check includes CPU, storage and RAM on each of the assets in question. Warnings issued by this analyzer can indicate that either in import was misconfigured or systems may be overloaded.

V-Pattern​

During cloud migration projects, one often stumbles upon a data situation that allows for importing stacks akin to the following:

By modelling the application stack in this way, the database would be ignored for any proposal calculation or assessment.

The automatically issued suggestion is a link creation in order for the asset to be considered in the deployment stack.

Communication Inference​

Server-to-server communication information is often extracted from discovery tools in the discovery phase. This data can be of high importance in cloud migration projects since it can help to avoid interruptions during the migration process. However, server-to-server communication can be numerous and important dependencies between applications are easy to miss.

Therefore, this analyzer allows to easily create a link on the application level to make the dependency visible in the Transformation Cockpit:

Technology Variant​

Most asset types have two properties that specify their cloud product:

  • Technology: specifies the product in use e.g. Amazon EC2
  • Technology Variant: specifies the instance of the product e.g. Amazon EC2 t3a.2xlarge

Txture offers a feature that syncs certain attributes of the technology used back to properties of the asset. This anaylzer checks for any data in properties that contradicts itself. For example, the abovementioned Amazon EC2 t3a.2xlarge offers 8 CPU cores. If the number of CPU cores annotated in the property of the asset was different, a suggestion to correct the value would be issued.

Last updated on