ScaleDL Overview 2nd draft (7.10.2014)

Jure Polutnik, XLAB

Scalability management for Cloud Computing

Seventh Framework Programme:Call FP7-ICT-2011-8Priority 1.2 Cloud ComputingCollaboration Project (STREP)

Table of Contents1. Introduction............................................................................................................................................3

1.1 Overview........................................................................................................................................4

1.2 Quick Example...............................................................................................................................5

2. Concepts.................................................................................................................................................7

1.3 ScaleDL Overview views..............................................................................................................7

1.4 Architecture view...........................................................................................................................8

1.4.1 Layers.....................................................................................................................................8

1.4.2 Services..................................................................................................................................9

1.4.3 Usage Proxy.........................................................................................................................12

1.4.4 Connections..........................................................................................................................12

1.5 Application definition view.........................................................................................................15

1.5.1 Example...............................................................................................................................15

1.6 Specification view........................................................................................................................17

1.6.1 Service specification............................................................................................................17

1.6.2 Cloud environment specification.........................................................................................19

1.6.3 Deployable service specification.........................................................................................20

1.7 Deployment view.........................................................................................................................21

1.7.1 Clustered and Scalable deployment.....................................................................................21

1.8 Examples......................................................................................................................................24

1.8.1 Example: ScaleDL Overview model of sample web-shop application (TPC-W)...............24

System architecture modelling steps:...................................................................................................24

1.8.2 Example: ScaleDL Overview modelling in CloudScale Environment................................30

1 IntroductionThe ScaleDL Overview is a meta-model that provides a design-oriented modelling language for cloud-based system architectures and deployments. It has been designed with the purpose of modelling cloud based systems from the perspectives of service deployments, dependencies, performance, costs and usage. It provides the possibility of modelling private, public and hybrid cloud solutions, as well as systems running on non-elastic infrastructures. The ScaleDL Overview consists of Architecture, Application, Specification and Deployment views. The Architecture View provides a descriptive abstraction of the system’s architecture, defined using cloud layers (i.e. infrastructure, platform and software layer), consisting of services as a basic building blocks. Service solution stack (i.e. vertically dependent services) is defined through deployment dependencies; referencing the service needed on the lower layer (i.e. infrastructure layer) for successfully deploying services on an upper layer (i.e. platform layer). The dependencies between service solution stacks are further defined through use of connection elements, representing network connectivity between service stacks. The connectivity with external environment is defined through UsageProxy for exposing services and ExternalSoftwareServices for referencing Software-As-A-Service (SaaS) services. The Application View provides a high-level definition of the system’s application, through services exposing operation interfaces (software and support platform services), the dependencies between them (provided and required interfaces). The operation interfaces exposed to external environment are defined through usage proxies, while using operation interfaces provided by external services (i.e. SaaS) through external proxies. Service information, performance (SLOs) and costs are further described using Specification View. Additionally ScaleDL Overview meta-model contains Cloud Definition, defining services available in specific cloud environment and Platform Service Definition, defining deployable platform services (e.g. databases, application servers, etc.) that are deployable in the environments providing Infrastructure-As-A-Service (IaaS). Both definitions can be defined in advance and used when constructing ScaleDL Overview models.Deployment View provides information of how the services are deployed, theirs runtime configuration and also monitoring results. For the infrastructure and provided platform services it defines runtime and generic (i.e. black-box) deployments. First describes the elastic properties of the service deployment while for the later the expected performance and SLOs of external services.

The model has been developed under the CloudScale project, with the aim of providing a well-defined descriptive model to be used by the CloudScale Environment, itself a solution that allows defining and analysing scalability and performance features of cloud based systems. The core functionality of the system is provided through the CloudScale tool-chain; Analyser, Extractor and Spotter, and the goal of the CloudScale Environment is to seamlessly integrate all these tools by providing user-friendly interfaces to operate with them. The basis to achieve such integration is the ScaleDL Overview, which will provide a high-level view of the cloud system: the information needed for automatize usage of the Extractor and Spotter (Dynamic and Static), and a transformation into the Extended PCM model on which the Analyser can perform system analysis.

1.1 OverviewThe root entity of the system architecture is the CloudEnvironment, which defines an abstract cloud environment, split into three layers: SoftwareLayer, PlatformLayer and InfrastructureLayer. The basic element in each layer is the Service, which is further divided into three layered service classes: SoftwareService, PlatformService and InfrastructureService. Services in the architecture model represent high-level abstraction of cloud-based resources (e.g. application, database service, elastic computing infrastructure, etc.) and are further specified through ServiceDescriptors and configured through ServiceDelpoyment, representing Specification and Deployment View. The infrastructure services represent computing, networking, and storage services. In the current ScaleDL Overview version, networking services are not yet defined, and the connection between them is indirectly defined through dependencies between platform services. However the bandwidth available at the deployed services is specified through network interface properties, defined in virtual machine descriptors and the cloud environment specification. The platform services offer a complete set of features (e.g. database, application server, etc.) composing the system development stack for a particular application. Platform services can be used as an execution environment for application services or as a support services offering complete solution made available for use by the application services, therefore the ScaleDL Overview splits these services into two groups: RuntimePlatformServices and SupportServices. The first contains a RuntimeContainer, available for deploying software services and the second represents the complete solution with its defined interfaces, through which software services make use of their capabilities. The software services represent services offering functionality to the external environment or to another software services through exposed interfaces. Services on the platform and software layers usually depend on services available in lower layers, however the exact information is not always known, and is it not required from the system point of view. Therefore the ScaleDL Overview divides those services into externally deployed services (i.e. ProvidedServices), which represents services that either are provided by the cloud provider or are available as a software-as-a-service, and system services, which are part of the system and were manually configured, deployed or developed by a system engineer. The externally deployed services (software or platform services) act as black boxes for which the deployment information is unknown to the system, and the performance of the system can be only predicted through measurements and/or service level objectives (SLO). The deployment information of the system services is known, therefore the performance can be analysed based on the performance of the lower layer services. Layers bellow infrastructure layer (e.g. virtualization and hardware layer) are not described in ScaleDL Overview, therefor infrastructure services are configured through RuntimeDeployment, which describes computing environment (e.g. virtual machines) and various deployable configurations available in the cloud: clustered and scalable computing environment, load balancing and scalability management.

Figure 1: Cloud layers, services, deployment and usage overview

Although there are several possible connections between services (e.g. between services on the same layer, connections between software and support services), the ScaleDL Overview only defines connection between operation interface containers; software and support platform services. The ScaleDL Overview distinguishes between 2 types of connections; Internal and External. The Internal type is used for connecting platform services inside the same cloud environment, where the specifics (throughput, latency) are defined by the CloudEnvironment specification. The External type on the other hand, is used to connect components from different CloudEnvironment, representing the tunnel between two different cloud environments and connections running from or into the system with use of proxy entities (i.e. calls to external services, or to represent entrant connections). Connection between services is prerequisite for defining which operation interfaces are required by services; only operation interfaces provided by connected services can be used by a specific service. The ScaleDL Overview definition currently does not infer connections between infrastructure layers that are indirectly defined through platform service connections if they are deployed on different infrastructure services. For the purpose of connectivity with external environments, UsageProxy is introduced into the model, which function as an operation provider (UsageProxy) by defining the incoming external connections (and will contain an UsageModel in future ScaleDL Overview versions). For connectivity with external software services while ServiceProxy represents the connections to the external software and platform services that are not part of the system or cloud environment, and function under a completely black-box paradigm. The distinction with the cloud provided services (e.g. Database As A Service) is that those services will be usually pre specified with their own performances, capabilities and SLOs; through the Specification view, while the specification of external services will be normally left to the users.

1.2 Quick ExampleFor quick overview of the ScaleDL Overview following example will briefly introduce main model elements, how are connected between each other and how to use them on a real-life system. The model represents CloudStore (http://www.cloudscale-project.eu/results/showcase/), a hypothetical cloud-based shopping service, deployed on the Amazon Web Services cloud. System is composed of 4 main components; web server, database server, storage server and external payment service. Web server is deployed on EC2 in auto scalability group, database and storage are provided by Dynamo and S3 support platform services, respectively. For external payment gateway we use PayPal application service.

Architecture Application definition Specification Deployment

2 ConceptsIn the following section the main concepts of ScaleDL Overview will be described. In addition to modelling cloud based systems ScaleDL Overview also provides the ability to enhance elements’ specifications through cloud and service specifications; defined in separate model, which can be used in describing the modelled system. At the time of writing this document, the ScaleDL Overview is still in development, therefore some features are not yet available, yet they are defined in this document. Currently the main missing part is the definition of external services’ behaviour and performance (i.e. SLO model), and the specifications for related costs (i.e. Price model), which will be defined in the last year of the CloudScale project.

2.1 ScaleDL Overview viewsSteps needed to completely define a system in the ScaleDL Overview are: creating system architecture, defining application view, specifying system services and defining services deployment. Therefore the system model is defined through 4 views: Architectural, Application, Specification and Deployment. Architectural view is a base view on which all other three depends on. It defines services, dependencies between them and cloud environments, while other three acts on a specific service, providing neccessery information to fully describe them and system as a whole.

Figure 2 : ScaleDL Overview viewsFigure 2 shows the ScaleDL Overview model with consisting views and dependencies between each other. Each view will be described in the detail in following sections.

2.2 Architecture viewThe main part of the ScaleDL Overview is Architecture View, used to model cloud based systems with abstract elements without providing them with actual specification or deployment. It is responsible to describe basic system elements, their dependencies and roles. The base component in the Architecture View is a CloudEnvironment, an abstract representation of cloud environment, in which the modelled system or part of it is deployed. The architecture can consists of more than one cloud environments and thus enabling possibility of modelling hybrid cloud solutions. With use of specification view, the cloud environment can be specified to provide infrastructure as a service (IaaS) or platform as a service (PaaS). For the first specifications hold the description of infrastructure resources while for the latter, it contains list of available services; however the specification can also describe a combination of those two (e.g. Amazon Web Services provides EC2 infrastructure and several platform services).

Figure 3: Usage of Platform and Infrastructure services

Figure 3 shows three different cloud configurations; first a typical IaaS provider with a PlatformService deployed on the available ComputingInfrastructureService; secondly a PaaS provider with a ProvidedPlatformService component; and finally an IaaS provider with additional provided services. The ScaleDL Overview enables modelling of all of them. In the following sections basic architecture elements are described in detail: Layers, Services, Connections and Proxies.

2.2.1 Layers The approach taken to model cloud based systems follows the categorization of cloud computing layers: Infrastructure layer, Platform layer and Software layer. Each layer consists of specific services, which are generalized in the ScaleDL Overview to enable modelling system architecture in an abstract way.

Figure 4: Architecture model layers

Figure 4 shows the architecture of a sample application deployed in the cloud environment from the perspective of the cloud layers, and their deployment and usage dependencies. The CloudEnvironment consists of cloud layers, each providing services used by the modelled system:

● InfrastructureLayer: The infrastructure layer consists of infrastructure services (InfrastructureService) offering compute and storage capacity within the cloud environment. The layer itself is based on the virtualization and hardware layers, which are transparent to the cloud based systems, and therefore they are not included into the ScaleDL Overview.

● PlatformLayer: The platform layer consists of platform services (PlatformService) that represent the technology stack used by the developed software. It consists of services responsible for running software services and services that supports them with specific functionalities (e.g. databases).

● SoftwareLayer: The software layer consists of application services (SoftwareService), both internally produced and deployed or externally available, on which system application depends.

2.2.2 ServicesServices represent abstract building blocks of modelled system, defined in each layer: infrastructure, platform and software. Dependencies between them define the system architecture. In ScaleDL Overview we distinguish two dependencies; vertical and horizontal dependency. Vertical or deployment dependency defines, which service (if any) on lower layer is responsible to run specific service. For services provided by 3rd parties (e.g. cloud environment, SaaS), for which the deployment information is not known or is not in interest of system architect, ScaleDL Overview defines them as provided with special deployment elements (see Error: Reference source not found). These provide SLOs and computing environments (in case of computing infrastructure services and runtime platform services; see below). These services are: InfrastructureServices (see 2.2.2.1), ProvidedPlatformRuntimeService, ProvidedPlatformSupportService (see 2.2.2.2), ProvidedSoftwareService and ExternalSoftwareService (see 2.2.2.3). Horizontal dependency is defined through use of Connections (see 2.2.4) between two operation interface containers; software and support platform services. ScaleDL Overview does not provide special elements for defining horizontal dependencies between infrastructure services. Nevertheless those are indirectly defined by the Connections in upper layer (i.e. platform layer); through connections between platform services that are not deployed on the same infrastructure service.

2.2.2.1 Infrastructure servicesThe infrastructure services (InfrastructureService) represent compute, storage and network resources available in a specific IaaS cloud environment. In the current ScaleDL Overview version only computing services are supported:

● ComputingInfrastructureService: The computing infrastructure service represents services provided by specific IaaS. Through deployment configuration, one can configure which computing resource (i.e. instances) to used (normally more are available), how the service will scale (scaling policies), how the load are distributed between the resources (scheduling policies) and initial, minimum and maximum size of the cluster; minimum and maximum are defined in scalable deployments.

Infrastructure services are always provided (provided by 3rd party), therefor it requires ServiceDeployment (see ..), with defined SLA and SLO. Additionally ComputingInfrastructureService requires ComputingEnvironmentDeployment, with which it is possible to configure (considering specification) clustered and scalable computing environments (see 2.5).

2.2.2.2 Platform servicesThe platform services are grouped into two main groups: deployable and provided platform services. First represents services for which we need to define on which infrastructure service it is deployed, while for the provided services this information is unknown to the modelled system and thus cannot be defined. The behaviour of those services is normally measured experimentally and/or defined through SLAs. The deployable platform services can be used only in IaaS clouds, since they provide infrastructure on which those components can be deployed. The provided platform services on the other hand are available in PaaS environments. Some cloud environments also provides some kind of wizards for deploying platform services on the infrastructure (e.g. Amazon RDS and BeanStalk), which ScaleDL Overview defines as provided platform services specified with infrastructure descriptor on which runtime deployment must be defined (see 2.4). Beside deployment information, platform services are also grouped by their ability to provide execution environment for software services (e.g. application servers) and the ability to support software services with specific features (e.g. databases). The support services thus provide interfaces used by software services, while the runtime services provide runtime container into which we can deploy software services.

Figure 5: PlatformService class hierarchy

Figure 5 shows the class hierarchy derived from platform services. Below is detailed description of all leaf classes:

● Deployable platform services○ PlatformRuntimeService: The deployable runtime platform services represent installable

software packages, which are able to execute developed applications (e.g. application servers: Tomcat or Glassfish).

○ PlatformSupportService: The deployable support platform services represent installable software packages, which provide specific functionalities used by developed software services (e.g. databases - MySQL or PostgreSQL, caches - MemCache), or are used for routing requests (web server - Apache WebServer, load balancer - nginx).

● Provided platform services○ ProvidedPlatformRuntimeService: The provided runtime platform services represent

services provided by cloud environment, for which the deployment information is transparent and provides runtime container for executing developed applications (e.g. AWS Beanstalk, Google AppEngine).

○ ProvidedPlatformSupportService: The provided support platform services represent services provided by cloud environment, for which deployment information is transparent and provides specific functionalities used by developed software services (e.g. AWS DynamoDB, Google Datastore).

2.2.2.3 Software servicesThe software services (SoftwareService) represent components that expose functionalities to the outside environment, and can also require functionalities provided by other software services. Software services

are grouped into three groups depending on weather the deployment information is available or is provided by cloud environment or externally:

● SoftwareService: The deployable software services represent developed software deployed on the runtime platform services. This service represents part of system application. It is only service, which can require operation interfaces from other operation interface containers and on the other hand only these services can expose it’s operation interfaces through UsageProxy (see 2.2.3).

● ProvidedSoftwareService: represents cloud provided services, which expose interfaces that can be used by deployable software services (e.g. AWS SNS, SQS, etc.).

● ExternalSoftwareService: represents external services, which expose interfaces that can be used by deployable software services and are available outside of the cloud environment (e.g. PayPal).

2.2.3 Usage ProxyUsage Proxy is used to represent external an environment and defines the entry point to provide logical interfaces to the modelled system In the current version, UsageProxy represents only a placeholder for the access point to the system, however, in later versions we will include also usage model (ScaleDL Usage Evolution), which will define how exactly the system is used.

2.2.4 ConnectionsConnection represents dependencies between different operation interface containers; software and support platform services. Connections are prerequisite for defining dependencies between services, through provide-require operation interface pair. All services that are connected can (not necessary) be depended on each other. The dependencies on the infrastructure layer are not supported by the ScaleDL Overview definition; however they are indirectly defined through the connections. The properties of connections, however, are specified in the model; bandwidth and latency.

Figure 6: ScaleDL Overview connection and usage dependencies

Figure 6 represents a basic architecture model, containing two platform services (‘Runtime Platform Service’ and ‘Support Platform Service’) in a cloud environment and external application service used by system application. System functionality is exposed to external environment through UsageProxy, which can expose all or subset of operation interfaces provided by the connected software service. On the other hand, system software service depends on operations interfaces provided by support platform service and also by the external software service. The ScaleDL Overview defines two connection types that operate between operation interface containers:

InternalConnection: Internal connections are used to represent dependencies between platform services in the same cloud environment. Specification of those connections (e.g. bandwidth, latency) is usually predefined through cloud specifications.

ExternalConnection: External connections are used for connecting platform services (and thus whole system) with the external environments. The difference with internal connection is that it cannot be specified be forehead, thus specification is left to the users. External connection can be used in three ways; it can connect services in distinct cloud environments (hybrid connections), it can connect system software services with external software services (external service connections) or be used for connecting UsageProxy with system software services (proxy connections).

Figure 7: Usage of different types of connection

Figure 7 shows an example application with both connection types in all possible scenarios. The connection type between Application Service 1 and 2 is external and connects two application services in different cloud environment. Similar is external connection between Application Service 1 and Support Platform Service 2, while connection between Application Service 2 and Support Platform Service 1 is internal and is defined by the cloud environment specification. External connections are also used for connecting External Application Service and Usage Proxy with deployable application services (i.e. services internal to modelled system). The idea behind creating different types of connections is to explicitly show how the connection can be described. Each connection has a connection descriptor. The internal connection is normally specified by the cloud environment, while the external connections must be measured and specified by the user.

2.3 Application definition view ScaleDL Overview is used to represent a high-level view of the cloud-based system, therefore software services and support platform services are an abstraction of the software logic, where actual logic can be defined through source code bundles (used in software service), database functions and schemas, configuration of in-memory cache, etc. Main elements for defining application definition are:

OperationInterface: The basic request flow in the ScaleDL Overview is defined through use of OperationInterface, which can be exposed by software services and support platform services. The operation interfaces can be required by only deployed software services, since the external software services and support platform services work as black-boxes, and all potential dependencies are not visible to the system.

OperationInterfaceContainer: Contains list of provided operation interfaces and list of required interfaces (interfaces provided by other services). It is contained in all application aware services (software service and support platform services).

Operation: Consists of name, return type and list of parameters. Parameter: Abstract type used by Operations. ScaleDL Overview defines three different

parameter types, together providing great flexibility when defining custom data types and collections.

o PrimitiveParameter: Most basic parameter defined by primitive types available in TypeEnum; INT, STRING, BOOL, DOUBLE.

o CompositeParamter: Parameter composed of other parameters; for example objects in OOP languages.

o CollectionParamter: Parameter functioning as a collection; for example list and sets.The system exposes services through the use of UsageProxy, which provides a subset of its operation interfaces (through OperationInterfaceContainer) defined by the software services deployed on the connected platform service.The goal of the CloudScale project is to analyse the cloud based systems. For the analysis of external services, specification (SLO, to be more concrete) with additional measurements should provide enough information about how the service will function in the running system. The software services will be further defined in the model required by the Analyser, either manually or with the help of the Extractor, which is capable of creating detailed software models through reverse engineering the software’s source code.

2.3.1 ExampleFollowing example shows the relation between the services, proxies and application definition elements.

Figure 8: Usage of operation interfaces

Figure 8 shows the sample application. The software service defines an operation interface, which is exposed through usage proxy to the external environment. The software service also requires the operation interface provided by support platform service. One thing to note here is that all platform services and usage proxy are connected, and thus the exposing of interfaces is possible between services and proxies.

2.4 Specification view

2.4.1 Service specificationThe second part of the ScaleDL Overview is the definition of the system modelled in the Architecture model. Each component (cloud environment, service, connection and proxy) is specified by the use of descriptors.

Figure 9: An Architecture component is decoupled of its Descriptor

The ScaleDL Overview defines special descriptors for each of the architectural components, which are adapted to the needs of describing the components’ behaviour. In the current version the descriptors are defined very briefly, providing only the basic information. The performance and cost information will be added in later versions using the ScaleDL specification. Below are the descriptions about the information that will be configurable inside these descriptors.

● Descriptor is a base class that provides basic properties (i.e. name and description) including the cloud provider id, for which a cloud-specific descriptor is available.

● CloudEnvironmentDescriptor provides description of a specific cloud environment. The cloud environment is further defined with region and availability zone descriptors (described later in this section). It specifies the network link performance, and cost between regions and/or to the external environment. Regions and availability zones are optional, since some clouds can be deployed only at one location.

○ RegionDescriptor provides information on regions available in a specific cloud environment. It specifies the network link performance (i.e. latency and bandwidth) and costs between availability zones within the same region.

○ AvailabilityZoneDescriptor provides information of availability zones available within a specific cloud environment region. It specifies the network link performance (i.e. latency and bandwidth) and cost between the components (nodes or services) within the same availability zone.

● ConnectionDescriptor provides information of the used network connection between two components; e.g. latency and bandwidth.

● ServiceDescriptor○ InfrastructureServiceSescriptor

■ ComputingInfrastructureServiceDescriptor provides information about the available computing resources in a specific cloud environment. It defines the hardware properties, such as: CPU, CPU units (number of cores), available memory and storage.

■ NetworkInfrastructureServiceDescriptor provides information of the network available in specific cloud environments. It defines bandwidth and latency.

○ PlatformServiceDescriptor

■ PlatformRuntimeServiceDescriptor specifies software servers that can be installed on the computing resources available in an IaaS cloud provider. It specifies what kind of software can be deployed on it (e.g. Java war packages, Python projects).

■ PlatformSupportServiceDescriptor specifies a platform service that can be installed on the computing resources of the IaaS cloud environment and provide functionality to the system.

■ ProvidedPlatformRuntimeServiceDescriptor specifies runtime services available in a specific cloud environment. The descriptor will define performance and cost of services through the use of ScaleDL, which is also developed under CloudScale project.

■ ProvidedPlatformSupportServiceDescriptor specifies support services available in a specific cloud environment, with available operations that can be used by the system. The descriptor will define performance and cost of services through the use of ScaleDL, which is also developed under CloudScale project.

○ SoftwareServiceDescriptor■ ExternalSoftwareServiceDescriptor provides description of external software

services and specifies their behaviour, such as available operations and theirs response times.

■ ProvidedSoftwareDescriptor provides description of provided software services (i.e. services provided by cloud environment) and specifies their behaviour, such as available operations and theirs response times.

2.4.1.1 SystemSpecification modelIn the ScaleDL Overview model all descriptors used for building the system are contained in the SystemSpecification model, and further referenced by abstract elements of the architecture model.

Figure 10: Usage of SystemSpecification

Figure 10 show abstract elements referencing descriptors, which are contained in the SystemSpecification model. Architecture component represents: CloudEnvironment, Service, Proxy, and Connection.The separation abstraction makes it possible to use the same descriptor more than once while configuring it in one place and not throughout all the copies used in the system. For instance, a descriptor could specify a MySQL deployable platform support service, which could be used several times throughout the system.

2.4.2 Cloud environment specificationThe ScaleDL Overview provides also the ability to define cloud and software specifications. Both models consist of descriptors, which can be copied into the system specification and used for modelling the system. Specifications, therefore, can be defined once and used multiple times by different systems. The separation was done for the purpose of the CloudScale project and CloudScale Environment and will provide the possibility to create plug-ins with new specifications, which will be pluggable into the environment and will enhance it with new specifications. Later in the project, we will also create a public repository that will hold such specifications, and provide everyone the ability to use them or even extend the repository with new ones.

CloudSpecification contents: ● CloudEnvironmentDescriptor

○ RegionDescriptors○ AvailabilityZoneDescriptor

● PlatformServiceDescriptor (PaaS)● InfrastructureServiceDescriptors (IaaS)

A Cloud specification consists of descriptors that are meant to be used for defining attributes of different architectural components in a specific cloud environment. Through a cloud specification it is possible to define both IaaS and PaaS cloud environments. For the the IaaS providers, the specification provides a

collection of infrastructure service descriptors. For the PaaS and also for the IaaS providers with additional platform services, a collection of platform service descriptors is available.Some clouds consist of many regions, which may contain several availability zones; therefore the collection for those descriptors must also be available. Each region and availability zone has its own specifics (e.g. cost, performance), and it is thus necessary to take this into account when modelling the system. For clouds that are not split into different regions and availability zones, it is not needed to define region and availability zone descriptors.

Figure 11: Regions and availability zones

Figure 11 shows a cloud environment with regions, each containing different availability zones. For example, Amazon AWS/EC2 provides many regions across the world, each having at least two availability zones on distinct locations.To define cloud networking, connection descriptors must be added to the definition. There can be several descriptors, defining connections inside same availability zone and region, or connections between services and instances from different regions.

2.4.3 Deployable service specificationDeployableServiceSpecification defines:

● Deployable runtime service descriptors● Deployable support service descriptors

With IaaS providers, users have the possibility to create new virtual machines (i.e. computing resources) and install different software on them, to form the modelled system. DeployableServiceSpecification model holds descriptors for runtime, support services and also operating systems. These specifications are not tied to one cloud environment, and can be used with any IaaS provider. For example, a runtime service can describe an architecture based on Apache Tomcat, Glassfish or Internet Information Server, and a support service can be used for MySQL, MemCache, PostgreSQL, or any other storage solution.

2.5 Deployment viewDeployment view defines how the architecture services are deployed in a specific cloud environment. ScaleDL Overview differentiates between three possible deployments; system service deployment, generic service deployment and runtime service deployment. First is used for software and platform services that are not provided externally and for which user needs to configure underlying service (platform or infrastructure). Generic and runtime deployments on the other hand relies on the provided services; first defines deployment of provided services for which runtime information is transparent to the system and the latter for services that needs to be configured with computing resources running them, theirs scalability properties and how the load is balanced; if more than one computing resource is used.Main deployment view components are:

Deployment: Part of the Overview model, containing all defined service deployments referenced by the architecture services. Using this approach, deployment information is separated from the architecture view and its services.

ServiceDeployment: Base class for defining service deployments, containing mas of key-value properties, representing arbitrary deployment information and configuration. By default this component us used by custom system services (deployed by the system architect), while provided services needs additional information and therefore must use derived components (GenericDeployment and RuntimeDeployment).

o GenericDeployment: used for provided platform services, where runtime information is transparent to the system. Normally these are support platform services (e.g. databases).

o RuntimeDeployment: used for runtime platform services and computing infrastructure services. It defines a computing environment, which runs particular service. A special case here are support platform services provided by some cloud environments that are basically wizards deploying service on the infrastructure. For example, AWS RDS platform service deploys relational database (with many possible configurations) on the elastic database computing infrastructure; not AWS EC2.

ComputingEnvironment: is base class for defining computing environment. It defines computing resource descriptor which is referenced from particular service descriptor. By default it is used for one computing resource deployments, while for the clustered and scalable deployments two derived classes are available (ClusteredComputingEnviroment and ScalableComputingEnvironment).

o ClusteredComputingEnvironment: is used for clustered runtime deployments (more than one computing resource) where load is balanced across all available computing resources. For that purpose, ClusteredComputingEnvironment use LoadBalancer component, which defines scheduling policy.

o ScalableComputingEnvironment: is derived from ClusteredComputingEnvironment with additional ability to define scalability features of the service using ScalingManager. It defines range (minimum and maximum) of computing resources system can use and scaling policies, defining how the system adapts to varying work-load.

2.5.1 Clustered and Scalable deploymentTo create clustered runtime deployment one must define how the load is scheduled across all running computing resources in the cluster. For this purpose ClusteredComputingEnvironment (and derived ScalableComputingEnvironment) are defining LoadBalancer. In current version of ScaleDL Overview it is possible to define scheduling policies from predefined set: ROUND_ROBIN, RANDOM. Further abstraction is currently not available, since Analyser (tool for scalability analysis) does not support custom balancing methods and only use random one. In addition to load balancer, one must also define size of the cluster (initial size, in case of scalable deployment) that must be greater than one, and it represents number of computing resources used for running the service. For scalable runtime deployment, one must define scalability manager and scaling policies, defining how the system should adapt to changes. In addition (since the resources are not unlimited) scaling manager contains range of the scaling cluster; minimum and maximum number of computing resources to be used for particular service.

2.5.1.1 Scaling manager

2.5.1.2 Scaling metrics ScalingPolicy: defines one policy of how the cluster should change based on the configuration

and scaling metric; or combination of them.o Type: defines how the current size of cluster is change when this scaling policy is

triggered. There are three available values: ChangeInCapacity, ExactCapacity, PercentChangeInCapacity. ChangeInCapacity is by predefined value (adjustment) of computing resources (positive or negative) while PrecentChangeInCapacity changes cluster relative (by percentage) to current size. ExactCapacity defines exact number of computing resources when this policy is triggered.

o Adjustments: Float value which is taken into account in combination with type to configure new cluster size when policy is triggered. In case of ExactCapacity and ChangeInCapacity types, this value must be integer (or will be rounded).

o Cooldown: Defines duration after the policy is triggered to wait for system to stabilize (another policy cannot be triggered during this time)

o Trigger: Defines when policy should be triggered. It is configured with use of ScalingMetric or combination of those. Metrics can be combined with AND and OR operators; scaling_metric1 [AND|OR scaling_metric2]

ScalingMeric: Format is as follows: Aggregation(Type) Operator Value [Period] (e.g. avg(CPU) >= 0.8 [5 minute])

o MetricType: defines metric type to be used. Possible types are: CPU, Memory, IO_Read, IO_Write, Data_IN, Data_OUT.

o Aggregation: defines how to aggreagate the values coolectied over the specified period. Possible aggregations are: min, max, avg, sum, count.

o Operator: defines comparable operator; <, <=, =, >=, >o Value: defines value to which aggregated metric are compared.

o Period: defines time period over which metrics are aggregated.

For example, if we want to define trigger which is activated when average CPU is greater than 80% for more than 2 minutes or memory consumption is greater than 90% for on our, we could define: Trigger >> Avg(CPU) >= 0.8 [2 minute] OR max(MEM) > 90% [1 hour]

3 Examples

3.1 Example: ScaleDL Overview model of sample web-shop application (TPC-W)

In the following example we will show how to use ScaleDL Overview to model a simple web-shop application. The application is web-based and offers users to browse through items available in the shop, through book categories, search and browsing similar books. Additionally, the solution offers ordering capabilities, with user registration, shopping cart and purchase pages.The solution is running in the Amazon Web Services (AWS/EC2) cloud. The application is developed using Java Servlet Framework and is deployed on a Tomcat application server, which is installed on the small EC2 instance (i.e. virtual machine running Linux OS distribution). The multimedia content is stored in the S3 elastic cloud storage. The application server is self-adaptable, which means that it scales-out in case of increased load. The AWS Elastic Load Balancer (ELB) is configured in front of the application server cluster to automatically distribute incoming traffic (load) across multiple EC2 instances (application servers).

Figure 12: Sample web-shop application deployment

The application displays the following web-pages: Browsing: Categories, Book, Search Ordering: Registration, Shopping cart, Check-out

We will split the modelling of the system in the ScaleDL Overview Model into three phases: system architecture, system specification and system application definition. In the first (system architecture) we create a high-level system abstraction split into three layers: infrastructure, platform and application, in the second phase we specify the properties and behaviour of the modelled system and in the last phase we define the application’s behaviour through definitions of interfaces and dependencies between them.

System architecture modelling steps:1. Create a CloudEnvironment

The CloudEnvironment represents the AWS cloud in which we deploy our sample application. 2. Define the infrastructure layer

The infrastructure layer consists of infrastructure services, which represent computing resources used in our system. We create two ComputingInfrastructureServices which will be used to deploy system platform services; one for the software server and one for the database server. We modelled those instances using ComputingInfrastructureService, on which we will deploy our platform services (MySQL and Tomcat). Choosing the computing resource and defining deployment properties of these services will be covered in ‘Deployment modelling step’.

3. Define the platform layerThe platform layer consists of platform services, representing our platform (i.e. development stack), which is used by the sample web-shop application. The platform services are grouped into two main groups: deployable and external. For the first (deployable) we need to define on which infrastructure service they are deployed, while for the second (provided) this information is transparent to the user and does not need to be modelled.a) Deployable platform services

a. Tomcat, is deployable and also provides runtime environment for application services, therefore we use PlatformRuntimeService component and name it ‘Tomcat’. We link it to the previously created infrastructure service ComputingInfrastructureService (VM-Tomcat).

b. MySQL, is deployable and is used as a support service to our system, therefore we use DeployableSupportService and name it ‘MySQL’. We reference it to the previously created ComputingInfrastructureService (VM-MySQL).

b) Provided platform servicesa. For defining AWS S3 we use a ProvidedPlatformSupportService component. This

service is provided by AWS cloud so we don’t need to define infrastructure service on which it is running. We name it ‘AWS S3’.

b. AWS ELB is also provided by AWS cloud, therefor we again use provided platform service; ProvidedPlatformSupportService. We name it ‘AWS ELB’.

4. Define the software layerOur sample web-application represents one software service, which needs to be deployed on the Tomcat application server. To model it we use SoftwareService, which we link to the PlatformRuntimeService, used to model Tomcat server.

5. Define UsageProxyThe UsageProxy component holds reference to operation interfaces from software services that are available to out-side environment.

6. Define connections Connections operate between platform services and proxies. To be able to define dependencies between interfaces (in the third modelling phase), the ScaleDL Overview expects that connections between undelaying platform services exists. Therefore we connect UsageProxy with AWS-ELB, and that AWS-ELB to Tomcat, which is further connected to MySQL and AWS S3.

For the first connection we use ExternalConnection, while for the other we use InternalConnection, since all services are in the same cloud environment.

Figure 13: Sample application architectural componentsFigure 13 shows the architectural components of our sample application with regards to the basic cloud layers. Web-shop application service uses functionality provided by the MySQL and the AWS S3 and is deployed on the Tomcat, all services available on the platform layer. The deployable platform services also depends (are deployed) on the infrastructure services, thus the deployment connection between the platform service and the infrastructure service.

System specification modelling steps: After creating the architecture model, we need to define what each element represents. We will create a System definition model that will hold all the descriptors needed for defining the system.

1. Specify CloudEnvironment:Create Amazon Web Services / Elastic Compute Cloud (AWS/EC2) descriptors. The CloudEnvironment will be defined with a CloudEnvironmentDescriptor, a RegionDescriptor and an AvailabilityZoneDescriptor. In some clouds we could skip the last two, however the performance and costs of AWS/EC2 cloud services varies with the chosen region and availability zone. At the end, a reference descriptor to the CloudEnvironment element is used.

2. Specify Infrastructure layer servicesComputingInfrastructureService is specified with ComputingInfrastructureServiceDescriptor, which besides basic information (i.e. name and description) requires available ComputingResourceDescriptors defining available computing resources and theirs properties (i.e. cpu, cpu units, memory and storage). In this step we specify AWS EC2 descriptor, with at least two computing resource descriptors (e.g. m1.small and m1.large), which we will use when defining deployment information. We specify both computing infrastructure services (VM-Tomcat and VM-MySQL) with newly created descriptor. Doing this we tell that we are deploying our services on the EC2 IaaS.

3. Specify Platform layer servicesIn the current version, platform services are specified with only basic information (i.e. name and description) with additional key-value set for flexibility. In the latter versions we are planning on

specifying behaviour of external services with the use of ScaleDL (result of the CloudScale project). Therefore, we create a platform descriptor for each platform service, with appropriate name and description. PlatformRuntimeServiceDescriptor – Tomcat PlatformSupportServiceDescriptor – MySQL ProvidedPlatformSupportServiceDescriptor – AWS S3 ProvidedPlatformSupportServiceDescriptor – AWS ELB

4. Connection descriptorsCreate a NetworkInfrastructureServiceDescriptor based on the AWS/EC2 network specifications and reference it to the all InternalConnections used in the environment.

Figure 14: Sample application system specification.Figure 14 shows both the architecture model (without usage information, on the left) and the specification model (on the right) of our sample application. All descriptors contained in the system specification model are referenced by the architectural components, except connections, which were left out due to clearer presentation. However, both connections reference the same connection descriptor.

System deployment modelling steps:After we have modelled architecture and specification models we are ready to configure services deployments. In our system we have 3 different deployments; basic service deployment (for non-provided services), generic service deployment (S3 service) and runtime service deployment (EC2 services).

1. Basic service deploymentFor all non-provided services we have an option to skip this step or define ServiceDeployment. Since we will not model specific configurations we can skip it, otherwise we can apply ServiceDeploymennt components on a subset of services and define deployment settings. The ScaleDL Overview only define free key-value map, therefor in-here we can put all relevant information.

2. Generic service deploymentFor the S3, which is provided platform service, we create GenericServiceDeployment and select SLO and Price model from the service specification.

3. Runtime service deploymentFor two computing infrastructure services we create RuntimeDeployment. For our application stack (application -> tomcat -> ec2) we want to scale-out when CPU and Memory exceeds configured thresholds. We define corresponding runtime deployment with ScalableRuntimeEnvironment. For our MySQL we want to define master-slave configuration of 4 servers. We don’t want to automatically scale it, therefor we use ClusteredRuntimeEnvironment.

ScalableRuntimeEnvironment (software->tomacat->ec2 stack)o Size = 2 (initial size)o LoadBalancer

schedulingPolicy = ROUND_ROBINo ScalableManager

maximum = 10, minimum = 2 (size range) ScalingPolicy (scale-out policy)

type = ChangeInCapacity, value = 1 (add one node when policy is triggered)

cooldown = 5 minutes trigger = avg(CPU) > 90% [5 minutes] AND max(Memory) >

80% [10 minutes] ClusteredRuntimeEnvironment

o size = 4 (cluster size)o LoadBalancer

schedulingPolicy = ROUND_ROBIN

System application modelling steps:1. Define interfaces

ScaleDL Overview Model defines OperationInterfaces, which needs to be described for all software services, and also for supporting platform services that expose functionality used by the developed application. For the sake of simplicity, we will only define basic operations needed in our system. Web-shop interfaces:

o Browsing: getHomepage(),

getBookPage (int id), getCategoryPage (String category)

o Ordering: getShopingCartPage(), getCheckoutPage(), login(String username, String password), addBookToCart(int id), performCheckout (String creditcard)

MySQL interfaces:o Data:

getBook(Integer id), getBooksByCategory(String category), getUser(int id), getShoppingCart(int userId), performCheckout(int chartId),.

AWS S3 interface:o Multimedia:

getBookCover (int id)

2. Define operation interface dependencies (provide-require pairs)The Browsing interface requires both the MySQL Data operation interface and AWS S3 Multimedia interface, while the Ordering operation interface only requires MySQL Data interface. AWS ELB is a support service without its own interface, therefore it references all interfaces indirectly exposed by the connected platform service. In this case it references to both Browsing and Ordering interface, which are further exposed by UsageProxy.

Figure 15: Software logic definition; OperationInterfaces and dependencies.Figure 15 shows the entire software logic definition. Each support platform service exposes one interface, which is required by the web-shop software service, which contains two interfaces are further exposed to the external environment (through UsageProxy; not included in this figure).

3.1.1 Example: ScaleDL Overview modelling in CloudScale EnvironmentThe following example briefly shows the ScaleDL Overview modelling with the CloudScale Environment (CSE). We will show how the process of modelling the system of the previous example can be quicker and simpler using CSE. In the CloudScale Environment the ScaleDL Overview modelling is split into two phases. At first the user designs a diagram that represents an architectural view of the system with additional specifications available in the CSE, and on the second definitions the system through specialized editors. The ScaleDL Overview Diagram provides a simple, drag-and-drop modelling user interface, by using elements available in the panel (Figure 13). The panel is composed of two main groups; static and dynamic elements. Static elements are basic architecture elements; proxies, connections and software services. The dynamic part consists of elements provided by the installed specification plug-ins; The CloudScale Environment provides a plug-in mechanism, which enables users to add definitions that are not originally included. When used, those elements already have their descriptors defined, thus it is not necessary for the user to configure the element’s properties manually.

Figure 16: ScaleDL Overview model diagram using CloudScale Environment

In the first phase we model the system using the already available components in the pallet. Those components represent architecture components (connections, proxies, cloud environment and platform services), with already specified descriptors. Platform services are divided into “Deployable platform services” that can be deployed in any cloud environment, and specific cloud environment services (ProvidedPlatformService), which are available only under a specific cloud environment. The infrastructure layer is based on the cloud environment specification. When using one of the deployable platform services, the ComputingInfrastructureService is automatically created, with a default descriptor available at the cloud specification. Later the descriptor can be changed through the deployable platform service editor.The definition of the software layer is made through specialized editors. The CloudScale Environment provides several editors that enable a user to define all aspects of the ScaleDL Overview, and also to connect the model to the integrated CloudScale tool-chain: Analyser, Extractor and Spotter. Currently, the editors are still in the development phase and provide only basic configurations, but the aim is to fully support the entire ScaleDL Overview modelling and tools configurations.

Figure 17: ScaleDL Overview service editor

Figure 17 shows the deployable platform service editor capable of running software services (DeployableRuntimeService), where user can enter some basic information of a specific component, define software service interfaces and choose the instance that the component will be deployed on.