Shared Components

When transitioning to a cloud environment, optimizing resource sharing among multiple applications can prove highly advantageous. This strategic approach not only enhances operational efficiency but also generates substantial cost savings within the specific cloud ecosystem under consideration.

In some cases, databases (DBs) or similar components may need to be shared between applications. In such instances, it can also be highly beneficial to utilize shared components. Txture's cloud proposal capabilities encompass the incorporation of shared components, streamlining the cloud transformation process. When generating a Target Architecture for an application that shares components with others, solutions and potential conflicts are presented in the Conflicts menu.

This evaluation hinges on an in-depth analysis of each application's anticipated resource utilization, which is presented in the following screenshot. If an application utilizes only a small portion of the computational resources available, it becomes clear that modeling the underlying components as shared resources is a prudent decision.

Beyond resource utilization, the proposal also provides valuable cost predictions. By accounting for only the fraction of resources in use, it yields a significantly reduced monthly cost, as opposed to the full price displayed just below the shared pricing (in gray). This holistic approach ensures not only cost-efficiency but also strategic resource allocation.

Info:

As of now, the resource utilization as well as the reduced cost prediction is only shown for assets that are part of a compute cluster instance or a bare metal deployment.

Creating a Shared Component

While shared components in a deployment stack can be created in a manual process, the most common case is likely the presence of a so-called Conflict.

Creating Shared Components from a Conflict

Follow these steps to create a shared component from an asset existing in the AS-IS state and producing a conflict:

1. Navigate to the Transformation Cockpit and access the Target Architecture section. Enter the application mode by selecting the relevant application from the sidebar.
2. In the Conflicts card, you will notice the detection of a conflict. Click on Show Conflicts.
3. The shared asset(s) will be shown. Click on Resolve Conflict.

Info:

If you just imported your data, you might want to wait until the Target Architecture Asset Consolidation or the related Task Scheduling group has run for the first time. Conflict detection hinges on a completed run of this task.

In the next step, you are presented with three options:

1. Create shared component from migration action: This allows to use one of the replacements from a proposal involving this assets and apply it as a shared component.
2. Select existing shared component: Selecting this option will present you with a list of shared components that already exist and allow you to use it for this application as well.
3. Create new shared component from scratch Allows creating completely new shared components that can later be used in other application stacks too.

Regardless of your choice, after creating/selecting the shared component you will be presented with a list of applications that are part of the conflict. A checkbox allows selecting the applications where the shared component should be used in the proposal. Note that selecting an application here will select the default proposal with the addition (replacing the asset in question) of the shared component.

Watch the video below for a visual demonstration of the process. Please note that the user interface elements and layout may have evolved since the creation of this video, as the shared components feature is constantly improved.

Create a Shared Component That Is Non-existent in the AS-IS Scenario

You can create a new shared component that doesn't exist in the AS-IS scenario by following these steps:

1. Navigate to the Target Architecture tab and select Show Components in the Shared Components card.
2. Next, click on Create New Shared Component.
3. Provide a name for the shared component and select the appropriate product.
4. This newly created shared component can then be utilized as outlined in step 3 of the Creating a Shared Component section.

Automatically reusing Shared Components

Info:

This feature is available starting from Txture 41.

After you've created a shared component you can configure Txture to automatically consider using the shared component in future proposals. This means that also application stacks that do not have any conflicts with stacks can make use of these shared components. A common use-case for this functionality are shared infrastructure pieces that are provided by a central service within the organisation, such as e.g. a shared OpenShift cluster. If this is configured, a containerization proposal will automatically make use of the shared cluster. Note that this feature does currently not expand the resources of the shared component as more application make use of it and over-utilization could potentially occur.

The following steps allow automatically resuing Shared Components in proposals:

1. Make sure you have at least one shared component (either by creating it from scratch or from a conflict)
2. Adapt your cloud approaches to include the "Reuse Shared Components" cloud service strategy where needed:
3. In the "Technology" section of your Target Architecture Preferences, select the Shared Components that you'd like to be automatically proposed:

Managing and Editing Existing Shared Components

You can modify a shared component that you have previously created at any time. To do so, navigate to the general view of the Target Architecture tab in the transformation cockpit. The Show components button in the Shared Components card in the top right provides an overview over all shared components that you have created. Select any shared component from the list to view its proposal. Head to the Price & Bill of Materials tab to edit/change the cloud product(s). Click on the menu button to find the option for deleting a shared component.

Change the Weighting/Cost Attribution of a Shared Component

When two or more applications share a component, they may not utilize the shared component in the same proportion. To accurately reflect this disparity in cost attribution, you can modify the weighting of the shared component. By default, each shared component is assigned a weight of "1" per application.

To adjust the weight, follow these steps:

1. Navigate to a cloud proposal containing the shared component.
2. Click Edit Proposal located in the top right corner.
3. Modify the weight according to your preferences.

Calculating Cost Attribution:

Consider the scenario where a shared component is utilized by two applications, with a total cost of $100/month. By default, the weight of this shared component in each proposal is 1. The sum of the weights is 2, and each application attributes 50% of the total weights. This cost attribution for the shared component is then reflected in the cloud proposal as $50/month per application.

Now, let's continue with the same example, but this time, we change the weight of Application A to 4 while maintaining a weight of 1 for Application B. The total sum of weights is now 5. Application B attributes 1/5 of the weighting, resulting in associated costs of 20% of the total costs. Application A attributes 4/5 of the weight, equivalent to 80%.

Therefore, the updated cost attribution is $80/month for Application A and $20/month for Application B.