Product Update

Feature Update

All product updates
Cloud Target Architecture

Planning Optimal Cloud Application Portfolios in Two Steps

7min read
Share this article:
planning cloud application portfolio

Txture Cloud Transformation (CT) is the premier software solution to offer end-to-end assistance during a cloud transformation of an entire (or parts of an) application portfolio. Txture CT deals with portfolios that are both hosted on premises or already in the cloud, waiting for modernization.

The Txture CT process captures all phases of a transformation with a high degree of automation in mind. Starting with continuous data collection from multiple sources including e.g. existing CMDBs, Txture CT offers comprehensible cloud readiness, benefit and risk assessments of all your applications. This gives you the power to come up with the right choices regarding migration strategy and target landing zone.

In this article we outline how to perform migration planning activities for cloud target architectures that resemble an optimal future application portfolio. The baseline for starting to plan target architectures is usually the outcome of a multi-angle cloud assessment for all in-scope applications.

cloud assessment resultsFigure 1. Assessment results for individual applications and the portfolio are the baseline to move forward with confidence.

The cloud assessment in Txture CT presents you with an indication of feasibility and sheds light on topics like a migration strategy on top of the 6Rs and a target landing zone recommendation that includes public cloud service providers (CSP) as well as private cloud setups.

Given the assessment results, you have to come up with a strategy on how to leverage cloud for each single application of your portfolio. This strategy is translated into various application specific target architecture options that map your current technology stack to a cloud based one.

This resembles the first step towards an optimal cloud application portfolio:

Step 1: Application specific planning of a cloud target architecture.

Major efforts and time need to go into the actual migration planning. For every single application you have to select a CSP - in case you pursue a multi-cloud or hybrid cloud strategy. Your teams may state a preference towards a CSP due to existing skills and experience. Business may suggest a provider based on negotiated enterprise discount packages. In order to make a well-informed decision you need to look at detailed application level target architectures and a variety of alternatives that all leverage available cloud services on the market in different ways and combinations.

Obtaining alternative application target architectures is an important intermediary result, as it enables comparison of cloud cost forecasts and expected migration efforts. You may want to compare in detail and from different angles, a simple lift-and-shift where you only update server operating systems alongside more sophisticated and modern solutions that make use of containers and e.g. a provider managed No-SQL database.

Txture CT makes it easy for you to work on different target architectures for applications. It automatically generates various baseline proposals for you across providers and their offerings on all service models on the fly. This allows you to compare, discuss, adjust and decide on a way forward towards the actual cloud transition - see Figure 2. This gives you an enormous speed-up in the process as you can focus on quality discussions with the application owners and shortens the actual time-to-migration.

comparing alternative cloud application target architecturesFigure 2. Comparing alternative cloud application target architectures across different CSPs and service models.

Behind the curtains, Txture's cloud knowledge base is the foundation for this capability. As of today it manages roughly 250.000 cloud product variants, across all major cloud providers (currently 7) and their 200+ global data center locations. See Figure 3. for an excerpt. You can also access our cloud knowledge base via our free SaaS cloud comparison tool Cloud Insider.

vast cloud service catalogFigure 3. Vast cloud service knowledge enables automated baseline application target architectures. Excerpt from CSP managed relational database management systems

Useful activities directly supported by Txture CT for step 1, application specific target architectures, are the following:

  1. Application specific (and global) cloud preferences to guide Txture CT's baseline generated application cloud target architectures. This includes the selection of strategically relevant CSPs, narrowing or broadening geographical regions as potential hosting options, expressing regulations to comply with and much more.

  2. Baseline target architecture proposals for each application considering the aforementioned cloud preferences. This kicks off discussions regarding different cloud products and migration options by comparing benefits as well as potential risks and efforts.

  3. Optional adjustments to application target architectures by choosing from baseline alternatives and by tweaking cloud products, their sizing, pricing strategy and more - see Figure 4.

choose product variantFigure 4. Txture CT applies baseline sizing of cloud products based on collected data. Still each cloud product type and instance sizing can be tweaked as necessary.

Once you have obtained a set of target architectures for all individual applications in Txture CT - whether they are still drafts or already finalized, you need to change perspective to an application portfolio level of view. This resembles the second step towards an optimal target cloud landscape:

Step 2: Portfolio level consolidation of application cloud target architectures

In step 1 we came up with cloud targets for individual applications with the support of Txture CT. In this past step we did not yet look into dependencies between individual applications. Dependencies usually happen to exist on different architectural levels:

  • Overlapping or redundant support of business capabilities e.g. due to partially duplicate application portfolios after a merger. This usually requires retiring or reconciling applications for an optimal portfolio.

  • Tightly coupled data communication on application or application component level. Software components in an application stack may require low-latency data exchange with a component of a different application. Such a data exchange might be achieved easiest within the same cloud setting, whether in a public or private cloud environment.

  • Sets of applications sharing both certain technical components like databases, API-gateways, etc. as well as IT infrastructure like single servers or compute clusters. This scenario requires analysis of whether applications will need to share those components after the cloud transition or not.

For handling such cross application dependencies Txture CT suggests to reiterate step 1 and adapt individual application target architectures so that they fulfill overarching goals of the new cloud based portfolio.

You can easily spot dependent applications by making use of Txture CT's flexible reporting mechanisms. See Figure 5. for exemplary reports that help identify application re-evaluation targets.

cloud application cluster by business capabilityFigure 5. Application clustered by business capability (left) and indicating communication paths (right).

For identifying shared technical or infrastructure components in deployment stacks of different applications, Txture CT is capable of analyzing conflicts in the applications' cloud target architectures. Figure 6. shows two applications that share a common server and another two applications that share a database.

Whereas the database in this example is marked as a shared component between the two application in the cloud target (cf. the same replacement using AWS RDS), the virtual server has been replaced by different cloud products for each application separately in step 1 (cf. the use of AWS EC2 and Google Cloud GCE).

Having separate deployments using different CSPs and services is a valid option and can be explicitly decided based on a subsequent analysis. On the other hand you will likely have central components, e.g. authentication providers, certain databases, compute clusters (on virtual machine level like VMware or on container level like Kubernetes). Those can be marked as shared components explicitly in Txture CT, which advises for a consolidated cloud target portfolio offering a realistic cost perspective.

shared cloud componentsFigure 6. Automatic detection of shared components and potential cloud target conflicts.

Benefits of using Txture CT and its two step planning approach

Txture CT's reporting and automation capabilities greatly support the cloud migration planning phase. Leveraging automatically generated cloud target architectures, as well as analysis and management of shared components for all applications in your portfolio, will boost your cloud journey enormously.

From applying Txture CT's best practice approach you gain

  • quick transparency over your application estate,
  • immediate decision options for your applications' cloud move,
  • continuous architectural level control and
  • realistic cloud portfolio cost forecasts (see Figure 7. for an overview).

Txture CT is the end-to-end cloud transformation platform that provides full fledged cloud application portfolio planning, all in a central place. Gain speed and take out the risk in your journey to cloud by making use of flexible data collection abilities, automated cloud readiness assessments and support for both application and portfolio level cloud target architecture planning.

cloud portfolio and cost forecastsFigure 7. Consolidated cloud application portfolio with cloud cost forecasts for all applications and considering shared components.

Seeing is believing! Feel free to request a demo or contact us for more information!