Conflicts

Whenever multiple applications 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?

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

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

• Opting for different migration strategies for the applications 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 applications, 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 applications. 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 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.

Conflicts are not Errors

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. See the sections below on how to resolve them.

Not all conflicts are harmful

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 applications. In this case, we recommend to look closely at the utilization and downsize the individual deployments via right-sizing.

Detecting Conflicts

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

Not ALL migration proposals are considered for conflict detection

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

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.

The overview will show you the information required to resolve the issues. It lists all applications 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 applications 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 by selecting an application from the left sidebar. The application-specific view of the conflicts will only show issues regarding assets that are part of the selected application's deployment.

Do NOT resolve conflicts until you have selected your final migration proposals!

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 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 applications 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.