Building an Application Stack in the Cloud

Once deployment requirements (including hardware and software requirements) have been cap-tured in form of models, there is still the question how the required execution stack, which is necessary to run the cloud application, can be created automatically. This strongly depends on which cloud abstraction layer is targeted. As already mentioned, IaaS provides the most flexible

solution and virtual instances can be customized all-embracing. When speaking about PaaS, the dependency on APIs and available libraries is stronger and detailed information about hardware requirements (i.e. amount of CPU cores) can not be taken into account during migration. On the other hand, there are software requirements, which can be categorised into different layers, each of them depending on underlying layers and so on. All layers grouped together can be seen as a stack, which enables an application to be run in the cloud.

There are different approaches to address the problem of how to semi-automatically create and setup execution stacks on cloud resources. Figure 2.2 illustrates four different possibilities of a virtual image configuration to ensure that a Java-based application (such as the PetStore), can be executed on the virtual machine. The applicationCloud Applicationneeds a database, a web server and a Java execution environment, which are already part of the virtual image or have to be installed once the virtual machines has booted.

Figure 2.2:Virtual Image Configuration Options. Source: [2]

Pre-baked image. All dependencies, inclusively the application, are baked into one virtual image. If the existing application is already running in a virtual environment it is easier to create a snapshot of the server in its current state and transfer it to the cloud. The main drawback is when components have to be changed, such as updating or patching the web server, the oper-ating system or the application itself. To persists such changes, the virtual images needs to be recreated. The advantage is, as soon as a virtual machine is initialised with the image, it is ready for operation instantly.

Container approach. Market places like AWS market place⁸, which are tightly integrated with their provided cloud services enable consumers to look for pre-configured virtual machines images, which are ready to be deployed onto a virtual appliance. The creator can determine the hourly rate she wants to charge, which is billed to the consumer additionally to the normal expenses of using virtual resources. Although this approach is comfortable and does not include a lot of configuration it is quite inflexible. There may be some installed software, which are not necessary to run the application that would result into wasted resources. If the technology stack is unavailable, one would have to search for the most accurate alternative and eventually re-configure it afterwards. Compared to the pre-baked image strategy, the application code is decoupled from the rest of the software stack, which is handy when the application needs to be updated.

Layer approach. Compared to the previous two approaches, this is one is more agile. The strategy is to create images in advance only with the most basic layers, which do not have to be updated frequently. All layers above are described in an abstract way, often called recipes.

These have to be interpreted and executed when the virtual machine is initially booted and before it can be used for productive purposes. The flexibility of such recipes, which describe everything needed to install and configure a specific software, lies in the definition of configuration param-eters such as version numbers or user credentials.

An application that is capable to interpret and run recipes is Opscode Chef, which is ex-plained in more details in Section 7.3.

Raw. As the image just contains the operating system, all configuration has to be done from scratch, every time a new virtual instance is booted. In relation to application scaling this may not be effective, as the installation of needed software may consume more time than the peak period, where an additional instance is needed, lasts. On the other hand, the used image does not have to be maintained and kept updated, as the majority of cloud providers provide images of up-to-date operating systems.

2.4.1 Search Based Software Engineering

The idea of search based software engineering (SBSE) was already considered in 2001 by Har-man et al. in [27] and has been successfully applied to a various of different software engineering problems such as test data generation or automated patching [28].

The authors of [28] explore the possibility of how SBSE “can help to optimise the design, development, deployment and evolution of cloud computing for its provider and their clients”

[28]. In the following the focus lies mainly on the client side, as this master’s thesis describes the problem from a consumer’s point of view.

In general SBSE can be seen as a problem solving method in software engineering, where

“computational search and optimisation techniques” [28] are used to find an optimal solution among other potentially correct solutions, which may be in conflict. There are two steps in-volved to convert a common software engineering problem into one which can be solved by the

8https://aws.amazon.com/marketplace/

SBSE approach. (i) reformulation of the problem, which means the definition of candidates representing possible solutions and (ii) definition of an evaluation function, which fulfils the ability to determine the better solution, out of two given ones.

Concerning the previously mentioned container approach, [28] addresses the problem in detail and provides a solution in applying SBSE. When using pre-configured virtual images, some software components may not be used at all, which would waste unnecessarily resources and may affect both: client (additional costs, higher response time) and provider (demand of physical hardware). The main question is to determine the trade-off between the frequency of using a module and the possible reduction of allocated hard disk space when removed.

Partial evolution, which has a long history and was applied already in 1977 for specialising programs [7], is one method to identify those modules which are unused and therefore could be removed in favor of smaller machine images. In this case, dependencies between modules are represented as a graph, where single nodes or a small group of nodes can be striped away, which makes the graph smaller, but at the same time lowers the functionality.

The authors of [50] and [34] describe an approach of slicing unused parts of the source code to increase performance on the application layer. In general there are three methods: static slicing (without executing the program), dynamic slicing (considering program input) and condi-tioned slicing (bridging the gap between static and dynamic). [28] claim that the statical method of this approach can be applied to cut virtual images as well.

The third approach is a searched based approach to identify parts which can be deleted or even better to search for a way to create a new image, out of the old one and recording the intermediate necessary steps to assure reproducibility in the future.

CHAPTER 3