The (5+1) Architectural for Cloud Applications

Mohammad Hamdaqa, Ladan Tahvildari Technologies Applied Research (STAR) Group Department of Electrical and University of Waterloo, Canada {mhamdaqa, ltahvild}@uwaterloo.ca

Abstract Existing software frameworks focus on application development, rather than the dy- namic evolution of applications at runtime. Their view models reflect design considerations, more than service operations. However, the quality of a cloud application depends on its configuration and the architecture of its service model. For this Figure 1: Architecting for Application Implemen- reason, we need a view model that is constructed tation v.s. Service Operation around deployment. This paper proposes a (5+1) architectural view model, where each view corre- sponds to a different perspective on cloud applica- and leverage portability and scalability. tion deployment. The (5+1) view model has been View modeling is a well-established prac- realized as a layered, domain specific modeling tice. Existing frameworks include the (4+1) view language, and the capabilities of this language have model [25], the Three Schema approach [23], the been illustrated using a representative domain ex- [34] and the Department of ample. The model was derived by investigating the Defense framework [13]. These frameworks all process of architecting cloud applications, and then clarify , because that is when ar- providing a set of meta-models to describe cloud chitectural decisions were traditionally finalized. applications within their ecosystem. Static deployment infrastructures were the norm. In cloud computing however, architecture evolves 1 Introduction during deployment. Runtime operation needs as much architectural modeling as design does [31]. An architectural view model is a set of logical Cloud applications must morph at runtime to meet and consistent views that describe a complex sys- performance, availability, and scalability targets tem. Each view depicts the from a differ- under changing conditions. This shift in emphasis ent perspective to meet the needs of from architecting for implementation to architect- different stakeholders [25]. This paper presents ing for operation is illustrated in Figure 1. a view model for cloud applications that enables Models of implementation architecture capture cloud stakeholders (e.g., providers, developers, ad- the design to create design mod- ministrators and financial managers) to leverage els that reflect the source code of the applica- cloud platform capabilities to maximize availabil- tion. Models of service operation architecture cap- ity, maintain performance levels, minimize costs, tures the operational requirements to create run- time models that describe the configuration space not know how to distribute its service geograph- of the application. The practices complement each ically to ensure high availability with low over- other. However, the latter is more malleable and so head. CoupoNet’s architect designed the applica- better illuminates the dynamic evolution of cloud tion to minimize coupling and maximize cohesion. applications. During deployment the administrator may redis- This paper introduces a framework for under- tribute the modules to minimize costs, and perform standing service operation architecture: the (5+1) due diligence to initialize them with optimal ratios. view model. We also develop a cloud domain However, this may contradict the architect’s origi- specific (DSML) called Stra- nal design decisions. As demand fluctuates, the ad- tus Modeling Language (StratusML) [19]. At the ministrator updates the deployment model and re- core of the (5+1) is the service model, which de- configures the different services. scribes reconfigurable, executable, compositional CoupoNet faces common cloud challenges. units (Tasks [17]). Service models are further spec- They have to model multi-tenant and multi-tier ap- ified using four operational model views to repre- plications, partitioning them into modules, and dis- sent performance, adaptation, availability, and exe- tribute them across locations. They may strug- cution scenarios; plus views that illuminate porta- gle with vendor lock-in, deployment architecture bility and operational cost. StratusML fragments mismatches, uneven cloud expertise and clashing models into artifacts that are easy to modify. By stakeholder priorities [18]. Our (5+1) view model weaving these fragments into model views, cloud in StratusML can help reduce all these problems. stakeholders can better understand the runtime dy- namics and evolution of complex cloud applica- tions. 3 Architecting for the Cloud Section 2 illustrates some of the challenges fac- Cloud computing improves service availability, ing companies who use cloud applications. Sec- minimizes downtime, and scales applications on tion 3 explains how cloud applications must be ar- demand. This means cloud applications must chitected to be malleable and manageable. Sec- morph during runtime without requiring redeploy- tion 4 shows how the (5+1) meta-models facilitate ment or restart [18]. They must scale out by achieving this. Section 5 realizes the (5+1) model adding new instances to meet demand, and scale using StratusML, and shows how it serves system up to larger virtual hosting machines as needed. stakeholders. Related work is summarized in Sec- They routinely switch tasks on/off to alter their be- tion 6, and Section 7 concludes by pointing out di- haviour, and they may need to change the wiring rections for future research. between tasks that communicate through common storage (queue, blob, etc.). To support performance 2 A Motivating Example debugging, they must be able to switch between logging fine or coarse grained system dynamics. Consider CoupoNet, a fictitious startup that offers a Figure 2 shows that this level of flexibility can coupon service in the cloud. CoupoNet has a multi- be achieved by separating the application ser- tier, multi-tenant application that allows users to vice model from its configuration model and the open a free trial or paid account, design coupons, provider’s specifications; and enabling workflow and publish them to location-targeted customers. model composition based on the service model The application stores buy/sell , and performs tasks at runtime. The service model specifies the sophisticated analytics to rank offers, generate re- tasks provided by the cloud service, their types, and ports, and analyze system usage to dynamically up- their relationships. The configuration model fur- date CoupoNet’s pricing models. The service was ther specifies the service model, by specifying the launched in the cloud to reduce costs, ensure relia- replication of the tasks, and their concurrency and bility and minimize administration. distribution. The provider’s specifications specify CoupoNet is a startup, and does not know how the resource configuration of the underlying host- much traffic it will get. The coupon market has ing environment. Lastly, the workflow model rep- seasonal peaks, last-minute pile-ons, and can ex- resents different usage scenarios for the service hibit slashdot effects. Demand surges are expected, model tasks. We can change these models sepa- but no one can predict the time. CoupoNet does rately to meet desired operational requirements. In Figure 2: The Malleable Application Architectural Style order for the changes to be applied automatically at 4 The (5+1) Architectural View run time, an adaptation model should be defined to access all the elements and parameters of the Model adaptation models that need to be changed. The View models must specify not only how different model uses key performance indicators to initiate views are distinct, but also how they overlap. It is change requests. These indicators can be gathered usually difficult to define clear-cut boundaries be- runtime model per- from the and represented in a tween what each stakeholder should view and man- formance model to enable performance analysis. age. The aim of the (5+1) view model is to sim- Malleable Application Ar- We call this pattern the plify cloud application management by providing chitectural Style (MAAS) . views that correspond to different stakeholder per- MAAS is a common architectural pattern in spectives. This section illustrates how this is done. cloud . It relies on separating executable components from their model structure, config- uration, target resource specifications, execution 4.1 Overview scenarios and control. In Figure 2, the control As shown in Figure 3, the (5+1) architectural view model corresponds to the performance and adap- model consists of five model views that specify tation models, which are defined to influence the the core/service model view to address five differ- actions of the Cloud Fabric Manager. The fab- ent, but interleaved cloud concerns related to ser- ric manager is a platform specific autonomic man- vice deployment and evolution. Each model view ager [21] that uses a set of adaptation rules and per- conforms to its corresponding meta-model. More- formance indicators to enact change actions on the over, the top element in all the model view meta- target model using APIs. models extends the (5+1) component (i.e., a meta- The (5+1) meta-models capture all essential in- meta model element). The aforementioned model- formation for architecting malleable and platform ing hierarchy makes it possible to integrate all the independent cloud applications. The (5+1) ap- (5+1) meta-models and facilitates organizing the proach is based on the assumption that virtual ma- different modeling elements into categories (lay- chines can deal with code level mismatches by let- ers) based on the cloud concern they address. ting software components run on low level infras- The core meta-model is a fairly comprehensive tructure. We argue that this assumption is reason- pivot model that describes the application’s deploy- able given cloud dynamics. The constant updat- ment architecture in terms of tasks and interactions. ing and multiple service providers that character- It clarifies the cloud service model and its require- izes cloud computing drives mismatches between ments in terms most vendors would understand. infrastructure and applications that impact deploy- Each of the other five meta-models further enrich ment architecture. The (5+1) view meta-models the expressiveness of the core model. The per- make this assumptions explicit. formance meta-model enables annotating the core Figure 3: The (5+1) Architectural View Model model with performance parameters. The adapta- different meta-model elements. We used the pro- tion meta-model specifies adaptation rules and ac- cess of cleaning and elimination to divide the meta- tions for each task or group of tasks in the core model into smaller meta-models to facilitate ex- model. The availability meta-model defines the plaining them. A meta-model normally consists model configurations (i.e., configuration models in of abstract syntax, well-formedness rules, and se- MAAS). Its components instantiate the core model mantics. While class diagrams are normally able to and distribute its instances to different geographic capture the syntax, and the natural language can be locations. The service workflow meta-model facil- used to specify the semantics; the well-formedness itates creating different service scenarios, by com- rules requires using a constraint language to fur- posing and executing core tasks in series to achieve ther specify the domain constraints. Due to page a certain goal. Finally, the provider meta-model limits the current paper does not cover the meta- creates a provider profile, which consists of the models well-formedness rules. However, a list of provider’s service templates and pricing profile. model validation constraints have been made avail- The meta-models described in this paper has able online on the StratusML webpage1. been created using the following process: we started from existing domain artifacts of three 4.2 The Service (Core) Meta-Model cloud providers (i.e., Amazon AWS, Windows The service (core) meta-model allows developers Azure and GAE), from which we created variabil- to describe cloud services using platform indepen- ity models to highlight their commonalities and dif- dent components, providing a high level descrip- ferences. We built one core meta-model [17], re- tion of resource requirements independently from alized it using a DSL modeling framework (i.e., any target platform, and specifying operational re- Microsoft-DSL). Then, we built several views quirements to be enforced and validated. More par- around the core meta-model by extending it with ticularly, the core meta-model enables service de- the required components to address various con- velopers to: (i) describe the structure of a cloud ser- cerns. The result was a huge meta-model, where vice composed of one or more Tasks, the types of all the model elements inherit one of six elements tasks, and their relationships, (ii) cluster tasks into each represent one of the six different meta-models groups for easy management, (iii) assign each task in Figure 3. Each element in the meta-model is then a predefined or custom service template type, and mapped to one visual component in the MS-DSL (iv) assign availability level to every task (e.g., low, framework. This paper does not cover the DSL medium, high), which constrains how it should syntax (the visual components) and semantics. The paper focuses on describing the (5+1) architectural 1http://www.stargroup.uwaterloo.ca/ view model views and elements by explaining the ˜mhamdaqa/stratusml Figure 4: The Core View Meta-Model be instantiated and replicated in the availability in our meta-model. model. A service template specifies the computa- The core meta-model captures all the concepts tion power, memory and storage of the virtual ma- that are needed to specify a cloud configuration chines available to host a task. Service template space, and facilitates dealing with inconsistencies types (e.g., small, medium, large, extra-large) vary between the different providers’ file structures. The based on the provider. The templates are specified main extensions of the core meta-model in Figure 4 using the provider meta-model. over the one presented in [17] are the concepts of Figure 4 depicts the core meta-model, which is Service, Activity, GroupableCoreComponent, and an extension of the cloud application meta-model Group. we presented in [17]. The original meta-model has A service inherits the CoreComponent. It con- been created as a carrier of the service model and tains at least one GroupableCoreComponent.A configuration parameters needed to port cloud ap- service is one level higher than a task in granularity. plications between different platforms. It is an ab- It is equivalent to a cloud application in the original straction layer on top of the PaaS layer that was meta-model. The new meta-model facilitates cre- defined after manually inspecting three cloud plat- ating several services within the same application. form application packaging requirements, namely Each of them consists of several virtual appliances Amazon Web Services (AWS), Windows Azure, (a.k.a. Tasks), Groups, and/or StorageMediums. and Google Application Engine (GAE). For exam- An activity is a sub-process of a task. Each task ple, an Elastic Beanstalk App in AWS, a Role in has at least one activity. Activities are essential for Azure, and a Module in GAE specifications all re- performance analysis. GroupableCoreComponents fer to a virtual appliance that is prepared with the can be nested so that certain properties apply to all required software stack to run a certain family of of them. A Group is a container that applies the applications (i.e., web, back-end). All these con- composite pattern; it inherits the GroupableCore- cepts have been abstracted with the concept of Task Component and can contain many GroupableCore- Figure 5: The Performance View Meta-Model

Component elements at once. tween the cloud resource model and its perfor- The current core meta-model distinguishes three mance specifications. Each Activity is linked to Ac- group categories: ScalabilityGroup, StorageGroup, tivityPerformance, Workload, and to itself through and AvailabilityGroup.A ScalabilityGroup can the Call reflexive relationship. The ActivityPerfor- overlap or be nested in any other group, regulated mance specifies the activity server performance pa- by adaptation rules. Components in the same Scal- rameters. It specifies that activity’s resource de- abilityGroup can be scaled via different Scaling- mand. The Workload specifies the intensity of de- Factors.A StorageGroup can nest only Storage- mand on that activity. The Call component spec- Tasks; although it inherits Group, it may not nest ifies the number of calls that each activity makes any other GroupableCoreComponent. This is en- to others, the types of these calls, the communi- forced by a validation constraint. Finally, an Avail- cation mechanism (InteractionType) used, as well abilityGroup nests components, which need to be as the size of the input and output messages as- hosted for the same location. It is a superclass for sociated with the calls. While an activity can be the three geolocation groups (i.e., Zone, Region, the source of several calls, each call is associated and DataCenter). Availability groups will be dis- with exactly two activities; a source and a target cussed in Section 4.5. activity. An InteractionType can be synchronous, asynchronous, or forward, with the same semantics as in LQN [15]. The Endpoint is connected to a 4.3 The Performance Meta-Model Network performance component that specifies the connection parameters. Finally, each Task is con- Figure 5 depicts the performance meta-model. Its nected to a HostingEnvironment. The HostingEn- elements were inspired by the UML performance vironment parameters can be inferred based on the analysis modeling profile (PAM), which is part of task type and the target PaaS provided as specified MARTE profile [1]. As shown in Figure 5, there in the provider meta-model. are five association relationships that connect three core components to corresponding performance as- In a nutshell, each task can perform several ac- pects. These links represent integration points be- tivities. Each activity has a phase that specifies the order of execution within the task, and a type tinuously satisfies operational requirements (e.g., that specifies whether it is normal activity or a join, minimum operational cost, high performance, and fork, or loop activity. Phase zero activities are al- high availability). A rule can control the number ways connected directly to the endpoint, they are of virtual appliance instances, or enable a security the first activities to receive a request in a task. An guard or policy. A rule uses a set of key perfor- activity can be linked to other activities within the mance indicators as operands. These are usually same task or with external tasks. Each activity be- collected though instrumentation and trace summa- longs to one or more workloads.A workload log- rization. ically groups all activities that are affected by the Figure 6 shows the adaptation meta-model. Each same traffic class and hence should be executed to- component or group of components is associated gether, while a task groups all activities that share with a set of actions. The meta-model enables two and utilize the same underlying resources. There types of actions, predefined and custom actions. are two types of workloads: open workloads, where While predefined actions are known ahead of time requests arrive at a given rate; and closed work- (e.g., scaler actions), custom actions allow assign- loads, where requests are generated by a fixed num- ing external processes. An action is triggered based ber of users (population). Since there is many- on a constraint or reactive adaptation rule.A Con- to-many relationship between activities and work- straintRule is a predefined (static) constraint, such loads, another entity is needed to specify the activ- as the min/max number of instances allowed at a ity execution path for each workload. The work- certain time. A ReactiveRule is dynamic, based on flow entity is part of the workflow view. Each per- evaluating runtime environment parameters against formance solution (PSolution) has a list of work- a set of key performance indicators (e.g., CPU uti- flows. Each workflow has a designated workload lization, queue length, response time). and an ordered list of the Activities performed by that workflow. A performance solution (PSolution) 4.5 The Availability Meta-Model also specifies the solution technique used in solving the performance model (i.e., analytical, or simula- tion).

4.4 The Adaptation Meta-Model

Figure 7: The Availability View Meta-Model

Figure 7 shows the availability meta-model. An availability zone refers to the distinct physical lo- cation of the available hosting data-centers of a Figure 6: The Adaptation View Meta-Model provider. An AvailabilityZoneGroup nests compo- nents that need to be hosted in the same availability The adaptation meta-model uses rules to con- zone. It contains several RegionGroups that vary trol the core. This enables many dynamic features based on the provider. A RegionGroup nests com- of the system, such as elasticity and security, and ponents that need to be hosted in the same region helps administrators ensure that the system con- and contains many DataCenterGroups. Lastly, a

Table 1: Availability and Fault Recovery Levels Specified Requirements (Core) Validation Constraint to be Checked Availability Fault Recovery Very Low N/A A task has one instance Low Fast A task has two instances in the same region Medium Average A task has two instances distributed into two different regions High Slow A task has two instances distributed into two availability-zones High Fast A task has three instances, two in the same region, and one in a different availability-zone Very High Fast A task has four instances, two in the same region, one in different region but same zone, and one in different availability zone

DataCenterGroup nests components that need to be hosted in the same datacenter. Selecting a spe- cific datacenter for an application is still not sup- ported by most providers. For each task in the core model, the availabil- ity meta-model allows administrators to specify the number of instances (TaskInstance) to instan- tiate (replication) and their distribution to differ- ent geolocations (AvailabilityGroups). Recall that in the core model a service developer specifies a provider for each task, and the required availability and fault recovery levels. The availability model assigns one of that provider’s available geoloca- tions for each task. This enables hybrid cloud de- ployments, where an application can span multi- Figure 8: The Workflow View Meta-Model ple providers. Once the administrator creates the availability model, and before the actual artifacts required for packaging and deploying the applica- ment. Each activity incident belongs to one activ- tion on a target platform are generated, a set of con- ity. This allows us to compose different workflows straint rules are validated to ensure that the avail- (execution scenarios) for the activities according to ability model conforms with requirements. Table 1 their runtime execution. shows a list of availability and fault recovery objec- tives, and their corresponding validity constraints. An activity can be classified as a normal, com- posite or control activity. A control activity links source and target activities and describes their ex- 4.6 The Workflow Meta-Model ecution sequence and concurrency. Depending on To represent system behaviour and enable opera- the control activity type, it can link one source to tional analysis, the (5+1) model adopts a simple one target (sequence), one source to many targets workflow meta-model. It specifies activity control (fork), or many sources (join). Activities that suc- structures that need to be executed in sequence to ceed a fork control can all be executed concurrently perform a certain work. As shown in Figure 8, the (and fork), or one at a time based on evaluating a two main components in the workflow meta-model boolean (or fork). Similarly, in an (and join) all are activities and activity incidents. A workflow predecessor activities must be executed before the model represents the actual occurrence of the ac- join, while in an (or join) the execution of any of tivities that are defined in the core model along the predecessor activities is enough to start execu- with the workload generator (from the performance tion of the join activity. The normal activity is an model) that is responsible for the activity enact- elementary activity that cannot be further decom- posed, while a composite activity contains (n) nor- 5 StratusML mal or complex activities and their control joint ac- tivities. We validated the feasibility of our approach us- Even though the workflow model is essential for ing StratusML [19]. StratusML is a cloud applica- performance analysis, it is better to model activ- tion modeling language that realizes the (5+1) view ity definitions, performance specifications and ac- model. It enables developers to design high qual- tual usage scenarios seperately. This separation ity, distributed, component-based applications tai- of concerns maximizes modeling flexibility, fosters lored for cloud deployment. StratusML permits the reuse, and facilitates modeling of the application’s layering of views, letting stakeholders view mod- behaviour at runtime. els from their perspective. Each meta-model in the (5+1) view model is dedicated a layer in Stra- tusML. Layers can be turned on/off at any time. 4.7 The Provider Meta-Model This lets stakeholders toggle between partial and holistic views, which makes complex models eas- ier to use. StratusML visually models adaptation rules and constraints. It automates the generation of corresponding artifacts for the target cloud fab- ric, using elegant template-driven transformations to generate complete platform specific artifacts. A full list of the capabilities of StratusML is beyond the scope of this paper. However, a recorded demo is publicly available [19]. Here, we summarize the StratusML framework, and examine it against the motivating example presented in Section 2 to demonstrate its usefulness in modeling cloud ap- plication requirements. Figure 9: The Provider View Meta-Model

Traditional software architectural approaches 5.1 The StratusML Framework Ar- presumes that an application will be developed chitecture for one , deployed on premises, and Figure 10 shows the StratusML framework archi- maintained locally. In the public cloud, we de- tecture. It is a model-view-controller framework velop for a multi-organizational systems of sys- that transforms, reconciles and adapts models. tems. The Provider meta-model aims to model Transformation, validation, and analysis are per- different providers’ templates, offers and costs. formed whenever models are updated to keep them Figure 9 depicts the Provider meta-model. Each consistent. Both the validator and editor/viewer provider provides a list of availability zones, and use the Stratus meta-model, which realizes the service templates. Availability zones represent the (5+1) meta-models in the Microsoft DSL defini- physical locations of provider data-centers, while tion language [11]. Figure 10 shows each (5+1) service templates capture different resource speci- meta-models in its own layer, viewable in the mod- fication bundles (i.e., CPU speed, number of cores, eling IDE. StratusML supports two transformation memory size, disk space) that serve as templates types: a model transformation that refines Platform for service tasks. The ability to specify resources Independent Models into Provider Specific Models; using predefined templates is a turning point in au- and template-based transformation that generates tomating performance analysis. This meta-model Platform Specific Models for target platforms. Fig- enables reusability at the resource model level, pro- ure 10 shows the transformation engine using the viding ready to use templates that represent ac- validated StratusML model, and applying template tual cloud provider templates. Each template has transformation on it to generate a target model. The a price that captures how much the resource con- model encapsulates essential data about the enti- figurations cost per bundle. These prices usually ties it must generate, while the template dictates the depend on a provider’s pricing models, contract pe- syntax of the target model. The last component in riod and terms (e.g., free, weekly, pay-as-you-go). the framework is the architecture-aware adaptation Cloud Application Models Platform Independent Level Model Workflow Custom Model Controller Provider Editor/Viewer Architecture Provider Model

Template-Based Model Model Performance Adaptation Availability Manager Transformation Validation Analyzer Model Model Model Admin QA Performance/Availability/ Core Service T Cost Model Developer Deployment Provider Target Domain Stratus Configuration Model Admin Model PSM Constraints Meta-Model

Update (redeploy, reconfigure) Update (reconfigure, reorganize, recompose) Architecture-Aware Adaptation Manager Execute Monitor

Platform Provider Platform Meta-Model Platform Independent Independent Model Model Specific Model + Provider Specific Model T Transformation Process Operation Data Flow Control Flow Stakeholder Template

Figure 10: The Architecture of the StratusML Framework manager, which deploys the generated models to was a frontend web MVC-style application that the target platform, and monitors the application’s was accessed by specific user groups (i.e., Coupon behaviour after deployment to reflect changes in Providers, Coupon Buyers, Admins and Marketing configuration and design. The adaptation man- Researchers). The first worker task was the appli- ager uses the auto-generated rules to manage the cation backend that handles all operations (logic application at runtime. It completes the applica- tier). The second was the analytics/data-crunching tion management process (i.e., Design, Plan, Pack- engine, which processed buy/sell data. There was age, Deploy, Run, Tune, Re-plan/Re-design). A also a storage tier, which consisted of blobs for detailed description of model validation, transfor- storing data collected from buy/sell dumps, and mation and the architecture-aware adaptation have queues for asynchronous communication between been omitted due to space limits. StratusML was worker and web tasks. We do not provide a step- built as an extension of Microsoft Visual Studio by-step design of this project using StratusML in 2012. It utilizes the Microsoft DSL for model def- this paper (a StratusML usage scenario has been initions and uses the Text Template Transforma- made available on the StratusML webpage); in- tion Toolkit (T4) to turn models into desired output stead, we highlight how the different layers and files [11]. StratusML lets stakeholders build mod- features of StratusML can foster collaboration be- els, and create (or use ready made) transformation tween stakeholders to facilitate creating and ana- templates. lyzing cloud projects. Table 2 lists the requirements of the CoupoNet stakeholders, extracted from the example, and the StratusML layer that can be used 5.2 Meeting CoupoNet Team Require- to address the stakeholders needs. The following ments discussion explains how the features provided in We used StratusML to model the CoupoNet appli- the different layer(s) address stakeholders require- cation described in Section 2, generating the arti- ments. facts required to: (i) deploy the application to mul- Core Layer: The core layer furnishes various tiple providers, (ii) manage the application, and groups (i.e., storage, availability, and scalability) (iii) analyze its performance. This involved three that assist in modeling multi-tenancy (R1) using web tasks and two worker tasks. Each web task different service/data partitioning strategies. Log-

Table 2: Stakeholder Requirements Matched to Corresponding Views in StratusML. CoupoNet Stakeholder Requirements Stakeholder (5+1) View / StratusML Layer R1. Model Multi-tenant applications. Service Developer Core R2. Model Multi-tier applications. Service Developer Core R3. Communicate architectural decisions to administrators. Service Developer Core + Availability R4. Estimate the number of instances required. Administrator / QA Performance + Workflow R5. Uncertainty about the required resources. Administrator Adaptation R6. Service distribution into multi geographic locations. Administrator Availability R7. Evaluate different provider offerings. Manager Provider R8. Migrate between different providers. Administrator/Manager Provider R9. Minimize administration and configuration tasks. Administrator/Manager All R10. Manage model co-evolution. Administrator All

ical (i.e., storage, scalability) and physical (i.e., availability) partitioning can be used to achieve iso- lation between the tenants to ensure privacy, man- age service access privileges, and scale the applica- tion components together. Each StorageMedium or Task in the core model can be configured according to one the following multi-tenancy models: Single Instance Multi Tenant (SIMT), Multi Instance Sin- gle Tenant (MIST) and Multi Instance Multi Tenant (MIMT). The core meta-model also provides plat- form independent task-templates that can be used for modeling frontend, backend and storage pro- cesses along with the connections needed to de- scribe interactions between tasks. This facilitates Figure 11: StratusML Activity Performance Ex- modeling multi-tier applications (R2). Plus since cerpt groups can overlap, grouped components can mi- grate and scale together. Using groups, architects can ensure their decisions (e.g., reducing coupling, mance models and using them to scale the appli- increasing cohesiveness) are preserved (R3), and cation is out of the scope of this paper and will be not carelessly overridden. addressed in future work. Adaptation Layer: Using the adaptation layer, Performance and Workflow Layers: Estimat- StratusML facilitates modeling adaptation rules ing system performance requires both performance and actions, with a focus on scalability actions. A and workflow layers. StratusML provides per- user can specify constraints and reactive rules, and formance components to specify the information associate them with a task or scaling group. The collected through monitoring. Figure 11 shows framework generates the rule-based configurations a screenshot of the performance information that required to automate resource provisioning. This can be specified for task activities. Once all solves the problem when required resources cannot the required perfromance information are specified be estimated at the beginning of the project (R5). transformation templates can be used to generate Figure 12 shows a screenshot of a task that is as- a traget performance model. The example in Stra- sociated with an adaptation action that is activated tusML web page shows how templates can be used based on a default constraint rule. to generate performance models from the specified Availability Layer: The availability layer pro- performance model information for various perfor- vides groups that makes it easier to manage the lo- mance analysis tools. Currently StratusML sup- cations and counts of task instances. This helps ports generating LQN models [15], which can be administrators model cloud service distribution to used to estimate the number of instances required multi-geographic locations (R6). Figure 13 shows (R4). A detailed example for generating perfor- an example of three tasks located in the same data Figure 14: StratusML Provider and Pricing Profile Figure 12: StratusML Adaptation Rule and Action Excerpt Excerpt pendent of platform, and refining models for target center. Each of them has only one instance as platforms, StratusML lets applications migrate be- shown from the link cardinality. An administrator tween different providers (R8). StratusML makes can easily instruct the cloud fabric to relocate the this easy via transformation templates customized instance into a different location within the same by platform, to auto-generate target platform arti- provider or even a different provider by changing facts. This reduces admin and configuration (R9), the instance properties. and facilitates model co-evolution (R10). Figure 14 is a snapshot that shows how platform specifications and pricing information can be spec- ified for different providers (i.e., Windows Azure).

6 Related Work Our work has taken shape in the context of a rich literature focused on viewpoint architecture frame- works, model-driven quality prediction, and cloud DSMLs . Viewpoint Architectural Frameworks: Using multiple views to explore systems from different angles is common practice in [13, 23, 25, 34]. There are many such frameworks used in . Krutchen [25] fa- Figure 13: StratusML Availability View Excerpt mously proposed four views: logical, development, process and physical; plus “use cases” as the fifth Provider Layer: This layer captures provider view, to completely describe the system lifecycle. specifications. Users can import a supported Zou and Pavlovski [36] extended the (4+1) view provider’s specifications, or create a custom one. model by adding a control case view to address Once imported, an admin can specify a designated non-functional system requirements. Most such ar- provider for each availability group, and then dis- chitectural frameworks are generic enough to de- tribute task instances to different groups. To eval- scribe large class of systems. However, they only uate different provider offerings (R7) the adminis- consider the dynamism and variability of the design trator or financial manager can select the availabil- models and assume a static deployment infrastruc- ity groups where instances are distributed, change ture. Even when deployment models are consid- them all for a specific provider, or allow hybrid set- ered, they are considered as part of the lifecycle tings. The pricing algorithm will loop on all in- and not a driver of architectural evolution. stances and use the pricing profile of each instance, The (5+1) model was inspired by the (4+1) reading off the instance size and the provider, to model process view [25]. In fact, if tasks are con- calculate the total cost of the configuration. By sidered processes, the (5+1) model can be seen as modeling service structure and configuration inde- an extension of the process view, distinguished by its focus on the cloud application ecosystem (rep- partial and holistic views to describe and analyze resented by variable deployment models, dynamic the cloud systems from different perspectives. infrastructure, and standardized service offerings). Cloud DSML: There have been several recent pro- The (5+1) model augments its core with elements posals for using MDE to develop cloud DSMLs that enable quality prediction. Its views are limited [2, 27]. MODAClouds [3], and CloudML [16] but expressive enough to cover operational require- are most related to our approach. Methods can ments and the application lifecycles in the cloud. be differentiated based on the features they pro- Model-Driven Quality Predication (MDQP): vide. What distinguishes StratusML from other Several MDQP approaches appear in the literature. languages is its ability to provide partial and holis- Many were surveyed in [12, 22, 24]. According tic views of the different cloud application con- to Koziolek’s [24] classification, the main three cerns using layers, its ability to visually model categories for MDQP approaches are prediction adaptation rules and actions, and its ability to deal based on: (i) UML (e.g., CB-SPE [5], SPT [28], with platform heterogeneity using template-based MARTE [1]) (ii) proprietary meta-models (e.g., transformations. CBML [33], KLAPER [10], ROBOCOP [7], PAL- LADIO [4]), and (iii) middle-ware (e.g., NICTA [26]). Our approach relies on a proprietary meta- 7 Conclusions model. MDQP frameworks can be differentiated We presented a new (5+1) architectural view model by (i) the non-functional properties they model, and for cloud applications. It was realized as a cloud (ii) their accurate depiction of both software and re- DSML, StratusML, using layers to enable both par- source models. Most focus on performance analy- tial and holistic views. The model promotes flexi- sis and software modeling. Some frameworks that bility, portability, reusability and productivity. We support non-functional properties and enable hard- showed how StratusML supports cloud stakeholder ware and software modeling include MARTE [1], collaboration. The (5+1) model was designed for and Descartes (DML) [8]. Like Descartes, we the cloud domain, but it applies to any large dis- model dynamic systems on dynamic infrastructure, tributed system where software evolves in a dy- but we differ from both MARTE and Descartes by namic environment. being cloud specific. Both generic and specific The original contributions of this research are: frameworks have pros and cons [9]. For exam- (i) a new cloud specific architecture view model ple, while both we and Descartes model adapta- taking service models as first class entities, and tion requirements and actions, Descartes’ generic building views that address cloud application evo- method models multiple strategies. In compari- lution at runtime; (ii) naming the “Malleable Ap- son, we currently only model rule-based adapta- plication Architectural Style”, commonly used in tion. However, since most cloud providers support cloud computing, to facilitate managing cloud con- rule-based adaptation and provide rule engines, our figuration spaces and promote architectural self- framework does generate the actual artifacts (rule awareness; (iii) addressing the main service oper- files) needed to control applications at runtime. ational attributes needed to architect high quality Descartes requires framework-specific strategies, cloud applications using proprietary meta-models which can complicate automation and model trans- that augment the cloud core service/resource model formation. with quality-related concepts and attributes; and Runtime Models: The problem described in this (iv) realizing the (5+1) view model as a cloud paper is also related to managing and configuring DSML, using layers to enable toggling between software systems at runtime [6]. Using runtime partial and holistic views, facilitating dynamic be- models to manage software systems is not new. haviour modeling using adaptation rules and ac- Several approaches have been developed to address tions, and “weaving” stakeholder concerns together this problem [14, 29]. Recently, Zhang et al. lever- to generate useful artifacts. aged runtime models for the management of di- Future research directions include extending the verse cloud resources [35]. Other than being cloud scenario presented here to (i) showcase other fea- domain specific, our approach distinguishes itself tures of StratusML, (ii) show how the models pre- in the way it weaves the different models together sented here can be used for performance prediction, with the service model, and its ability to provide software adaptation, availability maximization and cost minimization, and (iii) to present concrete ex- [9] W. Chehade, A. Radermacher, F. Terrier, amples for model transformation and platform spe- B. Selic, ans Se.´ Gerard.´ A model-driven cific artifact generation. framework for the development of portable real-time embedded systems. In: the Interna- tional Conference on Engineering of Complex References Computer Systems, pp. 45-54. (2011). [1] The Object Management Group. UML Profile for MARTE: Modeling and anal- [10] A. Ciancone, A. Filieri, M. L. Drago, R. Mi- ysis of real-time embedded systems, randola, and V. Grassi. KlaperSuite: An inte- Version 1.1. OMG Document Number: grated model-driven environment for reliabil- formal/2011-06-02 [Online]. Available: ity and performance analysis of component- http://www.omg.org/spec/MARTE/1.1, based systems, In: Bishop, J., Vallecillo, A. (2011). (eds.) Objects, Models, Components, Patterns. LCNS, vol. 6705, pp. 99-114. Springer, Hei- [2] M. Almorsy, J. Grundy, and A. Ibrahim. delberg (2011). Adaptable, model-driven security engineering for SaaS cloud-based applications. Automated [11] S. Cook, C. Jones, S. Kent, and A.C. Wills. Software Engineering, Springer, 1-38 (2013). Domain-specific development with Visual Stu- dio DSL tools. Addison-Wesley Professional [3] D. Ardagna, E. Di Nitto, P. Mohagheghi, et al. (2007). Modaclouds: A model-driven approach for the design and execution of applications on multi- [12] V. Cortellessa, A. Di Marco, and P. Inver- ple clouds. In: ICSE Workshop on Modeling ardi. Model-based software performance anal- in Software Engineering, pp. 50-56. (2012). ysis. Springer (2011).

[4] S. Becker, H. Koziolek, and R. Reussner. The [13] Department of Defense Architecture Frame- Palladio component model for model-driven work Working Group et al. DoD architecture performance prediction. Journal of Systems framework, Version 1.5. Department of De- and Software, 82(1): 3-22 (2009). fense, USA, (2007).

[5] A. Bertolino and R. Mirandola. CB- [14] R. France and B. Rumpe. Model-Driven De- SPE Tool: Putting component-based perfor- velopment of Complex Software: A research mance engineering into practice In: Crnkovic, roadmap. In: Future of Software Engineering, I., Stafford, J., Schmidt, H., Wallnau, K. pp. 37-54. (2007). (eds.) Component-Based - ing. LCNS, vol. 3054, pp. 233-248. Springer, [15] G. Franks, T. Al-Omari, M. Woodside, Heidelberg (2004). O. Das, and S. Derisavi. Enhanced Modeling and Solution of Layered Queueing Networks. [6] G. Blair, N. Bencomo, and R. B. France. Mod- IEEE Transactions on Software Engineering, els@ run.time. Computer, 42(10): 22-27 35(2): 148-161 (2009). (2009). [16] G. Gonc¸alves, P. Endo, M. Santos, D. Sadok, [7] E. Bondarev, J. Muskens, M. Chaudron, et al. CloudML: An integrated language for J. Lukkien, et al. Predicting real-time prop- resource, service and request description for erties of component assemblies: A scenario- d-clouds. In: the International Conference simulation approach. In: Euromicro Confer- on Cloud Computing Technology and Science, ence, pp. 40-47 (2004). pp. 399-406. (2011).

[8] F. Brosig, N. Huber, and S. Kounev. [17] M. Hamdaqa, T. Livogiannis, and L. Tahvil- Architecture-level software performance dari. A reference model for developing cloud abstractions for online performance predic- applications. In: the International Conference tion. Science of , 1-22 on Cloud Computing and Services Science, pp. (2013). 98-103. (2011) [18] M. Hamdaqa, and L. Tahvildari. Cloud com- [29] H. Song, Y. Xiong, F. Chauvel, G. Huang, puting uncovered: A research landscape. Ad- Z. Hu, and H. Mei. Generating synchroniza- vances in , (86): 41-85 (2011). tion engines between running systems and their model-based views. In: Model-Driven Engi- [19] M. Hamdaqa and L. Tahvildari. StratusML: neering Languages and Systems, pp. 140-154. A layered cloud applications modeling lan- (2010). guage. Demo Video, [Online]. Available: http://www.stargroup.uwaterloo. [30] C. Szyperski, J. Bosch, and W. Weck. ca/˜mhamdaqa/stratusml, (2013). Component-oriented programming. In: the Eu- ropean Conference on Object-Oriented Tech- [20] J. D. Herbsleb. Global software engineering: nology, pp. 795-795. (1999). The future of socio-technical coordination. In: Future of Software Engineering, pp. 188-198. [31] R. N. Taylor, N. Medvidovic, and P. Oreizy. (2007). Architectural styles for runtime software adap- tation. In: Joint Working IEEE/IFIP Con- [21] P. Horn. Autonomic Computing: IBM’s ference on & European Perspective on the State of Information Tech- Conference on Software Architecture, pp. 171- nology. IBM Computing Systems, (15): 1-40 180. (2009). (2001). [32] P. Vitharana, H. Jain, and F. Zahedi. Strategy- [22] M. Isa, M. Z. Zaki, and D. N. Jawawi. A based design of reusable business components. Survey of Design Model for Quality Analy- IEEE Transactions on Systems, Man, and Cy- sis: From a performance and reliability per- bernetics, Part C: Applications and Reviews, spective. Computer and , 34(4):460-474 (2004). 6(2): 55-70 (2013). [33] X. Wu and M. Woodside. Performance [23] A. C. Klug and D. Tsichritzis. Multiple view modeling from software components. ACM support within the ansi/sparc framework. In: SIGSOFT Software Engineering Notes, 29(1): the International Conference on Very Large 290-301 (2004). Data Bases, vol. 3, pp. 477-488. (1977). [34] J. A. Zachman. A framework for informa- [24] H. Koziolek. Performance evaluation of tion . IBM Systems Jour- component-based software systems: A sur- nal, 26(3):276-292 (1987). vey. Performance Evaluation, 67(8): 634–658 (2010). [35] X. Zhang, X. Chen, Y. Zhang, Y. Wu, W. Yao, G. Huang, and Q. Lin. Runtime model [25] P. B. Kruchten. The 4+1 view model of archi- based management of diverse cloud resources. tecture. IEEE Software, 12(6): 42-50 (1995). In: Model-Driven Engineering Languages and [26] Y. Liu, I. Gorton, and A. Fekete. Design- Systems, pp. 572-588. (2013). level performance prediction of component- [36] J. Zou and C. J. Pavlovski. Modeling archi- based applications. IEEE Transactions on Soft- tectural non functional requirements: from use ware Engineering, 31(11): 928-941 (2005). case to control case. In: the International Con- [27] D. Petcu, B. Di Martino, S. Venticinque, et al. ference on e-Business Engineering, pp. 315- Experiences in building a mosaic of clouds. 322. (2006). Journal of Cloud Computing: Advances, Sys- tems and Applications, 2(1): 1-22 (2013). [28] B. Selic, A. Moore, M. Woodside, B. Wat- son, M. Bjorkander, M. Gerhardt, and D. Petriu. UML profile for schedulabil- ity, performance and time. OMG doc- ument, Version 1.1, [Online]. Available: http://www.omg.org/spec/SPTP/1.1, (2005).