# Enabling Role-Based Orchestration for Cloud Applications
## 2 Background Technology for Cloud Orchestration
### Orchestration Scenario for Cloud Application  
To motivate our work, we consider a sample orchestration scenario for a WordPress application deployed in a container runtime environment, which is an open-source content management system written in PHP. The application is basically made up of two functional components: WordPress servers providing back-end services as well as web pages and a MongoDB database node connected to the server. It is noted that the TOSCA topology of the application is illustrated in Figure 1.  
Our orchestration system considers Kubernetes as the deployment platform. With a combination of well-defined declarative APIs, clear abstractions, and comprehensive extensions, Kubernetes is widely accepted as a solid foundation for DevOps platforms [11; 12]. Kubernetes offers a rich set of fundamental computing resources and configurable capabilities. As illustrated in Figure 4, two components of WordPress application are running inside a Kubernetes Deployment, while a Kubernetes Service serves as a load balancer as well as an entry point for users to access the WordPress service. It is also noted that our orchestration scenario involves two fundamental orchestration capabilities, auto-scaling and progressive delivery, to cope with realistic production environments.  
Automatic scaling is an operational capability used to adjust the application capacity to dynamically changing demands [13; 14]. It allows the number of the replicas of a particular component to be dynamically adjusted according to performance metrics such as CPU utilization rate or number of requests per second to the application. In our scenario, auto-scaling is applied to the WordPress server Deployment in such a way that the number of replicas is automatically increased or decreased in response to the fluctuation of incoming requests. Auto-scaling capability is composed of two main modules, which are a monitoring module and a scaling one. The former is responsible for monitoring its target component and collecting relevant metrics data, while the latter automatically scales the number of replicas based on its scaling rules.  
Progressive delivery is a widespread practice for gradually rolling out new features in order to avoid adverse impact on application operations [15]. Our scenario plans to upgrade the WordPress server replicas from version v1.0 to version v2.0 in batches. A certain portion of them is upgraded in each round rather than all replicas at once, so that remaining v1.0 replicas continue to provide the service, if something goes wrong during the upgrade. In production environments, an application often has a number  
Figure 4: WordPress cloud application in action.  
of running replicas created and managed by its auto-scaling capability to guarantee the service availability. Progressive delivery provides a means to upgrade the replica set to a new version at a controlled pace.  
These two capabilities are frequently utilized and found beneficial. However, their setup is not straightforward for application builders because they oftentimes lack sufficient knowledge about underlying platform resources upon which the capabilities are fulfilled. In case of OAM, two roles are involved with the DevOps practice. Application operators are the primary users of those two operational capabilities. Obviously, they are not expected to know how to set up or implement these capabilities, even though they attach desired operational characteristics to running workloads using the capabilities. On the other hand, it is application developers who configure a workload runtime environment. To manage the complexity in performing orchestration configurations and dealing with low-level details, we propose a new orchestration scheme that can separate different roles' concerns from oftentimes overwhelming configuration specifics for cloud applications.