13. BPM in the Cloud: The BOC Case

Soon after the decision to offer the BPM solution ADONIS as SaaS, BOC was facing the challenge of selecting an appropriate IaaS provider. They started the decision making process by collecting various decision criteria taking into account operations, legal, cost, and sales related aspects. They assigned relative weights to these criteria and marked some of them as must-have features. As a next step around 20 candidate providers were considered and rated first only considering the must-have criteria which helped reducing efforts in data collection by ruling out a large portion of the initial candidates list. For the remaining candidates the rest of the data was collected and the three providers with the highest rankings were presented to the decision team for discussion.

Retrospectively some of the weaknesses of this intuitive approach soon became obvious [3]:

BOC contributed these experiences during the requirements elicitation process for Venues 4Clouds, MODAClouds Decision Making System for Cloud Service Offer Selection which is described in detail in Chap. 2 [add reference]. In particular, BOC contributed a number of functional requirements, an initial set of decision criteria, and general success criteria for a Decision Support System to be developed [4].

Based on the requirements gathered, a risk-driven framework for decision support [3], a methodology for eliciting risk, cost and quality aspects in multi-Cloud environments [5, 6], and a prototype of a Decision Support System (DSS) have been developed. BOC used this methodology and the prototypical DSS to perform a light weight risk analysis by first defining a set of relevant business-oriented and technology oriented assets, determining risks related to these assets, and treatments mitigating these risks [4]). During this assessment process both business and technical stakeholders were involved. Table 13.1 lists the assets considered by either of these stakeholders.

In that way, for example customer loyalty, which was identified as an important asset by business representatives, has been related to the technical oriented assets data privacy, data integrity, end user performance, and service availability. Data privacy, in turn, has been related to the risks unauthorized access from IaaS provider, insufficient isolation, insufficient physical security, and data exposure to government authorities. As possible mitigations for these risks the availability of certificates guaranteeing information security and the possibility to select a specific data location were selected. A complete mapping of all identified assets, risks and mitigations can be found in the appendix of MODAClouds public deliverable 2.3.2 [7].

The fact that the user is guided through a structured process, starting with high level assets helped to identify a larger set of risks and, consequently, treatments to be considered, that would not have been detected using the original intuitive approach. At the same time the process turned out to be simple enough and well-guided by the tool to be usable for a small or medium enterprise (SME) such as BOC.

Since the current version of the DSS (Venues 4Clouds) is at prototype stage only, both the data gathered about Cloud providers and the pool of assets and risks already predefined in the tool are in no way complete at the time of writing. Provided that the systems knowledgebase will grow over time and that the data available can be maintained up to date and accurate, e.g. by employing self-learning mechanisms and being able to extract data from multiple online sources, it will be able to assist SMEs such as BOC in continuously keeping track of a large number of potential providers and in analysing them in a cost efficient way.

Before the start of the MODAClouds project BOC already had gathered some experience with deployment automation by employing the configuration management system Puppet to automate software installation in their application hosting environment. However, when it came to deployment to the Cloud and, in particular, to multiple Clouds, they soon realized some shortcomings of their approach:

As soon as a first version of MODAClouds design time component CloudML4Clouds which is responsible for deploying the modelled application was available, BOC started evaluating the component and found the following potential benefits:

However, it also turned out that using CloudML4Clouds to deploy on Windows Virtual Machines—one of the application components to be deployed in BOCs case is a Windows application—had some disadvantages compared to the use of Linux based VMs. In particular, the tool is relying on the Windows Remote Management protocol to execute remote commands and to deploy to a Windows VM which in turn requires CloudML4Clouds to be executed on a Windows machine. BOC had already invested in developing scripts for Puppet deploying parts of their application to Windows and preferred to capitalize on these investments rather than having to re-implement these scripts using Windows PowerShell commands. Hence, they decided together with the partners involved in developing the component to start an initiative to integrate CloudML4Clouds with Puppet modules.

At the time of writing all required extensions needed for deploying software components through Puppet on Windows VMs are available and BOC currently evaluates the usability of the Puppet extension to CloudML [8].

Since Puppet and similar tools like Chef are widely used in the DevOps community BOC expects the possibility to integrate them with CloudML4Clouds to be beneficial for a large number of potential users.

Before deciding to push the SaaS business, BOC already had a basic monitoring solution in place for several hosting projects. It was based on infrastructure performance indicators like CPU load and RAM consumption as well as the basic availability of the customer facing frontends and central backend components. When going larger scale with a full-fledged SaaS platform, the system health and performance need to be tracked more in detail in order to be able to mitigate issues at an early stage. Such a monitoring solution needs to collect application specific data and in some cases combine metrics from various sources in order to provide the comprehensive view of the whole system required by the operations engineers.

This is where MODAClouds’ monitoring technology Tower 4Clouds (Chap. 5) has been introduced with great success. Its Resource Description Framework (RDF) based streaming technology together with a flexible approach to configure data collectors and data analysers provide a solid framework for the challenges of a reliable and extensible monitoring platform.

Tower 4Clouds can be used as part of the complete MODAClouds toolset including design time quality constraint modelling, CloudML deployment and runtime self-adaptation. However, the MODAClouds monitoring components can as well become building blocks for tailored environments, even if the other parts of Energizer 4Clouds are not being used. In the case of BOC’s SaaS platform it has been integrated with the existing solution based on the open source tool Icinga.¹ This solution allows the operations team to continue working with the well-established Icinga frontend and its service recovery mechanisms while obtaining more details about the state of the platform. Furthermore, MODAClouds’ concept for data collectors makes it very easy for the DevOps engineers to extend the number and the types of metrics collected.

The integration of the stream based monitoring framework with the Icinga poll-based metrics acquisition has been implemented by leveraging the observer interface for Tower 4Clouds and providing a generic Icinga plugin for retrieving the collected data from the observer. With such a toolset adding a new metric that can be acquired with an existing data collector is just a matter of extending the data collector’s configuration accordingly and defining a corresponding service within Icinga.

An additional benefit from the usage of MODAClouds’ technology for monitoring is that all streams that represent numeric time-series data can be also directed into the Metrics Explorer (see Chap. 5), a web based graphing tool. This can be very useful for the operations engineers when a retrospective view at system performance indicators is needed and trends are to be interpolated.

The monitoring solution architecture for BOC’s SaaS platform based on Tower 4Clouds, Icinga and the Metrics Explorer is depicted in Fig. 13.2.

One of the key motivations for choosing IaaS technology over other models such as housing is the shift from capital expenditure (CAPEX) to operational expenditure (OPEX). This enables service providers to relocate their services among multiple infrastructures without losing investments. For BOC’s Cloud services this capability is an essential asset as it allows for cost optimisation and it also can be the right approach for dealing with availability or performance issues encountered within a specific infrastructure. In addition there is another valid use case for Cloud-to-Cloud migration: customers especially in the public administration sector are confronted with changing regulatory policies related to location of services and data they use for their work. Such policies may at some point in time prohibit usage of services and storage of data outside the respective country.

BOC’s SaaS platform has been designed with the objective to be extensible to sites located in different countries if customers have the need to have their data stored and services deployed in specific geographical locations. This is achieved by relying on basic IaaS for compute, storage and network resources managed through CloudML which in turn triggers Puppet [9] for deploying and configuring the BOC services. This Cloud vendor independent toolchain enables BOC to move their services among IaaS platforms from various providers.

The Cloud-to-Cloud migration approach chosen by BOC is one that relies on data replication mechanisms of the used database management system (MS SQL Server or Oracle Database), CloudML for deploying application stacks in multiple sites and the REST-enabled MODAClouds load balancer for switching the traffic from one site to the other. The complete procedure that needs to be executed to perform the switch from site A to site B consists of the following steps.

The main steps of the relocation are depicted in Fig. 13.3.

As all of the involved steps are scriptable, automation is possible if the frequency of the migration use case justifies the effort for implementing the automated solution based on the procedure described above.