Target Architecture Preferences
Your Target Architecture (TA) Preferences (Main Menu / Transformation Cockpit / Target Architecture / Target Architecture Preferences) are taken into consideration for calculating Cloud Proposals for your target architecture.
Target Architecture Preferences can be set globally or for each application separately. Preferences can also be managed in groups. The local preferences take precedence over global or group ones.
In the following, the different Target Architecture Preferences are explained:
- Cloud Provider and Service Strategy
- Location and Landing Zone
- Payment
- Technology
- Rightsizing
- Compliance
Cloud Provider and Service Strategy
Strategic Cloud Provider
The Strategic Cloud Provider is your cloud provider of choice (you can also specify more than one). Only the listed providers will be considered when computing cloud proposals. If no provider is given, all providers will be considered.
The list of providers that can be added using the Add button is extracted from the Txture Taxonomy. If there are multiple strategic cloud providers, you can rank them with the sliders next to them. The ranking of the providers influences the scoring of the resulting cloud proposals.
You can set discounts for providers. This can be useful if your organization has some enterprise discounts and you want to take that into account. When computing cloud proposals, Txture will take into account discounted prices.
Service Model (deprecated)
Service Model has been phased out from version 40 on and replaced by Cloud Approaches.
Cloud Approaches
The Cloud Approaches settings enables the user to speciy which approaches Txture should produce cloud proposals for. The Weight option allows the user to specify the ranking weight of proposals generated by an approach.
Cloud Service Strategies
One cloud approach consists of one or several Cloud Service Strategies. The user can add primary and fallback cloud service strategies:
- Primary strategies are used first to generate proposals. At least one of the primary cloud service strategies needs to be responsible for an asset mapping to have it count as a proposal for this cloud approach.
- Fallback strategies are used if no primary strategy can be used.
The set of Cloud Service Strategies is predefined and consists of the following:
| Cloud Service Strategy | Description |
|---|---|
| Lift and Shift | Moves infrastructure to the cloud (IaaS) while keeping migration effort as low as possible. |
| Managed Services | Utilize managed services in the cloud (FaaS, PaaS) to reduce management efforts. |
| Serverless Container Platforms | Utilize fully-managed container platforms for deploying and scaling serverless microservices. |
| Container Orchestration | Utilize container orchestration engines in the cloud (CaaS) for enhanced management capabilities. |
| SaaS | Replace existing self-managed software with hosted SaaS solutions. |
| Cloud Runtime Platforms | Utilizes fully managed application and container runtime environments in the cloud to reduce infrastructure maintenance to a minimum for entire stacks. |
| Like for Like | Replaces individual assets with directly or closely matching cloud service of target cloud service providers. |
Restrictions
In addition, there is the option to limit the scope of a cloud approach to individual assets, operating systems, or technologies, by using the Restriction menu. For example, you may choose to use the Managed Services strategy for Databases and Load Balancers, and the Lift and Shift strategy for all other assets.
Default Approaches
One cloud approach can now contain an arbitrary number of Cloud Service Strategies and can be completely customized. Txture provides the following list of predefined Default Approaches (which can also be adjusted to your liking):
| Cloud Approach | Description | Execution Order of Cloud Service Strategies |
|---|---|---|
| Lift and Shift | Leveraging cloud IaaS for replacing on-premises or cloud compute and storage. Relevant e.g. in data center exit scenarios where migration effort needs to be kept low and timing is crucial. | Lift and Shift |
| Managed Services | Using fully managed services for application components to reduce deployment and maintenance overhead to a minimum. If no managed services can be proposed, IaaS is used as fallback. | Managed Services Lift and Shift |
| Containerization | Utilization of containers and container engines for running application components and obtaining modern workload management. Relevant to improve deployment and development agility of applications as part of a modernization effort. If no containerization can be proposed automatically, IaaS is used as fallback. | Serverless Container Platforms Container Orchestration Lift and Shift |
| Modernize | Utilization of the full cloud service catalog to modernize application stacks, including cloud application runtimes, containers and managed services. IaaS is used as a fallback, if no such modernization strategy can be executed automatically | Cloud Runtime Platforms Serverless Container Platforms Managed Services Container Orchestration Lift and Shift |
| SaaSify | Leveraging SaaS software that is commercially available, as a replacement for any existing application technology. | SaaS |
| Like for Like | Replaces individual assets with directly or closely matching cloud service of target cloud service providers. | Like for Like |
Custom Approaches
You can also specify your own Custom Approaches starting from scratch. This gives you the flexibility to choose any number of individual Cloud Service Strategies and their order.
Sustainability
Txture calculates the expected CO₂ emissions and energy consumption per cloud proposals. With these settings you can define how important it is for you to keep the carbon footprint of selected cloud products as low as possible.
Prefer 100% Cloudification
This setting allows you to show only proposals that don't contain any "Retain" options. If not a single proposal could be generated for which this is the case, also proposals with less cloudification are shown.
Location and Landing Zone
Landing Zone
The Landing Zone limits the cloud provider selection to a specific landing zone. You can prefer or require a specific landing zone or simply don't care about it by setting the landing zone to neutral. The current provider landing zones are public cloud and private cloud.
Allowed Location
This setting allows you to choose your allowed target locations. You can select an individual data center, or an entire region such as a country or a continent. Only the listed data centers and data centers within the listed regions will be considered. If no location is given, then the European Union will be used by default. As with strategic cloud providers, you can rank the given locations with the sliders next to them, influencing the cloud proposal result ranking.
Prefer AS-IS Asset Locations
If you defined the location for the asset of your AS-IS application, Txture will try to find cloud products in data centers as close as possible to the original location. If the defined location are not within the configured allowed locations, a new location within the allowed locations will be chosen.
Government Regions
The Restriction of regions setting allows you to filter your target data centers. You can choose that proposals are generated for No Government regions or Only Government regions. If you are not sure about them yet, it's also possible to not set any restriction. By default, the Government regions are excluded.
Payment
Product Discount
This setting allows to define custom discounts for certain cloud products, for example “Amazon EC2 - 10%” or “Cloud SQL for MySQL - 15%”. It is possible to configure multiple discounts for different cloud products. Generally, product discounts have priority over provider discounts. This means, if a product discount applies, an overall provider discount does not apply for this particular cloud product replacement.
There are a few price items that are not discountable, such as Windows Server license fees. These are unaffected by both provider and product discounts.
Price
The Price determines how much impact the monthly cost has on the ranking of a proposal:
- Not important: Do not consider the monthly costs for the ranking of proposals.
- Desired: Prefer solutions with smaller monthly costs (even though e.g. the migration effort may be higher).
- Important: Strongly prefer solutions with smaller monthly costs.
- Very important: Put a very strong emphasis on solutions with smaller monthly costs during proposal ranking.
Cloud Pricing
Cloud pricing is a complex topic, and it is not always possible to directly compare offers from different vendors. Txture compares cost estimates on a best effort basis. Also, for the purpose of the price preference, Txture will only consider on demand instance prices with bring-your-own-license (BYOL) contracts.
Duration of Binding
This setting allows you to pre-select the desired pricing terms with respect to the duration of binding for automatically generated proposals. If the selected setting is not available, the closest matching duration option with a shorter binding is selected.
Payment
The Payment allows to pre-select the desired pricing terms with respect to upfront payment for automatically generated proposals.
Technology Licensing Options
coming soon
Custom Line Items
This setting allows increasing the cost of each proposal by a fixed amount or percentage value of the total cost of the proposal.
They can be helpful to realize a more realistic overall cost by adding e.g. HR-costs for management or similar costs that are independent of the actual cloud cost.
Calculation: All percentage values are calculated from the total cost of the proposal without any further line item.
Technology
CPU Vendor
This setting allows you to set a preference for a certain CPU vendor for virtual servers and some select databases. Cloud proposals that contain instances with CPUs of the preferred CPU vendor are ranked higher.
Processor Preference
This setting allows you define the desired characteristics of the processor if multiple product instances match the resource requirements. We currently support three options, i.e. cost effective, balanced, and performance oriented:
Cost effective
- The right-sized instance with the lowest price is selected.
- If the prices are the same for multiple instances, the one with the better CPU thread performance is selected.
Balanced
- The right-sized instance with the best cost performance trade-off is selected (CPU performance per dollar).
- Dev-optimized instances are ignored.
Performance-oriented processors
- The right-sized instance with the best CPU thread performance is selected.
- If the performance scores are the same for multiple instances, the one with lower price is selected.
- Dev-optimized instances are ignored.
Technology Replacements
The Technology Replacements allow to virtually modify the technologies of the application stack and the automatically generated proposals. There are multiple options available for defining such rules:
Technology Selection
- By Technology: An actual Technology from the Cloud Knowledge Engine can be selected and the rule is valid for all sub-technologies and cloud products of selected technology. For example, if "MySQL" is selected, the rule will be considered for all MySQL versions.
- By Technology Vendor: The Technology Vendor can be selected and the rule is valid for all technologies and cloud products of this vendor.
Replacement Action
- Auto: If a very generic rule is not applicable for one of the sub-technologies, this action allows to invalidate the action of the more generic rule. For example, if "MySQL" is selected and an action besides "Auto" is assigned, but for "MySQL 8.0" this action is not desired, then an "Auto" action for "MySQL 8.0" allows to invalidate the action for "MySQL".
- Avoid: The selected technology (and sub-technologies/cloud products) should not be part of an automatically generated proposal
- ReplaceWith: This action allows to pretend that the selected technology (and sub-technologies/cloud products) is the one you choose for this action. For example, if during the migration all servers with "Microsoft Windows" operating system should be migrated to servers with "Linux" operating systems, then a By Technology combined with a ReplaceWith action will allow to generate the desired proposals.
Preferred Technologies
The Preferred Technologies allows to rank proposals that contain one of the selected technologies (or sub-technologies/cloud products) higher by a separate score that is only evaluated if at least one preferred technology is given.
Storage Access Type
This setting allows you to specify a preferred Storage Access Type for object storage mappings. The Storage Access Type "Hot" is associated with higher storage costs and should be selected for frequently accessed data. "Archive" causes the lowest storage costs but possibly higher retrieval costs and should therefore only be selected for data archiving and backups.
| Storage Access Type | Description | Storage Cost |
|---|---|---|
| Hot | Best IO performance for frequently accessed data | $$$$ |
| Warm | For infrequently accessed data with a minimum storage duration of 30 days | $$$ |
| Cold | For infrequently accessed data with a minimum storage duration of 90 days | $$ |
| Archive | For rarely accessed data (data archiving and backup) | $ |
In addition to the storage costs, the different Storage Access Types usually also lead to different data access costs, which are, however, vendor-specific and cannot be described in general terms.
Storage Disk Type
The Storage Disk Type lets you choose between "SSD" for better overall performance and "HDD" for greater cost efficiency.
Storage Redundancy
The Storage Redundancy setting allows you to specify your preferred option for protecting against the failure of a drive or an entire data centre. For choosing the most suitable redundancy option the tradeoff between lower costs and higher availability should be considered. You can choose between "Local", "Region" and "Global". Selecting "Local" is the most cost-effective option, while "Global" ensures the highest availability.
Default Size of Persistent Storage
Most server products in the cloud require a separate booking of persistent storage (volume).
For servers of the as-is landscape that don't have a persistent storage attached, the automatically generated proposals will add a storage element with this default size, if not annotated on the server itself.
If no default-storage is desired, this setting can be set to 0.
Technical Similarity
The Technical Similarity determines how much impact the migration effort has on the ranking of a cloud proposal. Select "Very important" if you want to reduce migration effort. Select "Not important" if you want to invest more into optimization towards cloud-native solutions.
- Not important: Do not consider the migration effort for the ranking of proposals. Allow all possibilities to achieve optimization towards cloud-native.
- Desired: Prefer solutions with small migration effort (even though e.g. they have higher cost of ownership).
- Important: Strongly prefer solutions with small migration effort.
- Very Important: Put a very strong emphasis on solutions with a small migration effort during proposal ranking.
Rightsizing
CPU, Memory and Storage
There are different modes for CPU, memory and storage rightsizing.
For certain asset types, CPU, Memory and Storage scaling factors can be defined.
Within the rightsizing settings, you can choose whether or not to take these scaling factors into account.
If you choose to consider the scaling factors, you can add a margin to the asset scaling factors and define a default for missing values.
In the case of missing values, the margin is not added and the Default factor is used as is.
If you choose to not consider the asset scaling factors you can define an Overriding factor that is applied to all assets.
By setting the Overriding factor to 100% you achieve "equal-sized" instances.
Example: Virtual Server, 8 CPU cores, 0.5 CPU scaling factor
- Scenario 1: Consider asset scaling factor, added margin of 0% 4 CPU cores
- Scenario 2: Consider asset scaling factor, added margin of 25% 6 CPU cores
- Scenario 3: Do not consider asset scaling factor, overriding factor of 100% 8 CPU cores
- Scenario 4: Do not consider asset scaling factor, overriding factor of 150% 12 CPU cores
These scenarios can also be applied to memory and storage right sizing.
For more details you can look into the Rightsizing documentation.
Instance Downsizing
This setting allows you to reduce the CPU and RAM size of instances to be considered as replacement candidates in cloud proposals.
Use a value of 0 if the current sizing requirements of an instance have to be fulfilled entirely.
For example, if you have a 10-core machine and allow down-sizing by 20%, then machines with 8 cores or more will be considered.
The storage size isn't considered by this setting. If CPU or RAM scaling factors on the asset are considered, both the scaling factors from the asset and the Instance Downsizing factor are applied.
Processor Performance
This setting allows you to specify whether the right-sizing of cloud product instances based on performance benchmark data of their underlying processor is enabled.
If enabled, Txture assesses the processor performance of the currently used instance based on CPU benchmark data and aims to select an instance with equal or better CPU performance. This approach does not rely direclty on the number of CPU cores for finding replacements, allowing the selection of smaller instances with superior performance. When multiple product instances meet the resource requirements, the Processor Preference setting guides the selection process.
Example: Virtual Server, 8 CPU cores, 5.6 CPU performance score
- Scenario 1: Virtual Server is replaced with a slower instance that is larger (e.g. 16 CPU Cores, 8.2 CPU performance score)
- Scenario 2: Virtual Server is replaced with a faster instance that is smaller (e.g. 4 cores, 5.8 CPU performance score)
- Scenario 3: Virtual Server is replaced with the same instance (8 CPU cores, 5.6 CPU performance score)
Compliance
Certification Requirements
For regulated industries it is often required to use cloud services that fulfill specific certification requirements. These settings allow you to add a number of certifications and set whether it is desired or a must for each one. Among the provided certifications are BSI C5, PCI DSS and a growing number of others.
SAP Certification Requirements
Similar to the above, you can also choose a number of SAP certifications and set them as required. Among the provided certifications are HANA, Hybris and others. For now SAP certifications are only supported for IaaS product instances, hence if must is chosen, then only the IaaS replacements are affected by that choice.
Vendor Lock-in
Txture assigns most cloud products a score for their likelihood to lead to vendor lock-in. With this setting, it is possible to change the impact of the vendor lock-in value on the proposal rating. It provides three settings:
- Permitted: No precautions against vendor lock-in are taken.
- Avoid if possible: If products without vendor lock-in are available, these will be preferred over products with vendor lock-in.
- Avoid strictly: No products with vendor lock-in will be permitted in cloud proposals.