Application assessment: how to get applications into the cloud?

Application assessment

Application assessment can be simplistically understood as the process of assessing the existing environment and existing applications. It is based on the systematic and documented collection of information about the existing environment and its evaluation with a view to transformation to a cloud environment.

The beginning of this process is a high-level analysis of applications, during which we identify all the conditions for the transfer to the cloud.

High level analysis

Where are the applications in their lifecycle, how are they licensed and what technologies do they use? During high-level analysis phase, we classify applications according to common characteristics and usually divide them into three main groups:

• Legacy = older applications that will likely require refactoring of the source code, which is often more expensive than re-developing the application in a modern way.
• Cloud ready = applications can usually be moved without major modifications to IaaS/PaaS services.
• Cloud aligned = applications developed architecturally as microservices (Openshift, Kubernetes).

Further sorting of applications

After we have basic data on application units from high level analysis we can start with the next phase. It is now a good idea to look at all applications and their environments from an architectural perspective. For example, we may find that some applications cannot be migrated because of the technology or hardware key used.

It is important to remember that each application runs on multiple environments depending on whether it is developed in-house, outsourced, or a boxed solution. Typical environments are production and test environments, in case of in-house development also DEV environment or UAT. Each environment has a different criticality and a different need for availability.

Further sorting can be done according to the following rules:

• What can be migrated easily (simple migration) = typically small applications on cloud supported technologies.
• What will be more complex (more complex migration) = larger applications with many integrations and dependencies.
• What not to migrate at all (migrations that can’t be done) = due to unsupported technologies, or perhaps nearing the end of the lifecycle.

Applications should be viewed as application units that have linked data and integrated interfaces. Usually, these units migrate together and cannot be separated by infrastructure. One showstopper can block the whole application.

After the basic classification of applications into an overview, we need to analyse each application in detail in order to properly design the new architecture of the application in the cloud environment.

Detailed application analysis

Detailed analysis of the application is essential for future architectural designs in the cloud environment. First, we need to identify all application and technology components and their sizing. What must we not forget?

• Detailed application architecture – precise description and sizing of individual components and environments.
• Integrations and their data flows between individual application components and other applications (for example, casting data to a data warehouse is a transfer-intensive operation).
• Authentication – how is user access to the application authenticated, are they accessing it from the internal network or from the “outside”?
• Is the application built to be highly accessible, i.e. everything redundantly, and what SLAs do they have to meet?
• Is the app part of the DR strategy?
• General security and compliance requirements, meeting standards like ISO27001 or NIS , implementing your own data encryption keys, etc.
• Licensing of the application and its components – verify how your own application is licensed, this can often be different in the cloud. For operating systems and databases, in general, if I have an active contract and pay for software assurance, I can use the license in the cloud. In the case of MS Azure, this service is called Azure Hybrid benefit for Microsoft licenses. Other cloud platforms use the term BYOL  (Bring your own license).
• TCO – the cost of running services, licenses, support and the cost of consuming hardware resources.

There can be significantly more things to analyse depending on the complexity of the application being migrated and the size of the company. For example, in the banking environment, high demands are placed on the compliance and security targets. Those who address the architecture of the environment and have documentation of the existing state have an advantage.

After the application analysis, we move on to the design of the target architecture, where we propose several possible scenarios and then evaluate them.

Application architecture

We design and architect the application with the use of cloud services in mind. It is often worth looking to see if the application exists as SaaS, i.e. all as a service. In the basic division we distinguish the following transition variants:

• Lift and shift – I move everything as it is. Usually as IaaS – this is the fastest way to migrate an application, but often the least suitable in terms of cost and does not bring any innovation.
• Replatform – in the cloud I replace Windows with Linux, MS SQL with PostgreSQL, etc. according to the supported application options. We can also consider using platform services, especially for database applications that need higher guaranteed availability and robustness.
• Rearchitecture – application redesign using platform services such as Redis Cache or replacing message queuing with Azure Service Bus. Modern applications that are containerized and evolved (e.g. Microservices architecture) can be deployed to AKS or Azure web application services.

Example: the Azure web server reference architecture (Source: https://docs.microsoft.com/cs-cz/azure/architecture/reference-architectures/app-service-web-app/scalable-web-app)

When planning, we concentrate the components that communicate intensively with each other in one location so that a large amount of data does not flow over the VPN links (especially outward from the cloud). In general, copying data into the cloud is free, taking data out costs you money.

In addition to data volume, latency can be an issue with a large number of operations. Every extra millisecond plays a role, which can cause the application to slow down significantly.

In the final design of the application architecture, we usually assess several options according to specified criteria (including prices) and proceed to the TCO calculation.

TCO: what will it actually cost me in the cloud?

TCO is based on the chosen architectural option. In general, “If I leave it as it is (lift and shift), it will be more expensive, but faster to migrate and without the need for major modifications.”

Options using platform services, which can have high availability and allow vertical and horizontal scaling on the fly, are better value for money. Here we can better work with possible peaks or, on the contrary, with dead periods, i.e. adapt the application to the operational load according to the current need. We generally get better value for money than if we build highly available services ourselves on our own HW and SW.

Another option is to reserve funds usually for 1-3 years, where the cost can be less than half of the standard pay-as-you-go (PAYG). By default, a combination of reservations and PAYG is used depending on the type of workload and the length of the service run per month.

Computational tasks that do not require immediately available hardware can be placed in the low priority tier. Such hardware is not guaranteed to start immediately, but its price can be up to 50% lower.

In the case of comparison with the existing operation, it is necessary to add the costs of electricity, UPS, diesel aggregates, cooling technology, fire extinguishing, security, etc. according to the size of the organisation.

After evaluating the TCO and weighing all the pros and cons, we proceed with the actual migration of the application.

Migration of applications to the cloud is an ongoing trend that will continue in the near future. When performing your migration it is worth targeting provider platform services that give you added value. Most of the time you will have the benefit in form of higher availability and dynamic scaling that was not achievable with on-premises setup.

Application that will benefit the most from the cloud move are the ones that have been created on-premises but with cloud principles in mind (eg. as Microservices architecture). They will profit from additional flexibility and development speed producing less cost at the same time. 

Other benefits of the cloud include the immediate availability of HW in case of a need to extend the service. In the modern day you might also need specific HW with graphics acceleration of industrial cards for your upcoming AI workloads.

There is always the case of added value of staying compliant and supporting various standards and norms. It can be way easier to meet the most rigorous security, compliance and governance requirements in the cloud than in your own data centre.

From a financial point of view, it will be more interesting to move from the purchase of assets to the purchase of services, i.e. to OPEX instead of CAPEX.

Migrating to the cloud is not a one-time project but a journey. 

Contact our experts to find out how to do it right!