The Cloud Architecture Building Blocks

A software system can be decomposed into components of different granularity levels. A component is “a unit of composition with contractually specified interfaces and explicit

context dependencies” [149]. It can be an object, a service, a microservice [151], a program instance, or a virtual machine image.

Components are usually designated based on the type of input they consume and out- put they provide. Modern service oriented programming models (e.g., OSGi, SCA, Jini) describe components as functional units of composition that take services as input (i. e., by referencing them) and provide services as output (i.e., by exposing service contracts). Cloud systems follow the same trend. However, in cloud computing, services are classified into layers (i.e. Software as a Service (SaaS), Platform as a Service (PaaS), and Infras- tructure as a Service (IaaS)), where components in upper layers consume services from the same layer or the layer below and provide services to be used in composing other services or applications at the upper layers. The higher the service layer that hosts the component, the courser the granularity of the component.

Selecting the right granularity level of components can have a significant impact on the software architecture. It can affect the complexity of the design, the ability to reuse the architectural elements, and the quality of the architecture. This section, analyzes the cloud applications’ components to determine which level is the best in order to describe a cloud application in a way that maximizes controllability and ensures the cloud application scalability, availability and portability.

Figure3.3 shows the different units of composition of a cloud application as perceived by developers at different service deployment layers. As shown in the figure, it is possible to distinguish three different units of composition.

(i) Services at the SaaS layer : A SaaS service is an application provided as a service that consists of at least one Task. Services can be orchestrated into business processes using any SOA business process modeling language.

(ii) Tasks at the PaaS layer: Each service at the SaaS layer is composed of a set of collaborative Task s at the platform level (PaaS), in addition to the definitions and relationships between these Task s, and their logical configurations.

(iii) Processes at IaaS layer: A Task with its platform configuration is packaged as a virtual machine image to be deployed as a running process on a cloud infrastructure. Several tasks can be packaged in the same virtual machine image.

As shown in Figure3.3, at each of the service layers (i.e., SaaS, PaaS, IaaS) the appli- cation consists of components that consume the layer beneath services to provide higher

Figure 3.3: Cloud Application Components Granularity.

level services. When the services consumed are middleware services, the developer’s fo- cus will be on the component itself (Task) and How to exploit the middleware services to build a task that can address both the functional and non-functional requirements of the application (i.e., service). In contrast, when the consumer services represent business functionalities, the developers’ attention will be on What are the services needed in order to achieve the business goal.

Coarse-grained components have higher contributions towards the solution; hence, they have high reuse efficiency. However, because coarse grained components are tailored to provide solutions for specific problems, they have a lower level of reusability. Moreover, course-grained components abstracts the technical details of the platform; hence they are more useful for modeling business processes. In contrast, fine grained components are more suitable for technical-level design that is why they are more favorable by developers.

Accordingly, the layer of abstraction selected is on the top of the PaaS layer. The selection of PaaS as the layer of abstraction has been made based on the following criteria:

(i) Level of Detail: To maximize reuse and bridge the gap between business require- ments and the technical implementations, If a component does not have the ability to fully express the requirements through configuration, its granularity level should be decreased. Accordingly, the right granularity of the main unit of composition should

Figure 3.4: The Tradeoffs between Applications’ Portability and the Level of Automation.

enable translating the requirements into functionalities that utilize the middleware capabilities of the cloud platforms.

(ii) Application Manageability: Granularity has a negative correlation with manage- rial goals, such as cost effectiveness, customization and maintainability[158], and a positive correlation with component assembly. Selecting the granularity at the PaaS level enables taking advantage of both.

(iii) Reduce Coupling and Design Complexity: Raising the granularity of the com- ponents can create a level of abstraction that simplifies the communication with the upper layers. This is important for distributed applications (e.g., cloud applications) where remote service invocations may lead to network performance problems. On the other hand, decreasing the level of granularity can decrease design complexity. A balance between fine- and coarse-grain components can help address both issues. (iv) Automation vs. Portability: Portability and automation vary between SaaS,

PaaS, and IaaS. In general, the number of constraints increase as we move up to the SaaS layer. The more the constraints the less the portability and the higher the risk of vendor lock-in. On the other hand, while cloud infrastructures enable quality attributes, such as dynamic elasticity, and high availability; these attributes cannot be fully addressed at the infrastructure level. The higher the level of abstraction the easier to automate these characteristics. This makes the PaaS layer the best candidate to support portability and enable automation.

lecting the right granularity level can assist in alleviating many architectural issues. Based on our analysis the best level of abstraction to achieve the highest flexibility to control the cloud application quality is right above the PaaS layer and below the SaaS layer. Hence, a cloud task is the basic unit of granularity and the main composition unit for cloud appli- cations. Tasks can be composed into services and can migrate between platforms without the need to perform any changes to their code. Changes can only be applied to the defi- nition and configuration artifacts. More about cloud Tasks types and relationships will be addressed later in the next chapter.