La marcación de la circunferencia de la distancia de los

Computing architectures which reduce the connection between hardware and application from both design level and runtime level, for example, container based and Google App Engine applications, can benefit from cloud services. Among several architecture paradigms, this thesis only focuses on Virtualized Componentized Application Architecture.

In this section, the Virtualized Componentized Application Architecture will be described. Component based architecture will be explained in section 4.2.1. Virtualized Componentized Application Architecture will be introduced in section 4.2.2.

4.2.1 Component based architecture

[MBNR68] proposed the concept of component based architecture for reusing software to build complex software system quickly and easily. With the increasing efforts from industry leaders such as Microsoft COM Component Object Model [WK94] CCM CORBA Component Model [SK00] and Sun EJB Enterprise Java Beans [DeM02], component based architecture is widely accepted from 90s.

38 CHAPTER 4. STATE OF THE ART-RUNTIME CONTROL

The thinking of developing software based on components is not entirely new. Traditionally, the composition of complex software systems always start from defining subsystem modules such as the lower-level modules, classes, procedures, etc.

Software development reuse mechanism has been adopted for many years. Although the Object-oriented model has already been widely used to solve the problems of software reusing from the developers’ perspective, component based architecture allow roles like administrator, architect and integrator taking the software reuse problem into consideration. Component-based architecture has further increased the possibility of software reusing. Using component tech- nology to develop large-scale software systems is faster and more cost effective.

Component oriented software engineering is described in [Szy02]. A component is a unit of composition whose interfaces and contextual dependencies are specified as explicit contracts [Szy02].

The Fractal Model is a language and technical independent component model [BCS04] developed by France Telecom R & D and INRIA. Fractal is one project of free software project consortium OW2 (formerly ObjectWeb) which aims at reducing the costs of software systems development, deployment and maintenance. Fractal can be adopted in all kinds of software system, such as operating systems, middle-ware platforms and graphical user interfaces. Fractal can be realized in languages such as Java, C, .NET and Python.

Conventionally, a Fractal component is a processing unit with a heavily encapsulated state. A Fractal component interacts with the outside through customer interfaces and server inter- faces. An interface does not specify an abstract type definition as in object-oriented languages, but an access point (typed and identified by name) on a component.

In Fractal, the external interface and the subcomponent interface are connected through an internal interface. It makes it possible to define composite component. Fractal provides a recursive component model instead of a single hierarchy because a subcomponent can belong to several parent components. This sharing of components was specifically designed to represent the shared resource, such as operating systems.

The component content is isolated by a membrane, whose function is to control the interac- tions at the external interfaces and provide observation and component reconfiguration capabil- ities. This membrane is controlled by control interfaces. Fractal model specification mentions some control interfaces such as naming, establishment or abolition of a connection between a client interface and a server interface, access to the content of a composite, lifecycle manage- ment and access to component state. Thus, the Fractal model was clearly specified to enable observation and hot reconfiguration of a system, including the addition, removal or replacement of a component. Moreover, a Fractal component is not only an element of design but also an element at runtime.

Componentized Application Architecture (CAA) is extracted from the design level informa- tion, such as application architecture, owned by application developer. CAA contains necessary information for deploying an application into the cloud infrastructure. To be more precise, CAA contains the hardware and software requirements of running each component, such as CPU compute power, available memory, network bandwidth required for supporting the communica- tion between two components, the software stack, including required operating system, which are used for constructing the runtime environments for the application. In Figure 4.1, compo- nent C1 and component C2 both require services from component C4, but through different interfaces provided by component C4. Component C3 requires services both from component C4 and component C7. Application owner can shield system implementation details by only

4.2. VIRTUALIZEDCOMPONENTIZED APPLICATION ARCHITECTURE SCHEMA 39

CAA - Componentised Application Architecture (extract)

C4 C4 C5 C1 C2 C3 cLB a b C7 C7 Vertical scaling of a component Require Disk Storage R/W Horizontal scaling of a component

Figure 4.1. Componentized Application Architecture schema.

provide the layout’s requirements of its components. According to Figure 4.1, component C1 and Component C2 should be installed in the same VM, component C3 and Component C7 should be installed in the same VM and component C4 should be installed in one VM alone. These deployment requirements can come from application owner’s understanding of the sys- tem. Component C4 is only allowed to do horizontal scaling at runtime, while component C7 is only allowed to do vertical scaling. Horizontal scaling is allowed to be used for one component, the change of resource allocation can be performed by increasing or decreasing the number of duplications of the component. When vertical scaling can be used for one component, means that the change of resource allocated to the unique copy of this component can be done by in- creasing or decreasing its allocated resources. Since component C4 allows horizontal scaling, a load balancer is needed for routing workload among duplications of component C4.

4.2.2 Virtualized Componentized application architecture

Figure 4.1 is only an abstract description of the deployment requirements of an application. Several practical deployment schemas can be deducted from CAA described in figure 4.1. Fig- ure 4.2 and Figure 4.3 depict typical practical deployments. These practical deployments in a virtualized environment such as cloud environment is named as Virtualized Componentized Application Architecture(VCAA).

In Figure 4.2, three different ways of deploying CAA described in 4.1 are depicted. Com- ponents C1, C2, C3, C4 and C7 are deployed together or separately accordingly. The differences among these three VCAA conditions are the ways of realizing vertical scaling for component C7 and horizontal scaling for component C4. Vertical scaling can be performed by two ways. One way is increasing or decreasing the allocated resource in component level, as depicted in condition 1 and condition 2 of Figure 4.2, which means the size of VM is kept and VM changes

40 CHAPTER 4. STATE OF THE ART-RUNTIME CONTROL VM4 VM1 VM2 VM3 VCAA - condition1 C4 C4 C5 C1 C2 C3 C4 LB a b C7 C7 Data Link Service Link ST1 VM4 x VM4 x VM1 VM2 VM3 VCAA - condition2 C4 C4 C5 C1 C2 C3 C4 LB a b C7 C7 Data Link Service Link Read I/O Write I/O ST1 VCAA - condition3 VM4 x VM4 x VM1 VM2 VM2 VM3 C4 C5 C1 C2 C3 C4 LB a b C7 C7 Data Link Service Link VS of a VM ST1

4.2. VIRTUALIZEDCOMPONENTIZED APPLICATION ARCHITECTURE SCHEMA 41 Data Center 2 VM2 VM2 VM4 x VM4 x

VCAA - Virtualised Componentised Application Architecture

C4 C4 C3 C4 LB a b C7 C7 Data Center 1 VM1 C1 C2 Intra-DC Service Link VM3 C5 Data Link Read I/O Write I/O Inter-DC Service Link VS of a VM ST2 ST1

Figure 4.3. Multi-IaaS Virtualized Componentized Application Architecture example.

resource assigned to the component. Another way is that resource reallocation is performed in VM level, as depicted in condition 3 of Figure 4.2, which means the size of VM changes in order to increase or decrease resources allocated to the component. It can be the case when VM do not have enough resources to assign to the component.

Horizontal scaling can be performed in two ways. One way is that increasing or decreasing the number of component duplications in component level, as depicted in condition 1 in Figure 4.2, which means there are still one VM but the number of component duplications changes to have variational available resources for component C4. Another way is that horizontal scaling is performed in VM level, as depicted in condition 2 and condition 3 of Figure 4.2, which means VMs are copied together when duplicating components. In this way, workload is distributed by a VM level load balancer among identical VMs. It is worth mentioning that components of an application are not necessarily deployed in the same IaaS. As depicted in Figure 4.3, the VM carrying component C1 and C2 can locate alone in geographically different IaaS. This is a practical scenario, for example web server can locate closer to the end user to improve the speed of browsing articles of a e-commercial web site. If components are deployed in a geographically same IaaS, connection bandwidth and cost usually is out of question. However, bandwidth and cost can be a challenge if connections are through external network exactly the case described in Figure 4.1.

In this thesis, only VM level horizontal scaling and VM level vertical scaling are considered. We also make the hypothesis that all the VMs are of the same size when adopting horizontal scaling.

As mentioned before, adding or removing servers and changing server sizes are two ways of increasing and decreasing system capacity. Adding or removing servers refer as horizontal scaling. Another name of horizontal scaling is scaling out/ in. Changing server sizes refer as vertical scaling. Another name of vertical scaling is scaling up/ down.

Vertical scaling means changing the allocated amount of resource of a server. Vertical scal- ing can be achieved by reconfiguring the server or by replacing the server with a new server

42 CHAPTER 4. STATE OF THE ART-RUNTIME CONTROL

of different resource allocation. Aforementioned resources can be any kinds of resources, such as CPUs and memory. Cloud environment provides the possibility of adopting vertical scaling based on the virtualization technology. As an infrastructure based on virtualization technology, servers’ resource allocation can be reconfigured without power off, and it leads to significant re- duction of vertical scaling time compared to traditional IT environment. Vertical scaling can be used to simplify the changing of resources shared among application modules. Vertical scaling is suitable for changing the size of the database.

Horizontal scaling means adding or removing servers to the system to handle the changing demand. When the number of user requests for an application increases, additional server resources can be launched to adapt to the increasing workload. When resources are no longer needed which means there are underutilized servers, resources can be released by terminating underutilized servers. Usually, in a runtime control problem, we only considering same size of servers for horizontal scaling. It is also the case for this thesis.

Before the emerging of cloud computing, vertical scaling is the first choice of serving an increasing workload. Horizontal scaling is performed on individual part of an application only if it reaches the vertical scaling limitation. In the context of cloud computing, horizontal scaling is the overwhelming majority of the scaling choice. “Vertical scaling” can not be supported because most of the operating systems can not change usable CPU or memory without restart the operating system [VRMB11].