Allocate Distributed Costs in Target Cloud Application Portfolios

Taking into account the costs of a compute or database cluster can be challenging when simulating cloud target architectures. The typically high costs of cluster instances must be allocated proportionally to all associated resources to achieve cost truth on an application level. So far, the user had to take this into account - that changes with Release 28 where we leverage our concept of shared target architecture components, to derive proportional application cost.

Calculate and display proportional costs

To calculate and display proportional costs in Txture, we have introduced virtual costs and weights for sharing costs across multiple components as new concepts. The virtual cost is a ratio of the total costs based on resource utilization. This utilization is calculated by summing up RAM and CPU cores of all application components running on the cluster, taking the percentage of the available cluster resources. This is useful to indicate how well the resources of cloud cluster instances like e.g. for a VMware on Cloud deployment are leveraged across the dependent applications.

The screenshot below shows an example of a Google VMware Engine that is taken into consideration for calculating the cost of one of the applications and their components hosted on this cluster. The components that can be assigned to the application in scope only consume 2 percent of the cluster’s resources. Accordingly, only 2 percent of the total costs were passed on to the application. The cost per month shows the comparable virtual cost, whereas the light gray number below shows the actual total cost.

Example of a Google VMware Engine that only consumes 2 percent of the cluster's resources.

Cost distribution for all shared components

The concept of virtual cost and cost distribution applies not only for clusters, but for all shared components in the target architecture. In the screenshot below you see a shared component stack of a simple virtual machine, including provider, service and associated total cost.

Shared component stack of a simple virtual machine.

The application specific BOM in the screenshot below shows the very same shared virtual machine being utilized by a specific application (cf. green border). Resource requirements for this application are reflected in a weight, so that appropriate partial cost can be assigned and aggregated for this application. Other applications that leverage this shared virtual machine as well, are associated with the remaining cost automatically.

Cloud proposal containing the shared component (Amazon EC2 instance) from the example above

These new concepts help to lay out entire target application portfolios, reflecting application dependencies by acknowledging shared resource consumption. This greatly helps to determine optimal target architecture strategies and cost forecasting. Find out whether moving to individual VMs or a cloud-based compute cluster is more meaningful from an OPEX perspective or what cost to expect when operating larger sized shared databases.

Are your fingers tingling? That’s the urge to try out our new feature.
Feel free contact us for more information or support!