The (5+1) Architectural View Model

Fragmenting models into artifacts based on machine prespectives faciliates automation and increases flexibility. Unfortunately, this fragmentation makes it difficult for humans (cloud stakeholders) to create and comprehend these models. The information in these frag- mented models are usually specified by different stockholders. Moreover, this information is often overlaps on variety of ways. Accourdingly, there is a need to weave the fragmented models into views that enable stakeholders to better understand the runtime dynamics and evolution of complex cloud applications. This section analyzes the artifacts in MAAS from architecutral prespective based on dependency and containment relationships, and the stakeholders involved in specifying the different parts of these artifacts. Accordingly, we propose the (5+1) architectural view model, where each view corresponds to a different perspective on cloud application deployment.

Figure3.9 shows a high level architectural perspective of the relationship between the different artifacts required to deploy an application on a target platform. As show in the figure, the service model plays a centralized role in this architecture. To deploy an ap- plication onto a cloud platform; architects need to partition the application into software processes and package them into loosely coupled software modules (i.e., Tasks) with the re- quired software stack and app or web servers, and determine the virtual resources required to run the modules. Accordingly, a service template with the required specification can be selected and the application can be packaged into a set of Virtual Machine Images (VMI). Administrators then can instantiate and replicate these VMIs into the target cloud data- centers and specify the rules that govern any configuration changes based on monitoring the environment conditions (e.g., load), or by analyzing the system using the performance models that is created by the performance engineers.

Figure3.10 shows the (5+1) architectural view model. The (5+1) view model consists of five model views that specify the core/service model view to address five different, but interleaved cloud concerns related to service deployment and evolution. Each model view conforms to its corresponding meta-model. Moreover, the top element in all the model view meta-models extends the (5+1) component (i.e., a meta-meta model element). The aforementioned modeling hierarchy makes it possible to integrate all the (5+1) meta-models and facilitates organizing the different modeling elements into categories (layers) based on the cloud concern they address.

Figure 3.9: The Architectural Perspectives of Cloud Stakeholders

The details of each of the (5+1) meta-models and the methodology of defining them will be explained as part of defining the StratusML modeling language in chapters 4and5 respectively. These meta-models capture all essential information for architecting mal- leable and platform independent cloud applications. The (5+1) approach is based on the assumption that containers can deal with code level mismatches by letting software com- ponents run on low level infrastructure. We argue that this assumption is reasonable given cloud dynamics. The constant updating and multiple service providers that characterizes cloud computing drives mismatches between infrastructure and applications that impact deployment architecture. The (5+1) view meta-models make this assumptions explicit.

In a nutshell, the core meta-model is a fairly comprehensive pivot model that describes the application’s deployment architecture in terms of tasks and interactions. It clarifies the cloud service model and its requirements in terms most vendors would understand. Each of the other five meta-models further enrich the expressiveness of the core model. The performance meta-model enables annotating the core model with performance parameters. The adaptation meta-model specifies adaptation rules and actions for each task or group of

Figure 3.10: The (5+1) Architectural View Model

tasks in the core model. The availability meta-model defines the model configurations (i.e., configuration models in MAAS). Its components instantiate the core model and distribute its instances to different geographic locations. The service workflow meta-model facilitates creating different service scenarios, by composing and executing core tasks in series to achieve a certain goal. Finally, the provider meta-model creates a provider profile, which consists of the provider’s service templates and pricing profile.

3.4

Summary

This chapter introduced the (5+1) view model for cloud applications. The (5+1) view model is an architectural framework that captures the essence and the detail of the cloud applications’ characteristics that affect their dynamic evolution at runtime. It enables cloud stakeholders (e.g., providers, developers, administrators, performance engineers and finan- cial managers) to leverage cloud platform capabilities to maximize availability, maintain performance levels, minimize costs, and leverage portability and scalability.

At the core of the (5+1) is the cloud application service model. This model describes a reconfigurable executable units of composition that we call Task s. The service model is

further specified using a set of four operational model views that address the application performance, adaptation, availability, and execution scenarios, and one model that ad- dress the portability and operational cost of the application though capturing the platform providers specifications.

Chapter 4

StratusML: A Domain Specific

Modeling Language for Cloud

Applications

“I believe in a visual language that should be as strong as the written word.” – David LaChapelle, 1963

It is widely acknowledged within the software engineering community that architec- tural languages are defined by stakeholder concerns [95,101], and that a single “universal” notation (e.g., UML) is impractical to address all the concerns of a particular domain [95]. A domain language is usually needed. As explained in chapter 3, in the cloud domain, an application evolves at runtime to meet performance, availability, and scalability targets under changing conditions; a routine task that involves continuous changes to the appli- cation service models and deployment artifacts. While each stakeholder may conduct a certain type of change to address a specific concern, the impact of a change may span across multiple models and influence the decisions of several stakeholders. This chapter presents StratusML, a multi-cloud (i.e., platform independent) modeling framework and domain specific modeling language for cloud applications. StratusML is a realization of the (5+1) view model. It aims to satisfy the cloud stakeholders need to model and evolve applications that leverage cloud computing for maximum value with minimum conflicts between the stakeholders.

The rest of this chapter is organized as follows. Section4.1, presents an example of the cloud configuration space artifacts (i.e., what we are modeling). Section 4.2 provides an

overview of the StratusML modeling framework, its features, architecture, the methodol- ogy followed to build the framework, and its implementation. Section4.3 dives deeper into the StratusML language: abstract syntax, well-formdness rules and semantics. Section4.4 shows how the StratusML model concepts is mapped to the cloud specific platform con- structs. Section 4.5 demonstrates the framework capabilities using an example. Finally, Section4.6 summarizes the chapter.