Application assessment: how to get applications into the cloud?

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 it do you? With a thorough analysis and architecture design built on top of it, you can achieve cost savings, application modernization, 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, migration usually ends up annoyed users, budget overruns and rollback of the app. Let's show step by step how to correctly perform 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 transforming it into a cloud environment.

At the beginning of this process is a high-level application analysis, where 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 are they using? In high-level analysis, we categorise applications according to common characteristics, usually into three main groups:

• Legacy = older applications that are likely to 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. Now it's a good idea to take a look at all the 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 environmentsdepending on whether I develop it myself, contractor or boxed solution. Typical environments are production and test environments, and in the case of in-house development, DEV environments 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 will migrate Simply (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 won't work not migrate at all (migrations that cannot be performed) = due to unsupported technologies, or perhaps approaching the end of the lifecycle.

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

After the basic classification of the 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 application analysis 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 into a data warehouse is a demanding operation from the point of view of transfers).
• Authentication - how is user access to the application authenticated, are they accessing the application from the internal network or from the "outside"?
• Is the application built to be highly available, i.e. all redundant, and what SLAs must it meet?
• Is the app part of the DR strategy?
• General requirements for security a compliance, 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, generally if I have an active contract and pay 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 licence).
• TCO - the cost of running services, licenses, support and the cost of consuming hardware resources.

There may be significantly more things to analyze depending on the complexity of the application being migrated and the size of the company. For example, in a banking environment there are high demands on the compliance and security part. Those who address the architecture of the environment and they have documentation of the current state.

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 the design and architecture of 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 then distinguish the following transition variants:

• Lift and shift - I'm moving everything as is. Mostly as IaaS - this method is the fastest for application migration, but often the least suitable in terms of cost and does not bring any innovation.
• Replatform - in the cloud I will replace Windows for Linux, MS SQL for PostgreSQL, etc. according to the supported application capabilities. 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 in AKS or to Azure web application services.

When planning, we concentrate components that communicate intensively with each other in one location so that large amounts of data do not flow over 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 significantly slow down the application response.

In the final design of the application architecture, we usually assess several options according to the 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."

Financially, they're better off variants using platform servicesthat can have high availability and allow vertical and horizontal scaling on the fly. Here, we can better handle any peaks or dead periods, i.e. adapt the application to the traffic load according to the actual need. In general, we achieve better value for money than if we build highly available services ourselves on our own HW and SW.

Another option is Reservation of funds usually for 1-3 yearswhere the cost can be less than half of the standard pay-as-you-go (PAYG). A combination of bookings and PAYG is used as standard, depending on the type of workload and the length of service run per month.

Computing tasks that do not need immediately available hardware can be placed in the low priority tier. Such hardware is then not guaranteed to run immediately, but its cost can be up to an additional 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, firefighting, security, etc. on the side of the server room itself, depending on the size of the organization.

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 set criteria), the following is application migration planning.

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 (load tests). In the case of a service migration and deployment in High Availability (HA) or when scaling up in traffic, testing will be more challenging.

Here it is possible to use some 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 use a tool to manage testing, execute test scenarios and evaluate it (DevOps).

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

In conclusion, I would like to say

Migrate applications to the cloud is a recent trend and it pays to target platform services that have the added value of high availability and scaling during operation according to various parameters.

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

Other benefits of the cloud are immediate availability of HW if needed to expand the service or 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 support for various standards and normswhere it may 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. moving 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.