Conflicts

Edit online

Whenever multiple application instances share an asset in their deployment stacks, conflicts may arise. This is a natural consequence of Txture's application-centric approach.

What is a Conflict?

Edit online

A conflict always occurs when the same as-is asset is replaced multiple times in the target landscape by different proposals.

Example: Conflicts arising from shared infrastructure

Let's assume App 1 and App 2 are application instances and share a database DB 1. Typical examples for conflicts include:

  • Opting for different migration strategies for the application instances between which assets are shared. The migration proposal for App 1 may choose to rehost DB 1, while the migration proposal for App 2 chooses to replace DB 1 with a PaaS solution.
  • Choosing the same migration strategy for the application instances, but moving to different cloud providers. App 1 may move to AWS, while App 2 moves to Google Cloud. DB 1 will be present at both providers.
  • Choosing the same strategy and provider, but different locations for the application instances. App 1 may move to Frankfurt, while App 2 may move to Paris. The shared DB 1 will be present in both locations.
  • Choosing the same strategy, provider and location, but deploying the element twice. Even if we select the same target settings for App 1 and App 2, without further input we would effectively deploy DB 1 twice because each application instance manages its own stack.

In all examples above, there are two instances of DB 1 (one for App 1 and one for App 2). This of course also doubles the cost and carbon emissions for that asset in the target landscape. In the figure above, this is depicted as Conflict #1. Furthermore, there may be nested conflicts if the conflicting element has further infrastructure in its own stack. In the figure above, an example is shown as Conflict #2.

Note: In an application-focused workflow, it is normal to eventually encounter some target landscape conflicts. This does not mean that something went wrong; these are just migration cases that require additional consideration.
Note: A conflict merely indicates a potential duplication of cost due to multiple deployments. Especially when re-architecting a landscape, it can be a viable option to deploy a single asset multiple times. For example, it can be an effective strategy to split a previously shared database cluster into smaller individual database servers and attach them only to the relevant application instances. In this case, we recommend to look closely at the utilization and downsize the individual deployments via right-sizing.

Detecting Conflicts

Edit online

Txture offers automatic detection of conflicts. This operation is based on:

  • The contents of your repository in the As-Is scenario
  • The contents of your repository in the Target Landscape scenario, which consist of:
    • The selected migration proposals
    • For apps which have no selected cloud migration proposals, the automatically generated migration proposal will be used as a fallback
Warning: In particular, an arbitrary saved proposal will not be considered in conflict detection, unless it is selected or the automatically generated ("proposed") one.

Resolving Conflicts

Edit online

Txture features an overview that lists all conflicting asset migration actions. In the general view of the target architecture in the transformation cockpit you can find the Conflicts card along with the Show conflicts option in the center top.

Conflicts View

The overview will show you the information required to resolve the issues. It lists all application instances which use the asset and each of the chosen migration actions that are in conflict. For example, the screenshot above shows that VM 1 is set to be replaced by different compute products for two different application instances that share the server.

It also shows that DB 1 gets rehosted twice onto different stacks as a separate conflict. Remember that DB 1 in our example runs on VM 1. So we have two conflicts in the same part of the stack. We call the conflict on VM 1 a nested conflict, because it is fully contained by the conflict on DB 1. In other words: if the conflict on DB 1 gets resolved, it will also resolve the conflict on VM 1. You can use the "Include Nested Conflict" toggle to decide if you want to view the nested conflicts, or if you only want to see the top-level conflicts.

You can also view conflicts in the context of a single application instance by selecting an application instance from the left sidebar. The application-specific view of the conflicts will only show issues regarding assets that are part of the selected application instance's deployment.

Warning: Conflict detection relies upon the contents of the target architecture, which is constructed from selected migration proposals and (in the absence of a selected proposal) automatic proposals. We strongly discourage resolving conflicts before the final migration proposal has been selected for each application instance which participates in the conflict. Resolving a conflict by introducing (or reusing) a Shared Component will change the content of the active proposals for all application instances participating in the conflict. If you later on decide to use a different migration proposal which doesn't make use of the shared component, you will create a new conflict again. This doubles the effort of resolving it. In order to ensure the best workflow, conflict resolution should be the last step before finalizing your target architecture.

In order to resolve a conflict you can click on "Resolve Conflict" to view your options. Txture resolves conflicts in the target landscape via Shared Components. In some cases, it is possible to directly create a new Shared Component from the conflict and resolve it in this way. In other cases, you may prefer to select an already existing Shared Component.

Once you have aligned all migration actions for an asset it will be removed from the list of conflicts and can be re-shown by selecting the "Show resolved conflicts" toggle switch.