Cloudy with a Chance of Diamonds

To successfully transport an application to the cloud, it is not only the technical parameters and a functioning infrastructure that are crucial. It is much more important to consider all facets of the software and align it with the corporate strategy. adesso's analysis approach creates an overall technical and business picture that is essential for the sustainable and successful use of the cloud.

The adesso approach to adapting the cloud was presented in the blog post ‘Cloudy with a chance of Apps ’. This approach involves analysing applications and then migrating them to the cloud or modernising them. To check which options are available, a technical and business assessment is carried out as part of the analysis.

The technical assessment is tool-based and measures aspects such as CPU, RAM, utilisation and operating system version. The functional assessment is much more important because it also examines the software's task, conformity with company standards, criteria and pain points, and takes the corporate strategy into account.

The following analysis procedure was developed for this functional assessment:

As can be seen in the graphic, six different facets of the software are influenced by the corporate strategy (see centre). It is not only crucial where the application runs, but also what the operating processes look like. It is not only crucial what software is involved, but also what specific task it performs. It is not only crucial what the application's pain points are, but also that the options used are compliant. Only when all facets are given equal consideration can a consistent overall picture of the application be obtained.

Corporate strategy

The corporate strategy is shown in the middle of the graphic, as it influences all facets of the analysis. It defines the reason for the cloud, i.e. what goals are to be pursued with the cloud adoption. The applications must be subordinate to these goals or contribute to them, even if this runs counter to their own requirements.

If the goal is to relieve the burden on the operations team and thus use higher-value services and a great deal of automation, this must be taken into account in the analysis. If an application cannot use higher-value services or benefit from automation, it should not be moved to the cloud. This is because it will at best incur the same operating costs as before and thus not contribute to the business goal, as no improvement will be achieved.

If the goal is to strengthen customer loyalty, this can be achieved, for example, through improved and more stable operation, faster scaling and also more frequent updates with new features. All these points can be realised with modern cloud architectures. However, if the software cannot be adapted accordingly, it should be replaced or redeveloped to better fit the strategy.

Purpose of the software

The purpose of the software helps to assess why this application is needed, i.e. what problem it solves. This information is important in times of many alternatives and SaaS services because it often makes replacing software more attractive than migrating.

For example, if the customer has an on-premises backup solution, there is usually no need to migrate it to the cloud because the hyperscalers have backup solutions there. If it is a customised SAP system, there are special migration paths and landing zones that should be used. If the application is responsible for collecting and analysing data, a modern approach should be considered. For example, there are special data mesh architectures for data analysis and specialised tools for Azure in the form of Microsoft Fabric or Purview. In this case, only the data needs to be migrated, not the application.

Type of software

The type of software determines the degree of customisation options. Significantly more changes are possible with self-developed software than with purchased software.

A brief potential analysis should be carried out for self-developed software to determine whether cloud advantages can be used. If modernisation brings advantages for the cloud and is strategically desired, a modernisation concept can be created. This usually describes various adaptation steps with the respective costs and potentials. This enables the customer to select the desired target image precisely. These concepts require a considerable amount of analysis work, since interviews have to be conducted with the teams involved and the software has to be re-architected. Even though this analysis is more time-consuming and costly, the added value is enormous. Such a step is often worthwhile, especially for applications that directly influence the company's value creation.

The options are significantly more limited for purchased software. It is often possible to scale and improve automatically during operation, but it is usually not possible to convert to microservices or serverless technologies. However, high-quality services from hyperscalers can often be linked and integrated through simple configuration. This step saves infrastructure and operating costs. In addition, analysis and migration tools work well with purchased software, which speeds up the process.

Criteria

Criteria are non-functional requirements that determine the quality characteristics of the software. They may have changed over time and should therefore be re-recorded or reviewed. Some criteria have little influence on the architecture, for example usability, and are therefore only checked in exceptional cases. Other criteria strongly determine the future solution, for example efficiency or maintainability.

The efficiency criterion describes the system's behaviour when the load changes. Often, only as many resources as necessary should be used. Nevertheless, a quick response must be made when there are many requests and new resources must be provided automatically.

Reliability summarises the requirements for stable operation. The software should offer a correspondingly high level of availability and be able to continue to work or restart without problems even if subcomponents fail.

Security aspects aim, among other things, to improve access by, for example, adding multi-factor authentication to a legacy application or additionally encrypting data traffic. This also includes the traceability of changes, for example for audits.

One common reason for migrating to the cloud is to make it easier to maintain. This can be achieved by breaking up a monolithic structure or by switching to higher-quality services that offer a corresponding reduction in maintenance. A higher degree of automation can also contribute to better maintainability.

For many customers, a high level of portability is important. They want to avoid a vendor lock-in and be able to switch from one hyperscaler to another or to on-premises in a short period of time. Higher-value services are then rarely used, but rather containers and the corresponding managed Kubernetes services from the cloud service providers.

Compliance

As with the criteria, the compliance requirements may also have changed. This facet is not just about understanding the previous compliance and checking whether it still needs to be adhered to. It is also about adapting the application to the new compliance requirements that have arisen as a result of the cloud adaptation.

For example, what should the new SLA for the application look like in combination with the cloud landing zones and the SLAs of the cloud services? What guidelines apply to the applications in the cloud, for example, no public access and only in European regions? What are the disaster recovery requirements? The requirements are very different for each customer and can come from a wide variety of areas, such as security, business, operations, etc. Even if there are usually not that many significant requirements, the application must meet them in any case, which means that they have a major influence on the solution space.

Environment

When it comes to the environment, both the existing and the future environment are analysed. If the application is to run in the Azure cloud in the future, the corresponding services of the hyperscaler Microsoft can be used. The usability of cloud-native services such as Functions and App Service in Azure is also frequently checked. If the target environment is an OpenShift cluster, the usability of tools such as Red Hat Advanced Cluster Security or Argo CD is checked. The existing conditions imposed by the landing zones, such as the bandwidth for the on-premises connection, also influence the solution modules.

The existing environment is particularly relevant for tool selection. Depending on the environment, tools from hyperscalers or third-party providers can be used effectively. They help with the analysis and can also perform migrations later on. For example, VMWare environments can be analysed directly with tools from AWS and Azure. Other tools, such as those specifically for analysing databases, are often even automatically integrated or can be used in addition.

Infrastructure and operations

Here, too, it is worth taking an analytical look at whether the existing operational procedures and infrastructure can be adopted or adapted. On the one hand, proven concepts should be retained, but on the other hand, adaptation may be necessary.

Often, only technical feasibility is taken into account during migration, but not operations. On the one hand, this involves the operations team and their options, i.e. whether all the services of a hyperscaler can be used or whether a corresponding onboarding is still necessary. On the other hand, it also refers to the operational processes that have to be extended beyond the on-premise world into the cloud. This may require cooperation with other service providers or other operational teams.

The infrastructure looks at the actual structure of the application. Does the software have a database cluster? Does it have several front-end servers behind a load balancer? The technical analysis can provide details on this, but often not why the infrastructure was set up the way it was, what the communication flows and responsibilities are, and what the pain points are with the current setup. These points need to be scrutinised and, in the event of a possible transformation to the cloud, improved or, if appropriate, meaningfully reused.

Conclusion

A comprehensive analysis is required to successfully move an application to the cloud. This must take into account both the technical and process-related details of the application itself, the company's specifications and the future environment. The corporate strategy should always be the top priority and influence all the facets considered. Only by taking into account the corporate strategy and all the facets of the application can a very good target image be derived.

Would you like to learn more about exciting topics from the world of adesso? Then take a look at our previously published blog posts.

Also interesting:

• Cloudy with a chance of Apps