The (5+1) Architectural View Model for Cloud Applications Mohammad Hamdaqa, Ladan Tahvildari Software Technologies Applied Research (STAR) Group Department of Electrical and Computer Engineering University of Waterloo, Canada fmhamdaqa, [email protected] Abstract Existing software architecture 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- Zachman framework [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 software design, 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 system from a differ- under changing conditions. This shift in emphasis ent perspective to meet the information 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 requirements 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 modeling language (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 data, 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 systems. 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