# Enabling Role-Based Orchestration for Cloud Applications
## 2 Background Technology for Cloud Orchestration
### Standard Models for Cloud Application Orchestration  
Our orchestration approach leverages existing cloud orchestration standards, the most relevant ones of which are TOSCA (Topology and Orchestration Specification for Cloud Applications) and OAM (Open Application Model). OASIS TOSCA is an OASIS standard that aims to enable portable specification of cloud applications. According to the standard, an application topology is defined in an underlying platform-agnostic way in order to promote the application interoperability and portability across different cloud providers [7; 8]. To define the topology of applications, TOSCA provides a type system that can model applications' components as typed Nodes and relationships among the components as typed Relationships. Besides basic properties and interfaces, typed Nodes and Relationships also have Capability and Requirement by which application designers specify dependencies among components in terms of component functionalities. A component may be defined to provide a certain ability as a typed entity or require an ability also defined as a typed entity provided by others. As an example, consider a WordPress application, connected to a MongoDB database that can adapt to input fluctuations with auto-scaling capability enabled. As shown in Figure 1, the application can be defined as a TOSCA service template that is composed by a Topology Template along with accompanying types. In other words, the application's parts and their relationships can be modeled and specified using the TOSCA vocabulary. Additionally, TOSCA offers rich design primitives for specifying orchestration constraints and behaviors within a declarative service template configuration, such as policy and workflow [9]. Policy can be defined to express non-functional requirements applied to a group of typed nodes. Workflow is also known as Plan in TOSCA that includes a set of sequential tasks for fulfilling a certain orchestration task. Our approach employs the TOSCA standard as a domain-specific language for describing the topology of applications and defining their orchestration workflows. OAM is a runtime-agnostic modeling and specification standard for defining cloud applications [10]. Focused on the application layer rather than underlying platform resources or the infrastructure layer, OAM aims to model applications in a modular, extensible, and portable way, enabling application delivery to diverse target platforms. Distinguishing between parts that application developers and operators are responsible for, OAM argues for separation of roles' concerns when defining applications. With regard to the standard, an application is composed of two parts mainly; the first is the component inside which the application logic resides to provide its service, while the other is the specification of operational characteristics for the component. More specifically, an OAM component is introduced for application developers to declare a runtime environment where the application runs, which might be containers, virtual machines, IoT devices, or cloud platforms. The runtime environment is also known as workload in the context of OAM. For example, an OAM workload, called containerized workload, represents a standard definition of runtime for containerized applications. On the other hand, an OAM trait is a discretionary runtime overlay that empowers workloads with additional operational features. Examples of it include scaling workloads dynamically to achieve high availability and routing the traffic towards a specific host domain. Both component and trait are designed as reusable templates that can be easily instantiated to compositions of different applications. Application configuration is a top-level OAM resource manifest in which all building blocks of an application are to be instantiated and interconnected. Figure 2 depicts the structure of an application containing one component for a containerized workload with two traits, scale and route, attached, and Listing 1 shows its corresponding OAM YAML snippet.