Application assessment: how to get applications into the cloud?

 

Go through the basic steps to easily and efficiently transfer your applications to the cloud.

Lukáš Hudeček

 

In this article, I’ll introduce you to the basic steps and options to easily and efficiently migrate your applications to the cloud. And what good will that do you? With a thorough analysis and architecture design based on it, you can achieve cost savings, application modernisation, higher availability, better security and greater application flexibility in the cloud.

 

In most companies thinking about moving to the cloud, it first starts with a top-level management presentation. In the presentation, I have a diagram on the second slide with the applications in my server room. Then the 3rd and 4th slides follow, where the applications are already migrated in the cloud, which I comment by saying: “You can just copy and drop that.” On the 5th and 6th slide, I present a straightforward multi-cloud strategy design, moving applications between Azure and Amazon with a note: “I’m not going to depend on one provider.”

But it’s not that simple. Without proper preparation and planning, migrations usually end in annoyed users, budget overruns and application rollbacks. Let’s show step by step how to properly perform an application assesment.

 

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.

At 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? In high-level analysis, we classify applications according to common characteristics, usually 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 native = applications developed architecturally as microservices (Openshift, Kubernetes).

 

Further sorting of applications

We have basic data on application units from high level analysis. 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 blocks the whole application.

After the basic classification of applications into an overview, we need to analyze each application in detail in order to properly design the design and 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 ISO27001 standards or 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 analyze 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 part. 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.

 

 

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, I copy data into the cloud for free, copying out is charged.

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.

 

 

Application migration

After analyzing the application, selecting the target architecture, calculating the TCO and evaluating that it all makes sense (in terms of all the set criteria), the application migration planning follows.

It usually starts with a TEST or DEV environment. After the test migration, evaluation and testing takes place, either by the users themselves or by automated tests that check for correct functionality or generate load tests. Testing will be more challenging when migrating to a different type of service and deploying in High Availability (HA) or scaling in traffic.

 

Here it is possible to use a product for deploying the environment in the form of IaaC, i.e. I have the whole environment described in code (Github, Jenkins, DevOps). Or I’ll use a tool to manage testing, execute test scenarios and evaluate them (DevOps).

This cycle is repeated and evaluated after all environments have been migrated as planned. Then the production environment is handed over to Operations.

 

 

In conclusion, I would like to say

Migration of applications to the cloud is a recent trend and it is worth targeting platform services that have added value in the form of high availability and scaling during operation according to various parameters.

The biggest advantage are modern applications that have already been developed (such as Microservices architecture), they work very well for example in a Kubernetes cluster, where their components can run simultaneously side by side.

Other benefits of the cloud are the immediate availability of HW in case of a need to extend the service or the availability of HW with graphics acceleration of industrial cards (which are in short supply on the market due to cryptocurrency mining).

We also see added value in supporting various standards and norms where it can be easier to meet various security, compliance and governance requirements.

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.

However, before you embark on the migration phase, you need to pay attention to the readiness of the cloud environment to meet all security, compliance governance parameters. But that’s a topic for another article.

 

This is a machine translation. Please excuse any possible errors.