Investigating the Cloud Readiness of a Software Application

17. September 2018

As more and more software applications are operated in the cloud, stakeholders of applications originally developed for another platform wonder how they can make their application cloud ready. This article describes how we answer this question by analyzing cloud smells on code level and cloud requirements on architecture and infrastructure level during a software audit.

Several customers have asked us recently to analyze the cloud readiness of their code base which was originally developed for another target platform such as the (Windows) Desktop. They wanted to know whether their application could be operated in a cloud environment, which problems may occur and which actions they should take to make their application cloud ready.

We approach these questions in our CQSE software audits in two ways: First, we employ static analysis and manual code reviews to identify cloud smells in the code base, i.e. potentially risky code constructs regarding cloud deployment. And second, we employ interviews with different stakeholders to investigate whether the application meets requirements regarding the targeted cloud infrastructure.

Cloud Readiness on Code Level: Cloud Smells

»Smells« in general denote constructs in source code which should be analyzed and revised. Originally, the term was introduced for code constructs which should be refactored because of bad structuring [1]. In this spirit, »cloud smells« indicate code constructs which should be analyzed and revised because they are not appropriate in a cloud environment or their usage in a cloud environment is risky.

Examples of cloud smells are:

MessageBox.Show("Hello user!", "User Message", MessageBoxButtons.Ok);

Showing a message box to the user is possible in a Desktop environment but usually not possible in a cloud environment.

System.Media.SoundPlayer player = new System.Media.SoundPlayer(myWavFile);
player.Play();

Playing sound is possible in a Desktop environment but usually not possible in a cloud environment.

string path = @"c:\index.html";
if(File.Exists(path))
    Process.Start("iexplore.exe", path);

Starting sub processes is possible in a Desktop environment but should usually not be done directly in cloud environment. If it is done, the corresponding code pieces should be reviewed to ensure that they work (also) in a cloud environment. Furthermore, hard coded file names or paths usually work in a Desktop environment but not in a cloud environment.

Further examples of cloud smells are usage of public and static variables (which might preserve state between two service calls and thereby lead to wrong results), accessing the Windows registry or other Windows specific resources (which hinders operation on a Linux machine), or explicit thread management (which usually should be left to the cloud infrastructure).

The following figure summarizes cloud smells that we consider in the cloud readiness analysis:

Overview of Cloud Smells

As a first step, we use static analysis checks implemented in Teamscale to identify cloud smells. Afterwards, we manually review (a subset of) the code smells found by Teamscale to validate their correctness, identify generic and risky programming patterns and analyze aspects which cannot be addressed with static analysis alone.

Cloud Readiness on Architecture and Infrastructure Level: Cloud Requirements

Applications to be operated in a cloud environment have to meet certain requirements to ensure that they can be built for and deployed into the targeted cloud infrastructure. Obviously, these cloud requirements differ depending on the targeted cloud platform, e.g. a public cloud of a big cloud provider or a self-hosted cloud. Hence, we usually collect a list of cloud requirements that apply to the application by analyzing documentation of cloud platform providers and conducting interviews with cloud operation people. Then, we study whether the application meets the cloud requirements by conducting interviews with developers of the application.

Without a specific application or cloud context, the factors described in The Twelve-Factor App are a good starting point for a list of cloud requirements. Here is a summary of each factor:

ID	Cloud Requirement
I	Codebase: The application has one code base which is tracked in revision control and has many deployments to different stages.
II	Dependencies: External dependencies of the application are explicitly declared and isolated.
III	Configuration: The configuration of the application is stored in environment variables.
IV	Backing services: Consumed services are treated as attached resources by the application, i.e. accessed via a URL or other locator/credentials stored in the configuration without distinguishing between locally operated services and third party services.
V	Build, release, run: Build, release and run stages of the application are strictly separated.
VI	Processes: The application is executed as one or more stateless processes which share no resources (directly).
VII	Port binding: The application is completely self-contained (i.e. it does not rely e.g. on runtime injection of a web server into the execution environment to create a web-facing service) and exports HTTP as a service by binding to a port and listening to requests coming in on that port.
VIII	Concurrency: The application scales via the process model, i.e. processes are first class citizens and the operating system’s process manager is used for process management and scaling.
IX	Disposability: The application maximizes robustness with fast startup and graceful shutdown mechanisms.
X	Dev/prod parity: The application is designed for continuous deployment by keeping the gap between development and production small.
XI	Logs: The application treats logs as event streams, i.e. it never concerns itself with routing or storage of its event output stream.
XII	Admin processes: Administration and management tasks of the application are performed as one-off processes, i.e. they run in an identical environment, use the same codebase and configuration as any other processes.

Summary

This blog article described how we analyze the cloud readiness of an existing application that was written for another target platform in a CQSE software audit. We perform the analysis on two levels: First, we employ static analysis to identify code smells, i.e. code constructs which are inappropriate or risky in a cloud environment. And second, we use stakeholder interviews to study whether the application meets cloud requirements regarding architecture and infrastructure. Furthermore, we identify the third party frameworks and libraries used in the application and analyze whether they are cloud ready, too (see also Popeea: Static Analysis to Inspect Third-Party Library Usage).

Please get in contact with me if you are interested in the cloud readiness analysis or have feedback on this blog article.