Project Topics
Get Complete Project Material File(s) Now! »
Theoretical Background
This section describes the theoretical baseline for the rest of the thesis. First, the important definitions as used in the research are introduced and then the existing research in the fields of architectural patterns and cloud related to the subject of the thesis is reviewed
Important definitions
Cloud computing
“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models” (NIST: Mell & Grance, 2011). In this model a vendor provides cloud computing services to consumers. In that sense consumers are those who rent cloud computing resources from a vendor. Consumers typically use these resources either for their own needs or for building their own systems which are in turn offered to their own clients or to end-users.
The five essential characteristics mentioned are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service (NIST: Mell & Grance, 2011).
On-demand self-service allows cloud consumers to provision on their own the computational resources they need without redundant interaction with the vendor.
The capabilities provided by vendors are available over the network through a standard protocol and often represent coherent services – this is the broad network access. This setting is similar to the service-oriented model, where software services are available on the network; in that sense cloud computing extends the service-oriented model, but it also uses it. The broad network access characteristic means that using and integrating the provided capabilities over the network is an important aspect when architecting cloud systems thus featuring loose coupling similar to distributed systems.
As for resource pooling the computing resources are provided to multiple consumers through dynamic reallocation hidden from the consumers. The consumers are served in a dynamic multi-tenant model. Multi-tenancy means that different consumers may use the same physical or virtual hardware resources or instantiations of software systems at the same time with their data and resources still kept separated – the consumers are simultaneously tenants in the same resource (Bass, et al., 2012) . Further, the resources are abstracted in a way that almost hides their concrete distribution and location; “almost” because sometimes they are provided with the notion of geographical areas. The consumer has “no control or knowledge over the exact location of the provided resources” (NIST:Mell & Grance, 2011). Thus a system in the cloud needs to be designed from a location-agnostic distributed perspective.
Rapid elasticity is concerned with the ability to manually or even automatically scale up and down resources, i.e. allocate to the consumer more or less resources respectively. This characteristic influences the way systems are architected because as scaling might even happen automatically, systems should be designed in a way that utilizes this opportunity or at least does not suffer from it (Varia, 2011, p. 9).
Finally, the service is measured – the resources used are metered and usually there is a cost of usage that the consumers pay. As consumers can determine their resource usage and thus the costs they pay, this brings forward costs of operation as a non-functional requirement which needs to be addressed in the software architecture (Krishna & Jayakrishnan, 2013, pp. 89-90).
Other implications of these cloud characteristics upon architecture are increased importance of concurrent, asynchronous and parallel processing, data transfer and partitioning (Krishna & Jayakrishnan, 2013, p. 83).
Before going into the service models an important term needs to be introduced. According to NIST (2011), cloud infrastructure is “the collection of hardware and software that enables the five essential characteristics of cloud computing”. It can be viewed in terms of two layers: physical layer consisting of the hardware resources and an abstraction layer consisting of “the software deployed across the physical layer, which manifests the essential cloud characteristics”.
The three service models as illustrated in Figure 1 are Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) (NIST: Mell & Grance, 2011). In the figure, as well as often in the literature, systems deployed in the cloud are denoted with the term “cloud applications”. Those cloud applications utilizing the specific cloud characteristics and models are in turn called cloud-native applications (Fehling, et al., 2014a, p. 5).
In essence SaaS provides cloud computing consumers with the ability to consume a cloud-running service/application with a very limited possibilities for configuration (NIST: Mell & Grance, 2011, p. 2). As in this service model the role of the consumer is limited to only using resources, this model falls outside the scope of this research – cloud computing consumers do not design and build applications on their own in that service model.
PaaS gives the cloud computing consumer the ability to deploy to the cloud infrastructure and build their own applications (possibly providing them as SaaS later) on top of a mostly predefined infrastructure (NIST: Mell & Grance, 2011, p. 2). This means that architecting software solutions applies to this service model. Designing for this cloud service model is constrained by what the vendor offers, thus a number of technical architectural constraints are present and need to be accounted for depending on the chosen vendor.
Lastly, IaaS goes further allowing the cloud computing consumer to “provision processing, storage, networks, and other fundamental computing resources” (NIST: Mell & Grance, 2011, p. 2). This service model gives the most freedom to cloud computing consumers removing many of the limitations from PaaS. This freedom brings software design and development for this service model closer to traditional environments allowing for creating more complex systems with more complex architectures.
Finally, the four deployment models are private, community, public and hybrid cloud. The private cloud is operated for a single organization only, the community cloud operates for a community, the public cloud is available to anyone and the hybrid cloud is “a composition of two or more distinct cloud infrastructures” (NIST: Mell & Grance, 2011, p. 2). As the private cloud is intended to serve an organization, then this organization could use it for any purpose including building own systems which falls within the scope of the paper. As for a hybrid cloud, the existence of such a deployment model emphasizes the broad network access characteristic.
Cloud computing itself and the applications built on top of cloud infrastructure are inherently service-oriented (Guha, 2013) and distributed (Zhang, et al., 2010; Fehling, et al., 2014a). Computing resources are provided as services over the network with the three service models discussed above. Cloud applications use these services and due to the cloud computing characteristics, especially resource pooling and broad network access, the system architecture also needs to be more or less service-oriented and distributed. Thus loose coupling and integration of distributed services are clearly outlined as important aspects of architecting for the cloud
Software architecture
Although numerous attempts have been made to provide a definition for software architecture, “no universal definition of software architecture exists” (Clements, et al., 2010, p. 3) . On the web site of the Software Engineering Institute (SEI) hundreds of definitions are gathered. Yet, as Clements et al. point out, although there is still no universal definition, all definitions gathered have a “centroid” which is relatively apparent and “from which very useful progress could be made”. Two definitions that capture this centroid are the following:
- Software architecture is the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (ISO, 2011a)
- “Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled” (Woods, 2014)
The first definition is taken from the ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description standard and is more formal, whereas the second definition is closer to practice with a project focus. These show several important concepts important for understanding what software architecture is. Here some of the concepts crucial for this paper are outlined.
First, software architecture is a “conception of a system… [and it] may exist without ever being written down” (ISO, 2011a).
Second, in the ISO/IEC/IEEE 42010:2011 standard “every system is considered in the context of its environment” (ISO, 2011a). Environment is meant as a complex system of people, organization and system concerns with all their aspects. Then the software architecture of a system is observed and is influenced by the system environment. In the context of this thesis two broadly-defined types of system environments are investigated: the traditional and the cloud environment. As already mentioned in the introduction section “traditional” is used as a synonym for “not cloud”.
Finally, the second definition emphasizes the decision aspect of software architecture that may not be immediately obvious from the first definition. Designing a software system is a complex decision-making process. The ISO/IEC/IEEE 42010:2011 definition notes that the software architecture is embodied in its design principles. Rozanski & Woods (2011) describe an architectural design principle as “fundamental statement of belief, approach, or intent that guides the definition of your architecture”. It may be based on, for example, personal experience, customer requirements or established good practices; examples of such principles can be found in (Vogel, et al., 2011, pp. 118-140). Apart from architectural principles, architectural decisions may also be triggered by, for instance, technological or business constraints (Clements, et al., 2010, p. 7) or by a lack of knowledge in a specific area. Regardless of the trigger, architectural decisions could be rather implicit and undocumented. Architectural decisions shape the software architecture and their significance has been widely accepted. Documenting them has also become a hot research topic in the last few years.
Clements et al. (2010, pp. 6-9) discuss another important issue: the difference between architecture and design. According to them “architecture is design, but not all design is architectural”, thus differentiating between architectural and non-architectural design and design decisions. Discerning between what is architectural and what is not is a subjective matter that also depends on the context. This underlines the importance of the discussion of the centroid above, but as the terms are rather abstract, they are also subject to interpretation. Another case in which the difference between architectural and non-architectural design is important is patterns
Patterns
A pattern “describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” (Alexander, et al., 1977). Although this definition was initially intended for the building architecture field, it became widespread and pattern-related studies have been conducted in many fields such as organizational management, education and software.
In the software engineering context the consideration of patterns and their proper utilization has become an important part of effective and high-quality design. Patterns are often discussed in terms of the pattern as a description supplemented with a model of a solution for a given context and a pattern instance which is a concrete implementation of the pattern (Kobayashi & Saeki, 1999).
As outlined previously, the concepts of software design and software architecture are related. Following this logic, patterns can be viewed as architectural and non-architectural. The categorization of patterns presented by Buschmann, et al. (1996) confirms this view, defining three categories of patterns: architectural patterns, design patterns and idioms. As with the discussion about software architecture, the difference especially between architectural and design patterns is quite subjective and is sometimes hard to call. That is the reason why in some literature this is not even attempted (Fowler, et al., 2002). In other cases it is arguable, but in this thesis differentiation is fundamental.
An architectural pattern describes “a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them” (Buschmann, et al., 1996). Architectural patterns encompass a well-proven experience in building software systems by providing a generic solution with specific characteristics. As pattern-oriented software architecture research has shown architectural patterns can provide “a structural framework for a software system”, but they do not represent a complete software architecture; they need to be further refined and specified to the system needs (Buschmann, et al., 1996). Attractive as patterns are, overcommitting to them is hazardous. As with any other type of pattern, architectural patterns need to be well-understood and used in their proper context. If so, they effectively help the architect in taking important design decisions with less risk.
According to the classic book of Gamma et al, a design pattern provides “a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context” (Buschmann, et al., 1996). The difference with architectural patterns lies in the impact on the system – architectural patterns define the fundamental structure to subsystems and other building blocks, whereas design patterns refine a specific subsystem design. Yet, as already stated, the boundary is not always obvious nor even possible to be defined. For example, in smaller systems such as a stand-alone mobile application, choosing a design pattern may have such a significant impact on the system architecture that the design pattern essentially becomes an architectural pattern
1 Introduction
1.1 BACKGROUND
1.2 PURPOSE AND RESEARCH QUESTIONS
1.3 DELIMITATIONS
1.4 CONVENTIONS
1.5 OUTLINE
2 Theoretical Background
2.1 IMPORTANT DEFINITIONS
2.2 RELATED WORK
3 Research Method
3.1 CHOICE OF METHOD
3.2 DESIGN SCIENCE RESEARCH
3.3 IMPLEMENTATION
4 Design and Development
4.1 CLOUD APPLICABILITY TAXONOMY OF ARCHITECTURAL PATTERNS (CATAP)
4.2 PATTERNS-TO-CHARACTERISTICS MAPPING
4.3 PATTERN FORM
4.5 APE WIKI
5 Demonstration
5.1 DEMONSTRATION IN THIS RESEARCH
5.2 OPTIONS FOR EXTENSION
6 Evaluation
6.1 EVALUATION IN THIS RESEARCH
6.2 OPTIONS FOR EXTENSION
7 Discussion and Conclusions
7.1 DISCUSSION OF RESEARCH METHOD
7.2 DISCUSSION OF FINDINGS
7.3 OPTIONS FOR FUTURE RESEARCH
References
GET THE COMPLETE PROJECT
